log☇︎
500+ entries in 0.619s
asciilifeform: even if they're not indexed by line, but take the form ...../chan/date?start=foo&end=bar
snsabot: Logged on 2019-09-25 19:57:41 asciilifeform: lobbes: i relit mine via curl "http://logs.ossasepia.com/log-raw/trilema?istart=1937934&iend=1937941" > foo; ./eat_dump.py foo trilema 3
asciilifeform: lobbes: i relit mine via curl "http://logs.ossasepia.com/log-raw/trilema?istart=1937934&iend=1937941" > foo; ./eat_dump.py foo trilema 3
snsabot: Logged on 2019-09-15 20:55:59 asciilifeform: ( and mircea_popescu , say if you want yours excluded, or alternatively prefix '[chan] Logged on xxxx-xx-xx.... foo' etc. )
asciilifeform: ( and mircea_popescu , say if you want yours excluded, or alternatively prefix '[chan] Logged on xxxx-xx-xx.... foo' etc. )
asciilifeform: http://logs.nosuchlabs.com/log/trilema/2019-09-09#1935119 << this is a deeper africanism than mircea_popescu suspects , and sadly not even limited to pythonisms. it comes from when hands grow out of arses, and folx write libs where the namespaces cannot be mixed, so yer stuck lib_a.foo lib_b.foo , cuz can't import a + b . seen it in adaisms , cl, elsewhere.
asciilifeform: it is interesting, irc protocol asks that pingism follow form 'PING foo' 'PONG foo' . but their foo seems to be a constant.
asciilifeform: ( who hasn't blown entire weekend on 'grr should this /tmp/barf be chown apache:apache or apache:foo or...' ? )
asciilifeform: 'era 1' , when finally eaten, will be 'dekakoized' via phf's algo, i.e. <a href="...foo...">bar</a> only 'foo' will be transfomed, when foo corresponds to a kakotron url
asciilifeform: http://logs.nosuchlabs.com/log/trilema/2019-08-23#1930461 << this might be an irreconcilable 'religious' q. asciilifeform for instance thinks that having to write <b>foo</b> instead of *foo* is braindamaged.
asciilifeform: then i'm defo thick. let's work example ? machine booted up 5min ago. ergo primary FG buffer contains ~2MB. now i'ma a user, and i ask for dd if=/dev/random of=foo bs=1M count=3 , i.e. 3MB. nao what ?
asciilifeform: or for that matter why a x = foo.decode('latin-1') even can result in a x that later chokes pg when x.encode('utf-8') is put into a sqlism
asciilifeform: ah so if the page renderer asks for url, it dun see foo, bar ?
asciilifeform: nao all you'd need is to pluck out that foo and bar
asciilifeform: trilema.com/foo/bar/2016/44/32/21/11/pili/ btw loads even nao...
asciilifeform: ( or -- alternatively -- 'gateway' www , where e.g., http://foo.bar/btcbase.org/log , and hook all of our heathen dns records to point to said box, or a constellation of same ? )
asciilifeform: !A @foo@.3R*; .3!!!#
pehbot: asciilifeform: foo
asciilifeform: !A @foo@[foo]([;]); ! QY
pehbot: asciilifeform: foo;
asciilifeform: !A @foo@;; ! QY
asciilifeform: !A @foo@[foo].1,; ! QY
pehbot: asciilifeform: EGGOG: FATAL: Tick: 14 IP: 14 Symbol: ';' : Conditional Return in Sub: 'foo' is Prohibited! (Please check for unbalanced '{'.)'
asciilifeform: !A @foo@[foo].0{;}; QY
asciilifeform: !A @foo@[foo]; @bar@[bar]!!; @baz@[baz]!!; !
asciilifeform: !A @foo@[foo]; @bar@[bar]!; @baz@[baz]!!; !
asciilifeform: !A @foo@[foo]; @bar@[bar]!; @baz@[baz]!; !
asciilifeform: !A @foo@[foo]; !!!
asciilifeform: !A @foo@.0{;}_ @foo! QY
pehbot: asciilifeform: EGGOG: FATAL: Tick: 25 IP: 11 Symbol: '!' : Recursive invocation in Subroutine 'foo' is prohibited!
asciilifeform: !A @foo@ @foo! ; @foo! QY
asciilifeform: !A @foo@ @bar! ; @bar@ @foo! ; @foo! QY
asciilifeform: !A @foo@[sumthing seekrit]; LC @uses_seekrit@[in blah :]@foo!; RC @foo! QY
asciilifeform: !A @foo@[sumthing seekrit]; LC @uses_seekrit@[in blah :]@foo!; RC @uses_seekrit! QY
asciilifeform: !A @foo@[sumthing seekrit]; LC @uses_seekrit@[in blah :]@foo!; RC @uses_seekrit! QY
asciilifeform: !A '@foo@[sumthing seekrit]; LC @uses_seekrit@[in blah :]@foo!; RC @uses_seekrit! QY
asciilifeform: !A @z@[foo];@x@[x];@y@[y]@x!;@z!@x!@y!QY
asciilifeform: !A @z@[foo];@x@[x];@y@[y]@x!;@z!@x!@y!QY
a111: Logged on 2019-03-14 01:51 asciilifeform: !A .5:[Foo].3:[Bar].1-",_.1-",_
a111: Logged on 2019-03-14 01:51 asciilifeform: !A .5:[Foo].3:[Bar].1-",_.1-",_
asciilifeform: !A .5:[Foo].3:[Bar].1-",_.1-",_ ☟︎☟︎
asciilifeform: !A .5:[Foo].1-",_
asciilifeform: hanbot: it is also possible to bootstrap any vtron using naked gpg, ancient gnupatch, and bare teeth ( manually check sig and patch -p0 < foo.patch, for ea. )
asciilifeform: in turn, foo.h churns, churns, 9000 new versions in 6 months, cuz c intrinsically is a '10 lines contain 14 bugs' lang by virtue of sheer obfuscatory ugh ( who can say e.g. how many off-by-ones in http://archive.is/89adR#selection-9.11980-9.13314 ? in all possible calling contexts.. )
asciilifeform: 'what if you have a vax-flavoured foo.h' etc
asciilifeform: even e.g. #include <foo.h:e432850de89226c6745301a5932e30c5b09f260b9c850a5e76e8119f66b2f06f1798156138a1741aeff9c46ab90ff1d8ad97d9c089c7d76991a8b7ea8b104bdf> would've been improvement
mircea_popescu: in fact, there's a long line of illustrious ancestors who, having spotted this problem (wtf is foo ?!) attempted to solve it ~the very wrong way~, ie, by definition. hence not just ai winter, but microscopically naggum's sgi misadventures and so on.
mircea_popescu: (note that the tempting "obvious" approach -- describe foo then!!! -- is not only fucking broken, but broken in the exact way minsky wasted life trying to produce. there can not be ~description~, the only way to induce meaning in the machine is through filiation. v-produced foo has a very strict "wtf is it ??" answer associated, but also very fine and not structure-driven.)
asciilifeform: as it is, there could be 9000 variants of foo, and on same machine you'll find 900 of'em
asciilifeform: without saying where is foo
asciilifeform: mircea_popescu: the part where you can #include <foo.h>
phf: i also have another approach, with V_PATCHES=[('http://.../foo.vpatch', 'http://.../foo.vpatch.first.sig', 'http://.../foo.vpatch.another.sig'),...] where ebuild basically keeps explicit press order, but can also rely on emerge for pulling the files from remote. none of it is particularly satisfying
a111: Logged on 2018-11-26 14:19 phf: vpatch is picky about what it accepts, it's basically only a/foo/* b/foo/*, where's vdiff can accept a totally random stuff like /foo/bar/qux diffed against /dev/null or whatever. right now even diffing two straight files e.g. vdiff x y will produce a non-pressable vpatch. this is all not so much a bug as an unexplored aspect of vdiffing which is also part of the whole rename tracking.
phf: asciilifeform: i don't think so either, but it's a question of what's the format of vpatch. if the a/foo b/foo is mandatory or if you e.g. can have v2/foo v3/foo. right now the answer is "don't do it that way", which is fine, but it's cheap to talk through that stuff.
phf: and then vdiff v1 will give you a/foo b/foo genesis
phf: asciilifeform: right, that's possibly something to make mandatory then, that is a diff of any two directories produces a a/... b/... patch. so that you can have v1/foo v2/foo v3/foo and vdiff v2 v3 produces a/foo b/foo
phf: err vdiff foo where inside foo you have multiple folders. it's tied to whether or not those parent folders a and b should be implicit, and if vdiff should do the right thing in that case, or keep it all explicit and require the creation of a and b top level folders always.
phf: or perhaps vdiff foo/{bar,buz}/... should be producing /a/foo/bar/... /b/foo/bar/... and /a/foo/buz/... /b/foo/buz/...
phf: but to your point specifically, i was thinking that if you provide only one argument, right now vdiff errors out, so i think it would be better if it produced genesis. e.g. vdiff foo could produce a a/foo/* false b/foo/* 123 vpatch
phf: vpatch is picky about what it accepts, it's basically only a/foo/* b/foo/*, where's vdiff can accept a totally random stuff like /foo/bar/qux diffed against /dev/null or whatever. right now even diffing two straight files e.g. vdiff x y will produce a non-pressable vpatch. this is all not so much a bug as an unexplored aspect of vdiffing which is also part of the whole rename tracking. ☟︎
asciilifeform: mod6: mircea_popescu specifically didn't want to change the file ext. ( but only barfed lightly when asciilifeform proclaimed 'i'ma make mine foo.kv.vpatch cuz i have 90000 private vpatches in old form' )
asciilifeform: v makes it possible to sign a compartmentalized change , so reader is not stuck having to manually diff contents of signed_foo.today.tar.gz against signed_foo.tomorrow.tar.gz to see where the changes were. but what it deliberately does ~not~ do is to enable the pretense ( carried on in git & other heathen abominations ) that a proggy where something semantically upstream of $place were changed, is ~same~ proggy ~but for $place~ .
a111: Logged on 2018-03-28 20:02 phf: this gnulib solution actually wants you to define FOO_INLINE, which is set to "inline" when defined, and "extern inline" when used, so you can't even avoid the #define hackery with "extern inline". "Other non-C99 compilers use static inline so they suffer from code bloat, but they are not mainline platforms and will die out eventually."
asciilifeform: diana_coman: it's perfectly permissible to define, e.g., subtype foo 1 .. 40 of a 2**5 modular type that lives in 5bits; and catch the out-of-range eggog when reading it
phf: well, no, colorize, when it does its colorizing, has to know a bit about identifiers and tokens and such. so hooking in this case involves getting some information from colorize that says "i got an identifier FOO, give me back a link to where it should link"
asciilifeform: http://btcbase.org/log/2018-11-04#1869238 << iirc ( really calls for experimental test ) when you foo : String := "bar" & "baz" ; at compile time it glues'em , and does not drag in secondarystackism, fwiw ☝︎
a111: Logged on 2018-09-27 16:02 phf: you can basically do (cat foo.vpatch bar.vpatch qux.vpatch) | vpatch and expect the resulting press to be fully valid, hashes and all
phf: asciilifeform: i have a ksum PoC for you, http://btcbase.org/patches/vtools_ksum signed but it's from workbench, potentially buggy. "ksum foo bar qux" gives you shasum style <hash> foo\n<hash> bar\n<hash> qux\n
phf: you can basically do (cat foo.vpatch bar.vpatch qux.vpatch) | vpatch and expect the resulting press to be fully valid, hashes and all ☟︎
phf: asciilifeform: please to clarify, do you mean that you can say run "./vpatch < foo" and if that fails you run it as "./vpatch -t sha < foo". or are you saying "./vpatch < foo" and it attempts to, internally, first keccak then sha?
asciilifeform: i'ma formulate all subsequent ones as ' s/foo/bar ', as i do for BingoBoingo
asciilifeform: e.g. Foo(1 .. 3) := (others => 0) compiles into a memset(..., 0) ; Foo(1 .. 3) := Bar(5 .. 8) compiles into a memcpy . etc
asciilifeform: zcat /proc/conf.gz > foo
a111: Logged on 2018-08-11 00:12 asciilifeform: so we can e.g. !phuctor 106.242.174.238 , !phuctor foo@bar.com , etc
a111: Logged on 2018-08-11 00:12 asciilifeform: so we can e.g. !phuctor 106.242.174.238 , !phuctor foo@bar.com , etc
asciilifeform: so we can e.g. !phuctor 106.242.174.238 , !phuctor foo@bar.com , etc ☟︎☟︎
phf: well, 100 ln patch to the compiler, because it can't be done as a user proggy (e.g. (symbol-value 'foo) triggers a mechanism of some sort, without an indirection)
phf: if you want to reduce the problem to a "don't do this" policy, then it stems from repeated hunks across multiple vpatches, i.e. if you have two or more vpatches that have identical state transitions. something like that is bound to happen when you're attempting to port a feature between branches, as is the case with vtools. (i.e. you patched foo.c in one file "remove broken behavior", you now want to also introduce same fix to the other branch)
a111: Logged on 2018-07-05 18:02 phf: gentoo out of the box turned out to have all kinds of interesting surprises (i haven't ran gentoo in years, so it was interesting to see the holes through which the darkness comes). like the foo-9999999.ebuilds that just pull from the mystery github repos without any kind of checksumming
phf: gentoo out of the box turned out to have all kinds of interesting surprises (i haven't ran gentoo in years, so it was interesting to see the holes through which the darkness comes). like the foo-9999999.ebuilds that just pull from the mystery github repos without any kind of checksumming ☟︎
asciilifeform: hey, it isn't as if the academitards don't always create 'new' 'paper' via same foo | bar | baz template spammers use ( as posted in mircea_popescu's www on at least 1 occasion )
phf: ccl has a fancy system, based on hacked up gcc, for generating ffi mappings (called interfaces), which you then can use with (use-interface-dir :foo) (#_foobar ...)
mod6: Ah yeah. If i grep for "foo" and it isn't found. It just hands you back your shell. Which I just always thought "oh, nothing found". But this is actually a non-zero return code.
a111: Logged on 2018-05-15 21:28 asciilifeform: diana_coman: steps to replicate: 0) on a machine WITH A WORKING GNAT (e.g. adacore's , and it must be in your path already ) 1 ) download the tarball from http://ave1.org/2018/building-gnat-on-musl-now-with-partial-and-parallel-build-support 2) unpack tarball ada-musl-cross-2018-05-15.tgz , go to the dir 3) mkdir bin << this is where the built binariola will live 4) ./build-ada.sh /home/foo/temp/ada/ada-musl-cross-2018-05-15/bin
asciilifeform: i omitted a step 5 ) put in ~/.bash_profile , the path, e.g. PATH="/home/foo/temp/ada/ada-musl-cross-2018-05-15/bin/x86_64-linux-musl/bin/:$PATH"; export PATH
asciilifeform: diana_coman: steps to replicate: 0) on a machine WITH A WORKING GNAT (e.g. adacore's , and it must be in your path already ) 1 ) download the tarball from http://ave1.org/2018/building-gnat-on-musl-now-with-partial-and-parallel-build-support 2) unpack tarball ada-musl-cross-2018-05-15.tgz , go to the dir 3) mkdir bin << this is where the built binariola will live 4) ./build-ada.sh /home/foo/temp/ada/ada-musl-cross-2018-05-15/bin ☟︎
mod6: Yeah, came in hard with the awk-foo.
phf: i've skimmed it when it came out and i agree with your feedback. primarily making it self contained, i.e. getting rid of cl-ppcre for parsing (!!1) and needless dependencies like uiop by way of classical (defun run-program (foo bar) #+sbcl (sb-ext:...) #+ccl (ccl:...) #-(or ccl sbcl) (error ...))
phf: http://btcbase.org/log/2018-04-27#1805906 << asdf3 is pretty much standard in all the lisps right now, you have to go out of the way to downgrade. at the very least avoid implicit uiop dependency and declare it in your asdf file (this is by the way even fare's recommendation, but people ignore it "oh i have asdf3, means i can just throw a sneak uiop:foo all over my code) ☝︎
phf: perhaps try select * from moduli left outer join (select distinct unnest(mods) as mod from factors) as foo on moduli.idx = foo.mod where foo.mod is null
phf: with foo as (select distinct unnest(mods) as mod from factors) select * from moduli left outer join foo on moduli.idx = foo.mod where foo.mod is null;
asciilifeform: phf: eggog, missing FROM-clause entry for table "module" LINE 1: ...tors) select * from moduli left outer join foo on module.idx...
phf: mircea_popescu: maybe try this with foo as (select distinct unnest(mods) as mod from factors) select * from moduli left outer join foo on module.idx = foo.mod where foo.mod is null;
phf: but right now it's very easy to add foo:... clause. the complete set of these is from:, notfrom:, refs: (specific number of references that the post has), and not:
phf: mircea_popescu: notfrom, and it's not proper grammar. the whole thing is an AND, and the foo:... commands are constraints. so not is more properly should be called something like "filter:"
phf: i.e. trb.vpatch -> trb.web -> foo.c, bar.c, qux.c
phf: this gnulib solution actually wants you to define FOO_INLINE, which is set to "inline" when defined, and "extern inline" when used, so you can't even avoid the #define hackery with "extern inline". "Other non-C99 compilers use static inline so they suffer from code bloat, but they are not mainline platforms and will die out eventually." ☟︎
asciilifeform: ada folx: re making ada strings out of the c variety : strlen(char *) is a potentially lethal op ( suppose the nullterminator is missing ) so it will never be called implicitly by ada. you gotta either call strlen deliberately on c side, and then form ( can be on stack , declare ... Foo : String(1 .. Length) ... , say, a la http://btcbase.org/patches/ffa_ch4_ffacalc#L53 ) a proper ada string and copy the cstring into it.
phf: http://btcbase.org/log/2018-02-23#1785630 << so offending attribute is _Noreturn, which is a c11 feature that was only introduced in 4.7. but! i tested with 4.6.4 on freebsd before release, i now also compiled 4.4.3 and it still works. running cpp-4.4 on the file it looks like something in freebsd headers actually replaces _Noreturn with an __attribute__ call that older gcc's support. with a test file with `void _Noreturn foo() {...}' but without any includes, ☝︎
phf: asciilifeform: they have a stupid gb style scheme of *.foo.uy