600+ entries in 0.851s
phf: (there's yet another solution is to actually provide a binary patcher, that uses some minimal delta algorithm to patch files, while also providing the patching details in plain text. so you could say that the result is readable in a sense that it takes file
FOO and replaces bits #10 #1343 #325435 etc)
a111: Logged on 2018-01-05 22:41 asciilifeform: so {[
foo]}{[bar]} would then instead look like {[
foo]}~{[bar]}_ grrrrrr
phf: elastic spaces in this case means variable width spaces. you can't have that in plain text. you can either have foo_bar or foo__bar or ...
a111: Logged on 2017-12-27 02:01 asciilifeform: picture a kind of 'multiverse ada', where you dun call
foo(bar), but instead
foo:somepatchid(bar:somepatchid) etc, explicitly conforming to 'multiversism'...
pehbot: phf:
foo 0000000000000000000000000000000000000000000000000000000000000001=0000000000000000000000000000000000000000000000000000000000000001
a111: Logged on 2017-12-27 02:03 asciilifeform: or, on other end of the possible, a vtron that somehow understands that a call of
foo necessarily depends on the patch that birthed
foo... and requires disambiguation only if >1
foo exists in the tree
a111: Logged on 2016-06-20 04:23 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: what if you have /a/
foo and /b/bar/
foo, /b/qux/
foo where all
foo are identical?
phf: by your previous question you're saying that diff is supposed to say that
foo was moved
phf: say you have /a/
foo and you have /a/bar/
foo where both
foo are identical. you're running diff -ruN a b, what is the expected behavior?
mircea_popescu: when i say diff a/
foo b/
foo, diff fails to output "one is in a, the other in b" as the first fucking item on its list of differences. this is because the (idiots) that made diff thought they gain something by eliding "the trivial case".
mircea_popescu: but you can know that one
foo is in a and the other not
phf: there's no way of knowing without having a complete history of states whether or not
foo was moved or removed
phf: if you do mkdir a; touch
foo; touch a/
foo; mv
foo a/
foo;
phf: but anyway, i'm not convinced that file management is a proper concern for diff. we could add it to a diff format, by placing some instructions in the prelude (which is normally ignored by unix patchers). rm src/
foo.c, mv src/
foo.c src/bar.c which can be used as instructions for reader with non compliant patchers, or parsed by the vpatcher to be executed. this is all incredibly inband, but conforms to the medium
mircea_popescu: but, it wouldn't happen if
foo(4,4) nor when
foo(x,y) where the VALUES of x=y=4. it'd strictly happen when
foo(x,x) ie, same variable_name
gabriel_laddel: asciilifeform: There is still plenty to do. CLIM's COM-
FOO machinery has to be cut & replaced with "functions most often called on / FTYPE matches this as a valid ARG"
phf: well, right, it highlights a specific post, but also filters, so ...#;
foo works as a whole day filter
a111: Logged on 2017-06-06 20:38 asciilifeform: diana_coman: the example was written on a box with adacore's gnat; the stock gnu one is stricter, doesn't permit
Foo'Image -- instead you gotta FooTypeName'Image(
Foo)
phf: you also want to have a custom symbol reader, because reading cl::
foo is going to explode with a "locked package" error
phf: there's no such thing as a standard sexps. sure (
foo "bar" 1.2) but #\abc or #x123 exist in the same realm as #.(...)
a111: Logged on 2017-07-03 14:46 phf: i think ascii already made that point, that if you're profiling lisp with the vm startup, then you should also profile c machine from boot time. at the very least the vm should be warmed up by loading all the dependencies into the core, doing save-lisp on it, and then making sure that your
foo.lisp has an up to date fasl. inside lisp though to achieve the optimizations you run variants of your function inside (time ...) until you bring it within the ra
phf: i tried !from:
foo syntax, but until there's a proper search query grammar i think i'll stick to an explicit looking keyword, as originally suggested
a111: Logged on 2017-09-10 21:41 asciilifeform: upstack : is it obvious to everyone why the %eax is retarded ? ( same reason $
foo in basic/perl/other braindamaged langs is)
phf: well, why not: tar cvfz
foo.tar.gz `tree bar/baz|grep .txt` ?
phf: tramp when it sets up remove ssh scaffolding, sends small inline scripts which defensively retranslate what emacs wants, rather then doing "ssh
foo ls"
phf:
foo is a specially crafted file which is simply a sequence of bytes from 0 to 255
phf: so it shouldn't be loosing anything in 0-127 range, at least the
foo file comes through clean. it is trying to parse the input as unicode (and i'm pretty sure it's the server doing it, because curl is sending it 8bit clean)
trinque: phf's "
foo" breaks it, though really, if the thing's an ascii paster, I dunno that the bug's anything but "fed uniturds, did not tell user to fuck off"
phf: i say it right there! "cat
foo | wotpaste"
trinque: diff <(curl -s $(cat
foo | wotpaste))
foo Binary files /proc/self/fd/11 and
foo differ << with his wotpaste func and
foo phf: $ curl --silent $(cat
foo|wotpaste)|shasum
phf: 82a2e85430ce36b759c5422a7433001d6e64b777
foo phf: $ dd if=/dev/random of=
foo bs=1024 count=100
phf: 00000000: 0946 4f4f 0909 .
FOO..
phf: or possible supporting all kinds of system specific corner cases (oh netbsd returns NULL here instead of "
FOO")
phf: there's ISLISP standard, which was supposed to create a subset of multiple different lisps (like common lisp and scheme, but also eulisp, since designed by europeans). i don't think anyone (particularly sexp library authors for other languages) ever tried to conform to it. typical solution is to have a JSON-like subset of sexps, so that you can express (
FOO "abc" 2), i.e. symbol, string, number and list and nothing else
phf: (common lisp sexps are backed by a full blown reader, with multiple non-trivial dispatch macros, so for example '(1 #.(+ 1 1) 3) is a valid sexps that's read as '(1 2 3), i.e. (+ 1 1) is evaluated at read time. there's a dispatch for structs, like #S(
FOO :A 1 :B 2) results in a structure
foo with two slots a and b set to 1 and 2 respectively, but there's no corresponding constructor for classes. there's a reader for arrays, but that one doesn't let you
sina: imagine flatfile example of "assigning" generated key from "available" => "user" state, or "user" => "bogus" state, that's moving a keyfile from gossipd/keys/available to gossipd/keys/users/
foo or similar action, now my program has to either invoke "mv" or write mv-like functionality into my app
phf: i think ascii already made that point, that if you're profiling lisp with the vm startup, then you should also profile c machine from boot time. at the very least the vm should be warmed up by loading all the dependencies into the core, doing save-lisp on it, and then making sure that your
foo.lisp has an up to date fasl. inside lisp though to achieve the optimizations you run variants of your function inside (time ...) until you bring it within the ra
☟︎ mod6: <+asciilifeform> mod6: if you want to test, keep in mind that you gotta
Foo : FZ(Bits) ; now, rather than
Foo : FZ; << good to note. thanks
CluelessNoob: asciilifeform.asc asciilifeform.asc.
foo ben_vulpes.asc mircea_popescu.asc mod6.asc trinque.asc
phf: in fact!!! $(which
foo) works
phf: i'm getting a weirdest behavior on mac. a dumped lisp image with executable payload: when call it from shell "directly", i.e. ./
foo works fine, but when you call it "global" i.e. it's in path and you say
foo it responds with "read_mach_o_header: Bad file descriptor"