SPC q q
- quitSPC w /
- split window verticallySPC w
- - split window horizontallySPC 1
- switch to window 1SPC 2
- switch to window 2SPC w c
- delete current windowSPC TAB
- switch to previous bufferSPC b b
- switch buffers
-- show running queries (pre 9.2) | |
SELECT procpid, age(query_start, clock_timestamp()), usename, current_query | |
FROM pg_stat_activity | |
WHERE current_query != '<IDLE>' AND current_query NOT ILIKE '%pg_stat_activity%' | |
ORDER BY query_start desc; | |
-- show running queries (9.2) | |
SELECT pid, age(query_start, clock_timestamp()), usename, query | |
FROM pg_stat_activity | |
WHERE query != '<IDLE>' AND query NOT ILIKE '%pg_stat_activity%' |
package main | |
import ( | |
"context" | |
"flag" | |
"fmt" | |
"log" | |
"net/http" | |
"os" | |
"os/signal" |
(ns your.namespace.async-util | |
(:require | |
[clojure.core.async :as a :refer [>! <! >!! <!! go chan buffer | |
close! thread alts! alts!! timeout]] | |
[clojure.core.match :as match :refer [match]])) | |
;; | |
;; core.async util fns | |
;; |
This post also appears on lisper.in.
Reader macros are perhaps not as famous as ordinary macros. While macros are a great way to create your own DSL, reader macros provide even greater flexibility by allowing you to create entirely new syntax on top of Lisp.
Paul Graham explains them very well in [On Lisp][] (Chapter 17, Read-Macros):
The three big moments in a Lisp expression's life are read-time, compile-time, and runtime. Functions are in control at runtime. Macros give us a chance to perform transformations on programs at compile-time. ...read-macros... do their work at read-time.
RDBMS-based job queues have been criticized recently for being unable to handle heavy loads. And they deserve it, to some extent, because the queries used to safely lock a job have been pretty hairy. SELECT FOR UPDATE followed by an UPDATE works fine at first, but then you add more workers, and each is trying to SELECT FOR UPDATE the same row (and maybe throwing NOWAIT in there, then catching the errors and retrying), and things slow down.
On top of that, they have to actually update the row to mark it as locked, so the rest of your workers are sitting there waiting while one of them propagates its lock to disk (and the disks of however many servers you're replicating to). QueueClassic got some mileage out of the novel idea of randomly picking a row near the front of the queue to lock, but I can't still seem to get more than an an extra few hundred jobs per second out of it under heavy load.
So, many developers have started going straight t
I looked into the state of GraalVM and Clojure and wrote some small work-related scripts.
- Downloaded GraalVM and set $GRAALVM_HOME
- Found two main libraries for building GraalVM CLIs - https://github.com/luchiniatwork/cambada#packaging-as-a-native-image and https://github.com/taylorwood/clj.native-image (or https://github.com/taylorwood/lein-native-image for the lein equivalent). I chose clj.native-image as it seemed more focused on doing one thing well.
- First tried its template example which was easy to follow.
- Then added a graalvm build to one of our small cli tools
- Found it to be pretty straightforward except for a stdout flushing issue that was trivial to fix
# Turn on the simulator screen capture | |
xcrun simctl io booted recordVideo ~/simulator.mov | |
# Convert the iPhone 6s screen shot into a gif: | |
ffmpeg -i ~/simulator.mov -vf scale=320:-1 -r 6 -f gif -y simulator.gif |
import os | |
import pickle | |
import warnings | |
import numpy as np | |
import pandas as pd | |
from sklearn.model_selection import train_test_split | |
from tensorflow.keras.callbacks import EarlyStopping | |
from tensorflow.keras.layers import Dense | |
from tensorflow.keras.layers import Dropout |