phf: when i started using emacs there was an almost ideological aversion to DWIM in the community, instead of having say smart context "search" thing you'd have a dozen search-foo-in-bar combinations, and that was thought The Right Thing. emacs has long been dragged in the dwim direction by the usual suspects, but the vogue elsewhere is now dwiw, i.e. do what i want. as explicit/"want" gap gets bigger, you're going to have all kinds of attack vectors o

phf: which is handy if you're using something else to produce the patch, or if you need to use a non-trivial diff command. for example i sometimes need to exclude files from diffing, so a command might look like diff -x foo -x bar -x qux -ruN a b | grep -v '^Binary files ' | vdiff > foo.vpatch ☟︎☟︎☟︎

phf: something to keep in mind is that vpatch paths already include top level directory, like for example all the bitcoin ones are bitcoin/... so pressing them into an empty directory foo will result in foo/bitcoin/... tree

phf: asciilifeform: http://glyf.org/tmp/foo.jpg ☟︎

phf: j-dawg: btcbase secretly tracks btcbase itself, since i'm experimenting with (load-v "foo.vpatch") type thing, but that's not public. i don't think there's a proper vtronic chain of V or rotor available, so unless i generate those myself there's nothing i can track

phf: asciilifeform: heads up, archive contains a bunch of users without keys, where the foo.asc files content is "SELF-SIGNED PUBLIC KEY NOT FOUND", presumably that's the ones that didn't upload (you'd think they would 404 instead)

phf: !s foo

phf: but yeah, it greps by space separated words, greps by quoted strings (\" escape works) and recognizes from:foo, which composes. i.e. from:foo from:bar baz " foo bar " finds log entries from foo OR bar that contain both "baz" and " foo bar "

phf: well, no first one is going to catch both foo bar and bar foo, the second one only foo bar

phf: any particular preferences if q=foo&q=bar should work as grep foo|grep bar or grep foo.*bar?

phf: mircea_popescu: by the way, &from=foo already works, i.e. &from=mircea will only show...

phf: or perhaps just term foo or whatever command

phf: an alternative to tmux can be "detachtty", which is basically a tmux for non curses processes. it's a bit handier than tmux, since it gives you a pid/ctrl/log for one process only. you can issue batch commands, by doing something like echo '(foo)' | ssh server attachtty --socket=/tmp/cmucl-123.sock

phf: trinque: so just deploy the way you would normally deploy and write a simple set of operator commands (or even a menu driven thing) for repl, that you can control things over. "press 1 to asdf reload :FOO package, press 2 to reinitilize data, etc."

phf: basically some equivalent of "tree 182073587b70313f13678c6e1389cb6c94dd3c69\nauthor foo <foo> 1458691972 -0400\ncommitter foo <foo> 1458691972 -0400\n commit message ... "

phf: suggested solutions include writing update hooks, that in turn involve plenty of goo' ol' foo=$(bar|sed|awk)

phf: right, linux root=/dev/foo kbrebind=10:20,40:50,etc.

phf: 1) brew install cmake 2) patch < foo.patch 3) link_directories and include_directories in CMakeList.txt need to point to be modified to point to your boost/db4/openssl locations 4) mkdir foo; cd foo; cmake ..; make ☟︎

phf: mod6: you want to do (catch #f (load "foo.scm")), because without catch any errors in your foo.scm are going to kill tinyscheme AND terminate bitcoind without cleanup

phf: they have some package hack foo::bar (and not foo:bar), which mostly just breaks things

phf: right now it's a bit jury rigged though. most intrusive is the addition of "keywords" to scheme.c, i.e. :foo evaluates to :foo

phf: $('#patchset-select select').on('select', function() { alert('foo') }) doesn't do what i think it should

phf: there is? :o i did shasum -a 512 -c foo.txt|grep -v OK where foo.txt is your dpaste and only headers is not giving me ok.

phf: maybe? gcc does TCO, but the code does foo(); return; rather then return foo(); so who knows..

phf: ben_vulpes: you call that thing like void foo(args) { IMPLEMENT_RANDOMIZE_STACK(foo(args)); ...}, static makes nLoops shared, so the logic is, you set it to some random value between 1 and 21 and then recurse down that many times, "randomizing" the stack ☟︎

phf: contributors. an obvious next step is to have a gpg --verify buildroot.sig rely on the contents of .wot folder, by, for example, making a temp directory, doing a for pubkey in .wot/*.asc; do gpg --homedir $tmpdir --import $pubkey; done, then doing gpg --homedir $tmpdir --verify foo.sig; then rm -rf $tmpdir. this way a .wot folder is a canonical source of pubkeys always and for all operations

phf: well, that's the relevant posting bit echo foo|curl -s -F "content=<-" http://dpaste.com/api/v2/

phf: (drakma:http-request (concatenate 'string (cdr (assoc :location (nth-value 2 (drakma:http-request "http://dpaste.com/api/v2/" :method :post :parameters `(("content" . ,(concatenate 'string "foo" '(#\Newline) "bar"))))))) ".txt") :force-binary t) ☟︎

phf: oh, it's placed around, so (loop named foo ...) == (block foo (loop ...))

phf: probably can be cleaned up, but where's that catch being interpolated when you do (loop named foo...)

phf: oh yeah, re lisp, i've not had a chance to use it, but i'm pretty sure i have a bunch of code that does (loop .. do (catch :foo ... (loop ... (throw :foo ...)))

phf: otherwise you need to do foo=NULL; for(...) {...}; if(!foo) { ... }

phf: mod6: use File::Temp qw/:mktemp/; $foo = mkdtemp("/tmp/fooXXXXXXX"); print $foo."\n"; # => /tmp/foowq51sxd

phf: jurov: well, i could build eulora into /Applications/Foo.app/... structure, and then require people to install by dropping resulting app into /Applications/ on their machine, but there's no sport in that

phf: su/sudo vfs would be handy for copying files between users without having to adjust permissions or escalate to superuser. one pane is user foo, other pane is user bar. doesn't matter if foo's pane is in 700 folder, and if you were to copy, file will be created as belonging to user bar, with his umask applied

phf: ascii_field: i've tried reproducing the leak, but so far it looks like so according to my small test, mapTransactions.clear() should just work. http://glyf.org/tmp/foo.cpp.html there's a bunch of copy allocations that get cleaned up, but you'll notice when foo.clear() is called that picks up the leftover objects.

phf: williamdunne: i guess i might've also did a wild guess, i assume you're getting some standard-objects from somewhere, and they come out as #<FOO #x123123> or somesuch and you're trying to figure out, what's inside of them. you can (inspect foo) to see the insides of the object on repl, or you can call that (defmethod ...) and then every time an object is displayed on repl it's going to be displayed as #<FOO (value . 1) (value2 . "hello")> i

phf: williamdunne: not builtin, but here's a generic object printer, http://paste.lisp.org/display/153363. if you have an instance of a class, you'll get #<FOO (A . 1) (B . "test") C #x123123> (where C is unbound)