diff options
author | Ben Sima <ben@bsima.me> | 2020-11-18 20:20:27 -0500 |
---|---|---|
committer | Ben Sima <ben@bsima.me> | 2020-11-18 20:20:27 -0500 |
commit | e223b28e6820dcd9fa5c38ba22de487ada2ca0e6 (patch) | |
tree | 66061bca039242bc55338280f767d0ff64d35ba0 /Que/Quescripts.md | |
parent | ac3d455a9c0dc0b2f4afb88b56db3d16c0508428 (diff) |
Extend bild to nix targets properly
Also had to capitalize some stuff, and move some nix files around and rename
the metadata directive from 'exe' to 'out' because that just makes more sense,
and fix some compiler errors. But now bild treats both nix and hs files as
buildable things. So that's cool.
One interesting example is Biz/Pie.{nix,hs} - I can either create a dev build of
the hs file with ghc, or I can create a fully-encapsulated nix build. Its nice
to have both options because a dev build with ghc takes half the amount of time,
and I can rely on my locally cached hi and ho files. I think this shows the
power of bild, but also can be a somewhat subtle thing.
The issue really is with the separate command calls in nix builds vs dev builds.
I figure there are a few ways to fix this:
1. Try to use bild inside the nix rules. That could be interesting, but could
also lead to some weird behavior or worm holes forming.
2. Extract the command line invocation into a separate file, some kind of
really simple template that gets pulled into both programs.
It is important to consider that in the future I might want to have bild do a
module-by-module nix build of programs, but I'm not sure how that would effect
my choice here.
Diffstat (limited to 'Que/Quescripts.md')
-rw-r--r-- | Que/Quescripts.md | 50 |
1 files changed, 50 insertions, 0 deletions
diff --git a/Que/Quescripts.md b/Que/Quescripts.md new file mode 100644 index 0000000..77e7004 --- /dev/null +++ b/Que/Quescripts.md @@ -0,0 +1,50 @@ +% Quescripts + +## Remote desktop notifications + +Lets say we are running a job that takes a long time, maybe we are +compiling or running a large test suite. Instead of watching the +terminal until it completes, or flipping back to check on it every so +often, we can create a listener that displays a popup notification when +the job finishes. + +In one terminal run the listener: + + que pub/notify --then "notify-send '{que}' '{msg}'" + +In some other terminal run the job that takes forever: + + runtests ; echo "tests are done" | que pub/notify - + +When terminal 2 succeeds, terminal 1 will print "tests are done", then +call the `notify-send` command, which displays a notification toast in +Linux with title "`pub/notify`" and content "`tests are done`". + +Que paths are multi-producer and multi-consumer, so you can add as many +terminals as you want. + +On macOS you could use something like this (just watch your quotes): + + osascript -e "display notification \"{msg}\" with title \"{que}\"" + +in place of notify-send. + +## Ephemeral, serverless chat rooms + +coming soon + +## Collaborative jukebox + +It's surprisingly easy to make a collaborative jukebox. + +First start up a music player: + + que --poll pub/music --then "playsong '{msg}'" + +where `playsong` is a script that plays a file from data streaming to +`stdin`. For example [vlc](https://www.videolan.org/vlc/) does this when +you run it like `vlc -`. + +Then, anyone can submit songs with: + + que pub/music song.mp3 |