log☇︎
1600+ entries in 0.077s
asciilifeform: phf: you can get up to 10" panels, for ~pennies, the issue is the controller, nobody makes 1 that works with the surplus 'kindle' etc panels.
asciilifeform: phf: funnily enuff i have that screen, experimented with use as indicator. it's dog slow.
asciilifeform: phf: wouldja program on a 3" screen ?! ☟︎
asciilifeform: i cannot speak for e.g. trinque , phf, mod6 , but would not be surprised if same is the case there.
a111: Logged on 2018-10-01 09:04 diana_coman: phf, please add the fix patch to eucrypt http://ossasepia.com/reference-code-shelf/#selection-391.0-399.38
asciilifeform: !Q later tell phf http://btcbase.org/patches/v99#L36 is not 'bug' in the usual sense of the word, but imho oughta be fixed in next rev
asciilifeform: http://btcbase.org/log/2018-10-01#1856328 << phf, this is neato ! i'ma try it today. ☝︎
diana_coman: phf, please add the fix patch to eucrypt http://ossasepia.com/reference-code-shelf/#selection-391.0-399.38 ☟︎
mircea_popescu: esthlos phf sweet!
asciilifeform: nuffin is won by waiting, phf
a111: Logged on 2018-09-29 23:32 phf: (i'm not up to date with log) trinque: i can post a patched v.py that works with vtools, i have some free time sunday evening to prep it up
lobbesbot: phf: Sent 1 hour and 19 minutes ago: <asciilifeform> plox to snarf http://therealbitcoin.org/ml/btc-dev/2018-September/000312.html and the predecessor ( mod6's http://therealbitcoin.org/ml/btc-dev/2018-September/000311.html ) into 'experimental'
trinque: would also take a phf item, if v.py is ready to roll with vtools
asciilifeform: !Q later tell phf plox to snarf http://therealbitcoin.org/ml/btc-dev/2018-September/000312.html and the predecessor ( mod6's http://therealbitcoin.org/ml/btc-dev/2018-September/000311.html ) into 'experimental'
a111: Logged on 2018-09-27 17:54 asciilifeform: phf: imho your approach , i.e. dispensing with gnupatch, is The Right Thing, historically there was quite a bit of grief from gnupatch's habit of eagerly attempting to apply an invalid (by vtronic lights) but 'partially ok' by barbarian lights patch
asciilifeform: mircea_popescu: shouldn't take much sweat, anyffing that calls gnupatch could just as readily call phf's
a111: Logged on 2018-09-27 17:27 phf: trinque: vtools has not been design or intended to compete with any particular v implementation. it's a set of tools that you can use in a v workflow (hence the name). at least initially it was two matching tools vdiff and vpatch that know how to produce and consume a canonical vpatch. the conflation came up, because i also published vtools in a form that broke existing canonical v, v.pl, and was tasked with fixing the situation.
asciilifeform: mircea_popescu: phf posted one earlier
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
a111: Logged on 2018-09-27 09:34 diana_coman: http://barksinthewind.com/2018/vtools-keccak-regrind/ -> gotta ask here, phf, am I missing something or what Wednesday was that there in the first line meant to be?
a111: Logged on 2018-09-27 15:58 phf: i guess it's presumptuous on my part to think that it's exactly obvious how to take vtools and plug it directly into an existing v's, but that's all that's needed
a111: Logged on 2018-09-27 15:57 phf: i think v.pl is a venerable tool, it's battle tested, it has established interface, it's been worked on for three years now. i don't see any reason to throw it out.
mircea_popescu: so then. phf did a new ~vdiff~. and a very good one at that, from all i can see.
asciilifeform: mircea_popescu: just nao -- muscle-powered v a la diana_coman . this weekend would like to reword v.py to run on phf's components.
a111: Logged on 2018-09-27 15:50 phf: asciilifeform: you're just spreading fud, i don't know where to start unpacking this conversation
a111: Logged on 2018-09-27 15:36 phf: asciilifeform: but if you want a full "v replacement and i don't want to think about none of that" then just use esthlos's item. i believe he has a working keccak already
asciilifeform: ( asciilifeform plowed through the phf-vtronics thread when came back from voyage, and then second time when diana_coman requested keccak regrind, and both times failed to converge to correct answ re 'is there complete keccak vtron' )
a111: Logged on 2018-09-27 12:47 diana_coman: since I need to get the work done on this, I reground the UDP lib and I'll proceed from there; asciilifeform, phf and anyone else interested, keccak-patches are on my Code Shelf as usual: http://ossasepia.com/reference-code-shelf/#selection-477.0-477.19
asciilifeform: phf: exactly right algo
asciilifeform: phf: imho your approach , i.e. dispensing with gnupatch, is The Right Thing, historically there was quite a bit of grief from gnupatch's habit of eagerly attempting to apply an invalid (by vtronic lights) but 'partially ok' by barbarian lights patch ☟︎
trinque: phf: in principle I'm entirely in favor of the "unix philosophy" approach of simple, single-purpose tools
asciilifeform: phf: i finally sat down and properly read the thing, and i think i finally grasp.
trinque: however it'll need a vdiff too, so was going to pull in also phf's work
trinque: phf: did the problem which caused folks to have to delete one branch of your vpatch tree to press the other get fixed in v.pl?
a111: Logged on 2018-09-27 15:33 phf: asciilifeform: this has been extensively discussed in the logs. there was never a need for "new style v". v works just fine. one of the design goals of vtools was to nail down (and improve upon) the patch format. vtools are explicitly designed to be used with an existing v (for example i use it with v.py). vdiff produces wellformed vpatches and vpatch presses them ensuring that the format is valid and that the hashes stand. there's no
asciilifeform: btw phf , if you're willing to post your modified v.py ( i.e. http://btcbase.org/log/2018-09-27#1854990 ) i'ma sign ☝︎
asciilifeform: phf: makes sense.
asciilifeform: phf: ah huh
asciilifeform: phf: but yes i'ma revive it.
asciilifeform: phf: my orig vtron has been sad and unmaintained, and afaik unused by anybody by me, for long time
asciilifeform: phf: i don't dispute that it is obvious, but thought it had been done, this was my mistake.
asciilifeform: phf: right . what i was looking for is variant of same that calls out to keccak instead of sha512 ( mod6's latest vtron actually checks hashes ) . but apparently still needs baking.
asciilifeform: mod6: for nao i'll be entirely satisfied with the variant phf describes.
asciilifeform: phf: makes sense. my frustration is from walking the logs for past 2 days and looking for who has the complete shaft+head hammer, and not finding
asciilifeform: phf: loox like. i'ma put the head on the shaft in next coupla days .
asciilifeform: this thread is not meant to insult phf et al , but i open box where i thought was hammer, but there is only a hammer head
asciilifeform: phf: there is not currently a complete replacement for mod6 v.pl ! fact !
asciilifeform: phf: this is not a criticism of the format. but turns out asciilifeform has been looking for a 'i missed it in logz?' piece that doesn't exist quite yet ( hopefully will in 3 days... )
asciilifeform: phf: try an' see from my pov : i get a 'goddamn stop using old v' , go an' uncrate the replacement, and turns out it ain't a plug-in replacement but a set of pieces and a roll of duct tape
lobbesbot: phf: Sent 14 hours and 6 minutes ago: <asciilifeform> nm, distinguished by hand... but my vtron doesn't verify the sigs (not immediately sure why) and mod6's -- sees only Leaf: vtools_vpatch_newline.vpatch (phf)
lobbesbot: phf: Sent 14 hours and 10 minutes ago: <asciilifeform> are http://barksinthewind.com/2018/vtools-keccak-regrind/ old-style or new-style vpatches ?? my vtron won't press'em, and there is no way to distinguish , nor anything in the post to indicate, unless i'm thick
asciilifeform: if phf's item came with a standalone keccak hasher , would then be quite simple to retool e.g. mod6's vtron, to follow the new format. but as it is loox like i'ma have to wait for esthlos , to get full working replacement for old vtrons
diana_coman: I kept waiting on phf and esthlos since they were working on it as far as I could tell; and http://btcbase.org/log/2018-09-27#1854921 ☝︎
asciilifeform: http://btcbase.org/log/2018-09-27#1854935 << i did, phf reminded earlier ☝︎
diana_coman: since I need to get the work done on this, I reground the UDP lib and I'll proceed from there; asciilifeform, phf and anyone else interested, keccak-patches are on my Code Shelf as usual: http://ossasepia.com/reference-code-shelf/#selection-477.0-477.19 ☟︎
mircea_popescu: asciilifeform phf's thing presses fine, since at least june ( http://thewhet.net/2018/06/mp-wp-genesis-regrind/ )
diana_coman: http://barksinthewind.com/2018/vtools-keccak-regrind/ -> gotta ask here, phf, am I missing something or what Wednesday was that there in the first line meant to be? ☟︎
mod6: I took your tarball, dumped in the latest version of my vtron, dropped in the .wot (phf) and seals from what I had in my sandbox previously.
asciilifeform: maybe i'm thick, and didn't shuffle correctly, or wat. phf can i persuade you to give a working recipe ??
asciilifeform: !Q later tell phf nm, distinguished by hand... but my vtron doesn't verify the sigs (not immediately sure why) and mod6's -- sees only Leaf: vtools_vpatch_newline.vpatch (phf)
asciilifeform: !Q later tell phf are http://barksinthewind.com/2018/vtools-keccak-regrind/ old-style or new-style vpatches ?? my vtron won't press'em, and there is no way to distinguish , nor anything in the post to indicate, unless i'm thick
asciilifeform: ideally i simply switch vtron to phf's and it's omnivorous.
asciilifeform: tho possibly this was resolved, iirc phf's tool is able to eat old patches (with warning bell)
asciilifeform: would rather switch wholesale to phf's, since it apparently performs to satisfaction of diana_coman
asciilifeform: phf: i'm not especially attached to my ancient v, it suffered from several obvious sharp edges
asciilifeform: mod6: i've been using my orig vtron all this time. but recently diana_coman & mircea_popescu prodded, 'what's yer excuse for not moved to modern keccak-v' and i had no good counter, it's really time, so nao gotta actually uncrate phf's and make it go
mod6: mine does not do the graph-resolution as proposed by phf & esthlos.
mod6: <+diana_coman> asciilifeform, hm? I can't quite parse that q; if it helps: I'm using phf's vtools, yes << I'm a bit confused too. I'm still using my vtron.
asciilifeform: phf: noted, ty
diana_coman: asciilifeform, hm? I can't quite parse that q; if it helps: I'm using phf's vtools, yes
asciilifeform: diana_coman, mod6 , phf , et al : is the 'canonical' (i.e. most recent usable) oldv-tree of newstyle-v the one on phf's www ?
diana_coman: asciilifeform, I'm not aware of a converter but pinging phf to correct me if I'm wrong
asciilifeform: diana_coman: what's the fastest way to do this ? ( i.e. do you recall whether phf published his converter ? or do i gotta crank it manually )
asciilifeform: phf: lol was my 1st thought
ave1: phf: I suspect this modern systems has placed the C library and crt1.o etc in some wierd place
ave1: phf, your error is in the AdaCore gnat gcc (gcc -version shows these boron.a directories)
mircea_popescu: "phf: the problem with publishing ununderstood spew is that you're potentially publishing forever"
asciilifeform: 'See `config.log' for more details.' >> what's in there, phf ?
mircea_popescu: phf paste the spew ?
asciilifeform: ( hey phf ! )
asciilifeform: iirc phf has one too
a111: Logged on 2018-09-23 19:31 phf: ave1: thank you for investigation, i've gotten as far myself. there's an implicit global isystem that gets placed ahead of whatever isystem's you pass on command line. i've tried a variety of flags (e.g. --nostdinc), but didn't find the right combination yet. (the other way to discover it instead of using strace is to run the cpp -v command instead with most of the same arguments)
lobbesbot: phf: Sent 9 hours ago: <ave1> been running some tests on my system and it could be that an earlier step failed to install the header files correctly, could you run these commands and send me the output? http://p.bvulpes.com/pastes/EllTj/?raw=true
a111: Logged on 2018-09-23 10:30 ave1: !Q later tell phf, I've been running some tests on my system and it could be that an earlier step failed to install the header files correctly, could you run these commands and send me the output? http://p.bvulpes.com/pastes/EllTj/?raw=true
ave1: phf, http://btcbase.org/log/2018-09-23#1852924, I've tried on debian and I can reproduce the problem, Unfortunately I have no solution yet (it will probably be a patch). It seems the default/internal gcc spec defines "-isystem /usr/include/x86_64-linux-gnu ☝︎
ave1: !Q later tell phf, I've been running some tests on my system and it could be that an earlier step failed to install the header files correctly, could you run these commands and send me the output? http://p.bvulpes.com/pastes/EllTj/?raw=true ☟︎
asciilifeform: mircea_popescu: will add that, since we forked gcc, this is in principle fixable. ( tho it wouldn't help folx struggling to build the thing under heathen gcc -- e.g. phf currently -- i expect at some point we'll be done with 'build on heathen linux' )
a111: Logged on 2018-09-22 18:46 phf: asciilifeform: that i can see, but i'm not sure why it's picking up system wide includes. there's an isystem there that points to correct musl include tree, that has the sys/types.h file in it
asciilifeform: phf: you may have to strace and see wherethefuq it got it
asciilifeform: phf: gcc is pretty dumb, it will suck in anyffing it can see in the PATH, in ~random order
asciilifeform: phf: you gotta unset the typical gnat includes envir , e.g. here's asciilifeform's from 1 particular box, http://p.bvulpes.com/pastes/pUeES/?raw=true ( already has an ave1 gnat ,prior to that pointed to adacore's thing )
a111: Logged on 2018-09-22 11:15 ave1: phf: http://btcbase.org/log/2018-09-22#1852748, The second stage compilation of the gcc compiler is picking up the include files of the system (GNU clib specific and therefor incompatible).
a111: Logged on 2018-09-22 03:05 phf: ave1: i'm getting the following error http://p.bvulpes.com/pastes/49Tie/?raw=true when building ada-musl-cross-2018-06-01. i feel like it came up before, but i'm having hard time finding the thread
ave1: phf: http://btcbase.org/log/2018-09-22#1852748, The second stage compilation of the gcc compiler is picking up the include files of the system (GNU clib specific and therefor incompatible). ☝︎☟︎
lobbesbot: phf: Sent 7 hours and 3 minutes ago: <asciilifeform> plox to snarf 'errata' vpatch in http://www.loper-os.org/?p=2557 , ty
asciilifeform: !Q later tell phf plox to snarf 'errata' vpatch in http://www.loper-os.org/?p=2557 , ty
mircea_popescu: phf apparently the obviousness of who's whose daddy shines through even functionally illiterate, weed-whacked heads.
asciilifeform: phf: lol, 'will start'
mircea_popescu: phf the only sadness is that something as ridiculous as a sf-hack cult predated the republican infiltration of fbi etc.
asciilifeform: phf: against the indians, lol, if we go back enuff