log☇︎
3200+ entries in 0.027s
asciilifeform: unrelatedly, ave1 , diana_coman , mircea_popescu , phf , other folx with a gnat and 10min of free time -- asciilifeform would like to see outputs of http://www.loper-os.org/pub/ffa/thousand_muls.txt ( ch12 benchmark ) on various irons ☟︎
deedbot: diana_coman paid BingoBoingo invoice 1
deedbot: Invoiced diana_coman 0.15 << S.QNTR Auction winner
BingoBoingo: !!invoice diana_coman 0.15 S.QNTR Auction winner
BingoBoingo: diana_coman: Will do
BingoBoingo: diana_coman: I prefer Bitcoin. GPGgram me a destination for the shares and I will arrange delivery with Jurov. Thank you for your interest in Journalism.
asciilifeform: ohai diana_coman
auctionbot: Sell order # 1007 has ENDED: One lot of 14,500 S.QNTR shares SOLD to diana_coman for 150mn ecu. Attn: BingoBoingo
asciilifeform: diana_coman: sorta why asciilifeform wish list includes plain-files-on-disk blogotron -- then trivial to back up
mircea_popescu: mod6 from my pov, you've transparently rotated from not being able to add to not being able to read ; and should something like "alf, do not speak to diana_coman anymore" should issue for some reason, you'll just move on to ~same somewhere else.
a111: Logged on 2018-11-14 20:20 diana_coman: my understanding was that nobody actually LIKES oaep all that much but it's (again! another one of those!) the thing we have (as opposed to the thing we might wish for)
asciilifeform: pretty sure that diana_coman is on rk tho
asciilifeform: also iirc diana_coman and hanbot both have mp's-wp on rk , and i dun recall either of'em ever reporting OOM
mod6: <+diana_coman> mod6, re comment, it seems it got lost, I could not find it anywhere so not in queue nor anything << not a problem at all. we've resolved it anyhow. thanks for looking.
asciilifeform: diana_coman: it's the most economical, at the very least, algo that sorta does the job
asciilifeform: diana_coman: correct
asciilifeform: i in turn am working through diana_coman's oaep articles
asciilifeform: diana_coman: lemme know if you run into anyffing to any degree confusing.
asciilifeform: ohai diana_coman
asciilifeform: ohai mod6 , diana_coman , mircea_popescu
mod6: thanks for doing all this work diana_coman, I appreciate it. it's long over do for a v'ing. :]
mod6: <+diana_coman> mod6, I meant out of date wrt to my vpatch i.e. keccak hashes << ahh, gotcha
a111: Logged on 2018-11-14 10:54 diana_coman: and done: the updated .vpatch files and starter_v.zip + sigs are all up; I've checked them on my RK; genesis is the same and result is identical to V-2017; the result of 99993 .vpatch is identical to V-2018; the result of keccak_vtools vpatch is to update BOTH docs and code; re docs, I've nuked the user manual as I won't maintain it and it's becoming confusing due to being out of date; I've updated the quick_guide however, mainly for 1st t
a111: Logged on 2018-11-14 08:05 diana_coman: mod6, I don't see any comment from you on my blog, what happened? (re http://btcbase.org/log/2018-11-14#1872143 )
a111: Logged on 2018-11-14 07:55 diana_coman: the genesis IS on 99994K yes, the next vpatch upgrades it to 99993K and only THEN my own vpatch changes it to use Keccak and vtools
mircea_popescu: i meant diana_coman ah i see, you redid the whole tree, that was a patch.
a111: Logged on 2018-11-14 00:20 mod6: 2) http://btcbase.org/log/2018-11-13#1872126 << diana_coman I tried to leave you a note on your blog. But seems that you've based the genesis off of my vtron version 99994K, but there is a newer version: http://thebitcoin.foundation/v/V-20180222.tar.gz http://thebitcoin.foundation/v/V-20180222.tar.gz.mod6.sig Which is denoted as version 99993K.
a111: Logged on 2018-11-14 05:23 mircea_popescu: diana_coman where;d you end up with ye 2017 version from ? just used local copy, missed update ?
mircea_popescu: diana_coman where;d you end up with ye 2017 version from ? just used local copy, missed update ? ☟︎
asciilifeform: diana_coman: see #5 in particular
mod6: 2) http://btcbase.org/log/2018-11-13#1872126 << diana_coman I tried to leave you a note on your blog. But seems that you've based the genesis off of my vtron version 99994K, but there is a newer version: http://thebitcoin.foundation/v/V-20180222.tar.gz http://thebitcoin.foundation/v/V-20180222.tar.gz.mod6.sig Which is denoted as version 99993K. ☝︎☟︎
asciilifeform: ty for the help, diana_coman , phf , et al
asciilifeform: diana_coman: confirmed, worx, a++++
asciilifeform: diana_coman: vk.pl doesn't find the vpatch executable in the current dir ( this is not hard to fix tho, i'ma fix )
a111: Logged on 2018-11-13 21:36 asciilifeform: http://btcbase.org/log/2018-11-13#1872052 << i'ma hold off on posting http://btcbase.org/log/2018-11-13#1871779 item , then, so that i can link to diana_coman's vtron
a111: Logged on 2018-11-13 21:00 diana_coman: mircea_popescu, it's part and parcel of the promised write-up http://btcbase.org/log/2018-11-13#1871705
asciilifeform: http://btcbase.org/log/2018-11-13#1872052 << i'ma hold off on posting http://btcbase.org/log/2018-11-13#1871779 item , then, so that i can link to diana_coman's vtron ☝︎☝︎☟︎
a111: Logged on 2018-11-13 08:10 diana_coman: fwiw I actually patched v.pl to use phf's vtools and it works absolutely fine; I guess I'll write-it up and publish the whole thing later today if nobody else does it
mircea_popescu: http://btcbase.org/log/2018-11-13#1871781 << one of you, diana_coman phf mod6 asciilifeform do me a favour and properly genesisize v.pl huh! ☝︎
a111: Logged on 2018-11-13 08:10 diana_coman: fwiw I actually patched v.pl to use phf's vtools and it works absolutely fine; I guess I'll write-it up and publish the whole thing later today if nobody else does it
ave1: asciilifeform, diana_coman: I'm now looking into arm 64bit, but so far seems to be bit more involved. I've not found a way to directly couple an ada varable to a register.
bvt: diana_coman: i have updated the article with links to the logs. i confirm that using -std=gnu89 fixes the issue. -std=c89 -- does not.
asciilifeform: ty diana_coman
a111: Logged on 2018-10-06 14:31 diana_coman: I'll soon do the regrind of eucrypt to move it on to keccak hashes; my plan is to keep the patches precisely as they are otherwise (i.e. including NO manifest until I actually added it at the end); the way I see it, it's just a swap-in-place of one hash for another; if anyone sees this sort of thing differently - since I'm hmmm,first to regrind a big project? - yell now !
asciilifeform: currently looking into how diana_coman did it
asciilifeform: diana_coman: neato
a111: Logged on 2018-11-12 11:15 diana_coman: and ugh, bvt , your wp ate part of my comment! there was more between "used by gcc 4.9" and " they want. " wtf
a111: Logged on 2018-11-12 09:32 diana_coman: anyway, trinque, would you add bvt's blog to deedbot's feed please?
a111: Logged on 2018-11-12 11:22 diana_coman: I suppose it's the gcc >4.9 that made it eat up the whole part as "html"
asciilifeform: oh hm diana_coman already noted
auctionbot: Sell order # 1007: One lot of 14,500 S.QNTR shares Heard: 150mn from diana_coman outbidding mircea_popescu. Ending: 2018-11-15 16:25:23.664854 UTC (86 hours 31 mins)
bvt: diana_coman: ah, i see. if the c89 vs c99 is the issue, than this vpatch takes the wrong approach, and something along the lines of http://p.bvulpes.com/pastes/o7yc9/?raw=true would work better
asciilifeform: diana_coman: it's the correct model for ~some~ devices
asciilifeform: diana_coman: the 'not worth writing 500 ln so that record can be eaten/shat in 1 line' formulation
asciilifeform: ( had stream-powered serializer-deserializer for the 'varint' type, errything else did diana_coman-style )
asciilifeform: diana_coman: fwiw it's exactly where i ended up drawing the line in 'nqb'
asciilifeform: ^ mircea_popescu , diana_coman , other potential ffa eaters ^
mircea_popescu: diana_coman screw that, what "tries"
a111: Logged on 2018-11-10 19:29 diana_coman: http://btcbase.org/log/2018-11-10#1870634 -> lol, I'll fix
asciilifeform: btw diana_coman , i repeatedly refer to 'nqb' but it not yet got genesis'd, i did however gnathtml-ize it for reference : http://www.loper-os.org/pub/nqb/index.htm fwiw
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
diana_coman: this is what I had in mind; it helps but: diana_coman> in which case fine, it can perhaps even work like that for most messages except stuff that has max>message size and/or stuff that has meaningful data *after* this variable part
mircea_popescu: diana_coman the reason n is there is to tell you how much data is useful. what if you fixed n to max at depack size, and then delivered n=max records to application, and it is ITS job to discard the extras ?
mircea_popescu: diana_coman specifically, why doesn't http://trilema.com/2018/euloras-communication-protocol-restated/#selection-195.0-195.48 simply say "from 1 to 15" or w/e it is ?
a111: Logged on 2018-11-10 16:43 mircea_popescu: diana_coman is the structure actually problematic ?
mircea_popescu: diana_coman would it be smart if i defined the count types narrowly ? ie, bitwise ?
a111: Logged on 2018-11-10 17:00 mircea_popescu: diana_coman your guy has smileys kek.
a111: Logged on 2018-11-10 16:52 asciilifeform: diana_coman: and while we're nitpicking, Serpent message types can be an enumeration (see barnes)
mircea_popescu: diana_coman your guy has smileys kek. ☟︎
asciilifeform: in diana_coman's article
asciilifeform: diana_coman: and while we're nitpicking, Serpent message types can be an enumeration (see barnes) ☟︎
asciilifeform: diana_coman: btw the LSB/MSB/LMSB thing can be made slightly clearer / less-ctronic by actually making'em into 1-bit members of the record; gnat will do The Right Thing re padding
mircea_popescu: diana_coman is the structure actually problematic ? ☟︎
asciilifeform: diana_coman: imho mircea_popescu's protocol is simple enuff , however, that it doesn't make a gigantic difference that you walk the records explicitly, in re complexity of proggy
asciilifeform: diana_coman: ' I admit I am still not 100% sure of the actual, exact representation of such a record containing itself parametrized records since my understanding is that Ada will allocated maximum space (i.e. space to fit potentially the largest structure) ' >> i dug into this when baked 'nqb'. what it does is exactly this, recursively ( for ~each~ subrecord, allocates the maximum possible size ; ditto any subrecords. ) the represen
asciilifeform: diana_coman: loox like
asciilifeform: diana_coman: yea, d00d is a greybeard medical doc
asciilifeform: diana_coman: it is, and still appears in modern ru, e.g. for pope Иоанн Павел II etc
asciilifeform: diana_coman: ok good
a111: Logged on 2018-11-08 17:40 asciilifeform: btw, diana_coman were you able in the end to make sense of the http://www.loper-os.org/?p=2675 proof ? ( mircea_popescu's s.mg broadcast implies that yes -- but thought i oughta ask conceretely )
asciilifeform: btw, diana_coman were you able in the end to make sense of the http://www.loper-os.org/?p=2675 proof ? ( mircea_popescu's s.mg broadcast implies that yes -- but thought i oughta ask conceretely ) ☟︎
asciilifeform: yea makes sense. diana_coman made same observation earlier
asciilifeform: diana_coman: i'm sorta used to the 'eek', having a daytime saecular work that happens 100% in sewer
asciilifeform: diana_coman: ikr ?
asciilifeform: diana_coman: so far the only place i've used it, is c glue
asciilifeform: diana_coman: it's safe (i.e. endianism-proof) if you actually nail down the layout of the record (see barnes re how)
asciilifeform: diana_coman: either this, or the 'unchecked conversion' you had earlier (given that you specify a fixed size for the record, you will always end up with the given number of octets, it has no failure mode)
asciilifeform: diana_coman: http://www.adaic.org/resources/add_content/standards/12rm/html/RM-B-3-3.html
asciilifeform: diana_coman: hrm, why wouldja ~have~ to use streams ?
a111: Logged on 2018-10-16 13:56 diana_coman: at any rate when I get to the records I might come and whine loudly if I get stuck
mircea_popescu: diana_coman http://p.bvulpes.com/pastes/Phfs3/?raw=true
a111: Logged on 2018-11-06 23:57 asciilifeform: btw in case other folx ( diana_coman ? ) want to make these for ~their~ proggies, process is pretty simple :
asciilifeform: btw in case other folx ( diana_coman ? ) want to make these for ~their~ proggies, process is pretty simple : ☟︎
asciilifeform: neato, ty diana_coman
a111: Logged on 2018-11-05 09:56 diana_coman: http://btcbase.org/log/2018-11-04#1869273 - a config file seems the better choice, yes; I'll add it to the list to move the keys to a config file and update the tests to read from config file; that should actually meet asciilifeform's requirements too since the code will not contain the >80cols lines (although the config files will, of course)
mircea_popescu: diana_coman seems the reasonable available goat-and-cabbage pacifier
a111: Logged on 2018-11-04 23:10 mircea_popescu: diana_coman imo such items belong in a config file then. though he prolly wants the ~config~ file to also be "human readable" by which he means hard-paged at 80 cols like for idiots. because there's no such thing as a terminal, nor user settings, and i gotta format my text in a way that's aware of his dumb terminal. and he thinks this acceptable, somehow, that at the time i write i must bear in mind how he'll later read.
asciilifeform: mircea_popescu: diana_coman's are already 900+
mircea_popescu: diana_coman imo such items belong in a config file then. though he prolly wants the ~config~ file to also be "human readable" by which he means hard-paged at 80 cols like for idiots. because there's no such thing as a terminal, nor user settings, and i gotta format my text in a way that's aware of his dumb terminal. and he thinks this acceptable, somehow, that at the time i write i must bear in mind how he'll later read. ☟︎
a111: Logged on 2018-11-04 18:32 diana_coman: it still seems at best silly to manually split strings that one would than have to merge if they want to use as such somewhere else