log
▁▁▁▁▁⏐︎▁▁▁ 6403
asciilifeform: bvt: the only new instrs that seem to be even theoretically of use, are 'mulx' and 'adcx' -- but i dun have any iron that supports these atm, and cannot even begin to say whether constant time etc
asciilifeform: http://p.bvulpes.com/pastes/ncZvu/?raw=true << details, for anyone who gives a shit
asciilifeform: http://www.loper-os.org/pub/amd64_mulx.jpg << amd seems to support ~currently~, but dun say from what date of chip specifically
asciilifeform: fwiw it's still a 64bit mul, the only win is that it dun set any flags (and therefore keeps the pipe flowing)
asciilifeform: ftr asciilifeform suspects that 99% of what can be won from asmism in ffa, can be had simply from bvt's existing 64bit mul, plus doing adc for the additions-with-carry instead of the manually-cranked carry calc, and that all 'fancy' instructions will only lead to sad
asciilifeform meanwhile found today mistake in 17 , and expects it'll take several days to rewrite
asciilifeform: and meanwhile2, we have answr to above quandary, 'In 2017, BMI2 was further incorporated in AMD's Zen-architecture...'
asciilifeform: ... so 'mulx' aint in anyffing i have. if someone wants to test it with own hands, he can, otherwise fughetit.
asciilifeform: ftr an 'iron ffa' cpu does not even require a massive multiplier . even a microcoded ffa-style thing that lets you specify 'and at memory x there is a w-word int, and at y a w word int, add'em' etc , would still massively win over the extant liquishit, it would do the arithm atomically, without invoking branchpredictor, losing cache, etc.
asciilifeform: but no prizes for guessing why it aint on the market.
asciilifeform: ( 'you want fast crypto, plebe? here, buy nsa-certified(tm)(r) cryptoaccelerator card from ibm' )
asciilifeform: remember, only a terrorist(tm)(r) 'writes own crypto', 'good citizens use openssl' etc etc
mircea_popescu: http://btcbase.org/log/2019-03-09#1901062 << very much this. "oh, couldn't POSSIBLY spare another bus width for a FULL mult result. NEVERTHELESS... can fucking spare eight trillion bus widths to specify instruction length. it's 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000101 and not a mere fucking 0000000000000000000000000000000000000000000000000 ☝︎
a111: Logged on 2019-03-09 22:38 asciilifeform: if you ever wonder why your x64 iron draws 50x the wattage to do same thing as e.g. rk, wonder no longer -- the insanity where shit gets moved around to accomodate idjit instructions with fixed in/out hoppers, the insanity where you gotta set prefixes to specify what width ~each operand~ is (why this is needed ? srsly) , all of this adds up to 3bil transistors that heat the room
mircea_popescu: 000000000000101!!! NOW THAT IS IMPORTANT!!!
mircea_popescu: http://btcbase.org/log/2019-03-09#1901064 << in quite related news : went to flagship mall in this country, escazu multiplaza (escazu being where the us embassy compound lies, and all the retarded gringos live, very miami real estate racket reservation), and guess what ? there's no ipad store. AT ALL. instead, huawei dominates both in advertising (these large floating banners) and location (top floor store, only one to sell c ☝︎☟︎
a111: Logged on 2019-03-09 22:40 asciilifeform: when you build 1 of these things, there's a set of decisions that end up determining shape of whole thing; and it so happens that intel made ~all~ of the most retarded possible choices.
mircea_popescu: ellphones).
mircea_popescu: jobs' been dead what, a decade ? not even a decade. meanwhile, fifty FUCKING MORONS sat around in rooms pompously pretending as to how "of course i'm teh vp, didn';t you see the sign on the door ?"
mircea_popescu: vp of motherfucking what, exactly ? "how to give away the market to the azns" ? that's a skill ? ☟︎
mircea_popescu: any fucking monkey picked out in the street could have made ~just as good~ a "corporate executive" as the fucktards apple hired -- and somehow nobody is telling them this. and of course the idiots don't have the werewithal to look in the mirror, "if plumbers were as good at plumbing as we are at executiving, we'd be quite literally swimming in the shit we're metaphorically drowning in!" ☟︎
mircea_popescu: this is the fucking problem of socialism, when that wanna-be alt-hilary stupid cow asks "if the government can print money to rescue wall street, why won't it print money to let the chitlins enjoy the college lifestyle free of charge (and permanently!)" she has a fucking point -- and the entirely similar stup ☝︎
a111: Logged on 2017-03-15 00:29 mircea_popescu: pretty fine example of exactly why warren was so vocal (item was strictly a barony created so elizabeth warren could be barron OF SOMETHING). this cfpb item spent 55mn on "renovations" of its hq, ie more than the gsa spent that year on everything the usg owns ; spent immensely on travel (which is not something they do). the chairman is supposed to not be removable by the president except "for cause" (meanwhile that got strick
mircea_popescu: id cow "from twitter" explaining @whatever conference "how serious they take banning" blinks incomprehendingly just as she's done with her soundbytes. yeah, why is it ??? there's entirely no difference between any of them and any other aspiring-writers-in-new-york, philosophy of art history studies rejects the world over. why those, why not these ? blink blink ?
mircea_popescu: dude check me out, by now i'm writing 500 word chatlines. this isn't going well.
mircea_popescu: but on a more optimistic note, that's probably the most anyone cared about anything to do with the topic or the persons named or otherwise referred to in their entire history. that should count for something.
mircea_popescu: http://bvt-trace.net/2019/03/ffa-chapter-9-homework-comba-in-x86_64-assembly/#selection-15.295-19.176 << why this, specifically ? is there no ada asm calling method besides this ? ☟︎☟︎
mircea_popescu: 7% gains, not even that huge. ☟︎
mircea_popescu: but speaking of those design decisions, by my current thinking the ideal processor is defined as follows : the bus width is 512bits ; therefore the byte is 512bits. the processing core is a state machine, with 512 byte-sized registers. a processor is composed of 512 + 8*9 such cores. for convenience imagine them organized in a cube, 8x8x8, with an extra 64 item layer on three sides. ☟︎
mircea_popescu: the 512 "central" cores are state machines that can do add or mul, and always proceed ~on their entire register set~. so if you don't want to multiply 131072-bit numbers, just put in zeros ; and if you put larger numbers in there you'll just get the LAST 262144 bits of the result, is all.
mircea_popescu: the 64 "flat outer" cores are state machines that can do mvin and mvout -- taking registers to memory or memory to registers, ie use the bus. only, of course, for the state machines inside their ~projection~. ☟︎
mircea_popescu: the remainder 8 "sharp outer" cores control the flats, by moving things in and out of ~their~ registers.
mircea_popescu: memory, of course, starts with byte 299008 (584 * 512) and extends as far as 512 bits bus can address, if you're installing that. meaning, all core registers are allocated as memory anyways. and that's fucking it. ☟︎
mircea_popescu: i ~can't imagine~ what the fuck must have been going through the skull of whoever came up with "working a piece or moving the worked piece, same thing". what the fuck ever is it same thing! ☟︎
asciilifeform: ohai mircea_popescu
asciilifeform: http://btcbase.org/log/2019-03-10#1901101 << recall, ave1 found that the asm inlining was ~yet another~ item partially broken in ye olde gnat ( iirc it dun let you assign registers deterministically ) ☝︎
a111: Logged on 2019-03-10 02:44 mircea_popescu: http://bvt-trace.net/2019/03/ffa-chapter-9-homework-comba-in-x86_64-assembly/#selection-15.295-19.176 << why this, specifically ? is there no ada asm calling method besides this ?
asciilifeform: http://btcbase.org/log/2019-03-10#1901090 << i was convinced somehow that crapple stores exist only in the reich ☝︎
a111: Logged on 2019-03-10 02:22 mircea_popescu: http://btcbase.org/log/2019-03-09#1901064 << in quite related news : went to flagship mall in this country, escazu multiplaza (escazu being where the us embassy compound lies, and all the retarded gringos live, very miami real estate racket reservation), and guess what ? there's no ipad store. AT ALL. instead, huawei dominates both in advertising (these large floating banners) and location (top floor store, only one to sell c
asciilifeform: ( possibly am mistaken about this ? )
asciilifeform: think, where else are idjits gonna ~lease~ ( the new crapple thing! not even buy, lease.. ) a brick for its weight in gold
asciilifeform: http://btcbase.org/log/2019-03-10#1901102 << see the comments ☝︎
a111: Logged on 2019-03-10 02:46 mircea_popescu: 7% gains, not even that huge.
asciilifeform: he's on ch9, where no barrett, ~80% of the cpu eaten by knuthian div.
asciilifeform: http://btcbase.org/log/2019-03-10#1901103 << i cannot resist to bite : why 512 ? ☝︎☟︎
a111: Logged on 2019-03-10 03:02 mircea_popescu: but speaking of those design decisions, by my current thinking the ideal processor is defined as follows : the bus width is 512bits ; therefore the byte is 512bits. the processing core is a state machine, with 512 byte-sized registers. a processor is composed of 512 + 8*9 such cores. for convenience imagine them organized in a cube, 8x8x8, with an extra 64 item layer on three sides.
asciilifeform: http://btcbase.org/log/2019-03-10#1901105 << this is sorta how hillis's 'connection machine' worked. was pretty neat. ☝︎
a111: Logged on 2019-03-10 03:02 mircea_popescu: the 64 "flat outer" cores are state machines that can do mvin and mvout -- taking registers to memory or memory to registers, ie use the bus. only, of course, for the state machines inside their ~projection~.
asciilifeform: the thing with gigantic multers is that they grow physically with the cube of the bitness. hence scarce. ( tho i dun imagine even a 8192bit single-cycle multer would be remotely near as heavy as the 3bil-transistor 'let's fry eggs' pentium-xxviii or whatnot )
asciilifeform: http://btcbase.org/log/2019-03-10#1901108 << pipelineism, branchpredictionism, etc., all these heresies, were birthed from the fact that speed of memory fell massively behind that of cpu, in the time it takes to fetch ~anything~ you can do five digits of clock cycle ☝︎
a111: Logged on 2019-03-10 03:04 mircea_popescu: i ~can't imagine~ what the fuck must have been going through the skull of whoever came up with "working a piece or moving the worked piece, same thing". what the fuck ever is it same thing!
asciilifeform: so they 'let's find sumthing to do'.
asciilifeform: aaaanyfffing but get rid of the idjit von neumann bottleneck and bake micro-cpus into the ram
asciilifeform: cuz It Would Be Wrong (tm)(r)(uncle al)
asciilifeform: http://btcbase.org/log/2019-03-10#1901095 << rando monkey from the zoo would make 9000x better director than the catamite d00d ( recall, what he was in charge of prev. : rounding the corners on the 'ui'.. ) ☝︎
a111: Logged on 2019-03-10 02:24 mircea_popescu: any fucking monkey picked out in the street could have made ~just as good~ a "corporate executive" as the fucktards apple hired -- and somehow nobody is telling them this. and of course the idiots don't have the werewithal to look in the mirror, "if plumbers were as good at plumbing as we are at executiving, we'd be quite literally swimming in the shit we're metaphorically drowning in!"
asciilifeform: http://btcbase.org/log/2019-03-10#1901094 << with or without crapple, asia laffs allthewaytothebank -- it aint as if crapple bricks are made somewhere other than shenzhen ☝︎
a111: Logged on 2019-03-10 02:23 mircea_popescu: vp of motherfucking what, exactly ? "how to give away the market to the azns" ? that's a skill ?
asciilifeform: http://btcbase.org/log/2019-03-10#1901107 << 2^512 bits weigh approx what galaxy weighs, try it ☝︎
a111: Logged on 2019-03-10 03:02 mircea_popescu: memory, of course, starts with byte 299008 (584 * 512) and extends as far as 512 bits bus can address, if you're installing that. meaning, all core registers are allocated as memory anyways. and that's fucking it.
asciilifeform: ( at current or even hypothetical magic '1 atom per' density )
asciilifeform: ( not even speaking here of 512^512... )
asciilifeform: i dun expect to even live to see with own eyes a machine where 64bits of addr space fully populated (on current x64 Official standard, only 48 addr lines even connected, the rest mandatory 0)
asciilifeform bbl, maffs then meat
mircea_popescu: o right the registers. i recall.
mircea_popescu: http://btcbase.org/log/2019-03-10#1901119 << because 8 cubed. ☝︎☟︎
a111: Logged on 2019-03-10 03:21 asciilifeform: http://btcbase.org/log/2019-03-10#1901103 << i cannot resist to bite : why 512 ?
mircea_popescu: asciilifeform so i take it your ideal cpu would actually be simply state machines + registers, no actual ram ? ☟︎
diana_coman: http://btcbase.org/log/2019-03-09#1901066 -> I ran those and I got exactly the same genesis.vpatch (i.e. diff on this vs the one obtained from the script itself returned empty) ☝︎
a111: Logged on 2019-03-09 22:43 trinque: diana_coman, other folks that have cuntooed, can y'all confirm that the paths that ended up in your genesis.vpatch do not in fact exist? I'd like you to reproduce the commands starting at line 114 of scripts/make_portage_tree.sh in your build directories, i.e. cd ~/src/cuntoo/build/cuntoo and then run them, as root
diana_coman: onth in unexpected results and assorted ugh: vdiff ends up in stack overflow ran on those ☟︎
diana_coman: trinque, which are exactly the paths that don't match? since I don't have the original genesis.vpatch I can't really know what to check to look if indeed those paths actually exists or not or wtf
mircea_popescu: asciilifeform thinking about whart you said, i can't repress the suspicion that maybe the memory model is acrtually profoundly fucked,as a central driver of the whole cs insanity. ☟︎
mircea_popescu: ie, that structured data should really be much better hardware supported, that memory should include much more processor per storage cell, that in fact memory should look a lot more like trees than the current flat, democratic lines of "all cells are equal" ☟︎
mircea_popescu: ie, socialism fails yet again, and calling itself "democracy" dun help anything -- flat is fail, no two ways about it.
mircea_popescu: trinque no deedbot ?
mircea_popescu: http://btcbase.org/log/2019-03-10#1901145 << say this again ?! vdiff blows the stack when processing the two diffs ? ☝︎
a111: Logged on 2019-03-10 15:10 diana_coman: onth in unexpected results and assorted ugh: vdiff ends up in stack overflow ran on those
mircea_popescu: perhaps the correct republican approach is not to bake cpu, but to ~bake memory~. why even bother with the whole turdpile that's ddr init when could simply have sane ram, and rk with it. ☝︎☟︎
a111: Logged on 2018-09-25 00:39 asciilifeform: the only binball is that coupla kB of ddr ram init thing.
mircea_popescu: make a 18446744073709551616 byte ram arm board, for the keks.
mircea_popescu: 16 exabytes ftw!!!
asciilifeform: http://btcbase.org/log/2019-03-10#1901142 << programmable interconnect fabric ( similar to what's sold as fpga ) . iirc i detailed this in old thrd. ☝︎
a111: Logged on 2019-03-10 08:23 mircea_popescu: asciilifeform so i take it your ideal cpu would actually be simply state machines + registers, no actual ram ?
asciilifeform: http://btcbase.org/log/2019-03-10#1901147 << it indeed is, and in precisely the way described. ☝︎
a111: Logged on 2019-03-10 16:42 mircea_popescu: asciilifeform thinking about whart you said, i can't repress the suspicion that maybe the memory model is acrtually profoundly fucked,as a central driver of the whole cs insanity.
asciilifeform: http://btcbase.org/log/2019-03-10#1901148 << imho the ( ~homogeneous~ variant of ) fpga is actually the correct model. i.e. you get to stitch it later into however many parallel mechanisms you happen to need on a given occasion. ☝︎
a111: Logged on 2019-03-10 16:43 mircea_popescu: ie, that structured data should really be much better hardware supported, that memory should include much more processor per storage cell, that in fact memory should look a lot more like trees than the current flat, democratic lines of "all cells are equal"
asciilifeform: http://btcbase.org/log/2019-03-10#1901153 << bake 'pile of reconnectable flipflop' and then you aint gotta ever bake anyffin else again. iirc i detailed this in ancient thread, mircea_popescu barfed ( iirc answered 'why waste so many transistor on interconnects' ) , but can't currently dig up where we had this ☝︎
a111: Logged on 2019-03-10 17:02 mircea_popescu: perhaps the correct republican approach is not to bake cpu, but to ~bake memory~. why even bother with the whole turdpile that's ddr init when could simply have sane ram, and rk with it.
asciilifeform: http://btcbase.org/log/2019-03-10#1901140 << the down side of 'let's 512b bus' is that most cpu time (where it runs, not counting idles on i/o here) is spent in 'inner loops' where yer counting to e.g. 3. and nao you gotta move 512bits when yer counting to... 3 ☝︎
a111: Logged on 2019-03-10 05:07 mircea_popescu: http://btcbase.org/log/2019-03-10#1901119 << because 8 cubed.
diana_coman: mircea_popescu, yes, vdiff on the 2 genesis.vpatch files overflows the stack; while on same machine and same files, diff seems to have no such trouble
mircea_popescu: phf ^ ?
asciilifeform: ( the style of programming that would appear on ' asciilifeform's ideal cpu ' is best illustrated in http://btcbase.org/patches/fg-genesis/tree/fg.v . i.e. all of the independent pieces in fact run in parallel, and in deterministic time, there are no interrupts, no scheduler, etc. )
asciilifeform: mircea_popescu: we found that vdiff overflows during http://btcbase.org/log/2018-10-20#1864346 ☝︎
a111: Logged on 2018-10-20 01:44 asciilifeform: !Q later tell phf i found today that your keccak-vdiff is unable to eat a 40MB file ( dies politely with stack overflow )
asciilifeform: phf promised to fix, but then went on his ill-fated voyage
diana_coman: asciilifeform, ftr this is a 4.7MB file
diana_coman: and yes, I had this idea in my head that "previous problem, was solved"
asciilifeform: diana_coman: i do not presently know where is the barf threshold, i suspect it depends on yer stack size
asciilifeform: i'd like to see phf come back to life and fix. failing this, 1 of us will have to ☟︎
mircea_popescu: asciilifeform that was size, this is ???
mircea_popescu: diana_coman try it with the megastack size from before, calling tests ?
diana_coman: ulimit -s sez 8192
asciilifeform: diana_coman: iirc it throws whole file on the stack, but then also keccak eats stack
diana_coman: mircea_popescu, this is a different machine, the cuntoo-guinea pig
asciilifeform: so hard to say 'on napkin' what mass chokes it
diana_coman: I can give it unlimit stack anyway and see what happens, sure
diana_coman: yep, unlimited stack -> fine
diana_coman: (i.e. it runs, it returns fine, no differences between the files)
asciilifeform: !Q later tell phf fughet for nao about http://btcbase.org/log/2019-03-01#1899897 , but wouldja pleez fix vdiff ? and tell us what sorta swamp yer stuck in, what wouldja need to get to surface ? ☝︎
a111: Logged on 2019-03-01 08:57 phf: asciilifeform: give me until end of march to resolve it one way or another, feel free to neg rate me then
lobbesbot: asciilifeform: The operation succeeded.
asciilifeform: diana_coman: i think he's trapped in some sorta cube hell; the squarebracket thing mircea_popescu asked for also not happened yet etc
asciilifeform: trinque: deedbot dead ??
asciilifeform: diana_coman: the 'errything on stack' approach has its limits; it is why i wrote the mmap thing (currently stuck in limbo , but i'ma have to revive it and fix, cuz ffa 17 also is hitting against this wall, you can't expect to put 100MB on stack, you gotta mmap it
asciilifeform: i'ma detail, ftr : 'ffacalc' runs 'as fed', i.e. 1 command at a time. but 'peh' , adult version, has support for functions and loops, and therefore requires the 'tape' to exist in memory. so currently i have 'tape can be 1000000 bytes', but this is not acceptable obv. in the long term
asciilifeform: so it will have to have the mmap routine. ☟︎
asciilifeform wonders if phf hung on waiting for asciilifeform to fix the mmap lib
asciilifeform: mmap is the obv. logical method to handle multi-MB inputs for e.g. vdiff , without introducing heapisms
asciilifeform: tho not neccessarily required, in vdiff, the process as i understand it does not actually demand random access to the entire input
mircea_popescu: diana_coman see, if it is broken code, then it just eats all stack available. but i suspect here code is sound, demand on stack defensibly large.
mircea_popescu: the whole "low stack by default" thing is a low level "let's stimulate heap usage", in the same exact way the empire of smegma would impose a high import tax on soap.
mircea_popescu: asciilifeform it's not at all evident vdiff is broken. what'd you have him do ?
asciilifeform: mircea_popescu: ideally, mmap the inputs ☟︎
diana_coman: mircea_popescu, yes, I don't suspect the code is broken as such but it is a limitation of the approach and I did not really expect bumping into it at 7MB
diana_coman: I don't recall it being discussed in detail (i.e. with numbers for stack size and input size) anywhere and I think it should be, if it stays as it is
mircea_popescu: well, stack by default is small.
mircea_popescu: asciilifeform imo it is the job of the kernel to expose all available memory (ram, and fucking hell, disk, too, ALL available memory) to me as i fucking want it : stack, cpu registers, heap, whatever it is i wanna call it.
mircea_popescu: ie, yes "ideally mmap it", but not i! it.
asciilifeform: mircea_popescu: kernel ( linus's , that is ) -- exposes. the tricky bit was/is the ada glue.
asciilifeform: !#s horsecocks
a111: 28 results for "horsecocks", http://btcbase.org/log-search?q=horsecocks
asciilifeform: ^ the various drafts of this item
mircea_popescu: myeah.
BingoBoingo: asciilifeform: It's march 10th, what is the window for a supply run looking like and what issues appear to be blocking?
asciilifeform: BingoBoingo: currently hands full restarting ffa conveyor; however will be ordering irons in next 2 wks, and scheduling flight when the items with least predictable shipment windows are in hand
BingoBoingo: asciilifeform: Aite. We don't do these very often yet, so getting things in hand trumps getting plane ticket arranged.
asciilifeform: BingoBoingo: i'd ~really~ like to avoid the scenario where i go out with a half-empty crate
BingoBoingo: Right. Half empty crates are for testing new couriers.
mircea_popescu: can i help you guys with anything ?
asciilifeform: mircea_popescu: possibly you have an iron that wants to go in the crate ?
asciilifeform: i'm reluctant to do the massive rk thing until we have a semblance of working gnat for arm
mircea_popescu: that makes sense.
mircea_popescu: i don't really, and besides my/our policy has mostly been to have pizarro own iron, hence the snsa sale etc.
asciilifeform: we also host owner-operated iron (e.g. dulap is still snsa ; and trinque has some, and mod6 )
asciilifeform: ^ this goes for other folx! bring out thy irons.
asciilifeform bbl : meat chores
mircea_popescu: true enough. nevertheless, in my view owning iron helps give pizarro some meat on its bones.
phf: http://btcbase.org/log/2019-03-10#1901176 << i'll put it to the top of the stack, i remember fixing it, but never completing the patch. ☝︎☟︎
a111: Logged on 2019-03-10 17:40 asciilifeform: i'd like to see phf come back to life and fix. failing this, 1 of us will have to
lobbesbot: phf: Sent 2 hours ago: <asciilifeform> fughet for nao about http://btcbase.org/log/2019-03-01#1899897 , but wouldja pleez fix vdiff ? and tell us what sorta swamp yer stuck in, what wouldja need to get to surface ?
BingoBoingo: <mircea_popescu> true enough. nevertheless, in my view owning iron helps give pizarro some meat on its bones. << That it does
phf: the problem is that our ada keccak explodes whatever char buffer it gets into an array of octets, which means that, while diff keeps the size of chunks under some particular value, keccak explodes that value x8
phf: rather not array of octets, but array of bits
trinque: diana_coman: http://p.bvulpes.com/pastes/rWreS/?raw=true << here's the diff of your genesis and mine again
trinque: you'll notice it thinks your home dir is sitting in the profiles dir, which is mighty strange! maybe it is?
phf: http://btcbase.org/log/2019-03-10#1901200 << that is not at all the problem. i can read the file just fine, but as i do i feed chunks of it to keccak. keccak doesn't take char buffers, it wants "bitstream" i.e. arrays of bits, which means whatever char ☝︎☟︎
a111: Logged on 2019-03-10 18:09 asciilifeform: mircea_popescu: ideally, mmap the inputs
phf: buffer needs to be converted to 8x bitstream, which is in turn allocated on the stack
phf: there are three possible solutions, a) make sure that stack is arbitrarily large b) feed keccak buffers no larger than some magic size c) rewrite keccak to operate on char arrays directly without the need for bitstream allocation ☟︎
phf: ksum right now works for any sized file, because it goes the b) route: http://btcbase.org/patches/vtools_tempfile_standalone_notmp/tree/vtools/src/ksum.adb#L12
diana_coman: trinque, that's weird; fwiw: no, my home dir as far as I can see is *not* in the profiles directory
trinque: seems as though there's a dereferenced symlink munged into the path.
diana_coman: trinque, this is probably having to do with the drive being external, connected via USB and how it's mounted, I don't see any other explanation
trinque: thing is, my src directory is also a mount on my dev machine.
mod6: <+asciilifeform> we also host owner-operated iron (e.g. dulap is still snsa ; and trinque has some, and mod6 ) << The Foundation's 2nd box ("lovelace") is with ben_vulpes, currently. He's going to find a home for it in his new area, last we had talked about it. I don't have any machines on-hand that are waiting to go to .uy. However, I might be interested in buying a UY1 style machine from alf...
trinque: diana_coman: I'm running again with a vdiff pressed to http://btcbase.org/patches/vtools_ksum per http://btcbase.org/log/2018-12-03#1878057 ☝︎
a111: Logged on 2018-12-03 21:48 diana_coman: hm, if it's indeed the tmp thing, it might be worth a try to press vtools to current leaf (i.e. vtools_tempfile_standalone or _notmp) and see if that cures it; my archive contains pressed vtools to ksum patch only, not further
mod6: Ok, I'm gonna shutdown the cuntoo box, and boot my original gentoo ssd (where I built cuntoo from). I'll see what I can find out from the genesis.vpatch thing.
diana_coman: trinque, I'm trying here to even *see* this "profiles/" path in any other way than in the vpatch but so far no luck
diana_coman: fwiw a test file created there and vdiffed resulted in no such nonsense
feedbot: http://qntra.net/2019/03/french-ophthalmologists-demand-police-rubber-ball-bullet-ban-after-epidemic-of-eye-injuries/ << Qntra -- French Opht...ists Demand Police Rubber Ball Bullet Ban After Epidemic Of Eye Injuries
trinque: diana_coman: there oughta be a cuntoo/portage dir inside the build dir
trinque: this is what's vdiff'd to produce genesis
diana_coman: yes, that one is there; but I don't see the path that vdiff seems to see
trinque will brb, grabbing food real quick
diana_coman: cp -R portage would fail otherwise anyway
trinque: right, this is what leads me to believe there's some vdiff bug to discover
diana_coman: ha, wait, there actually IS a b/profiles/home/...
diana_coman: trinque, what should be in the portage/profiles dir?
diana_coman: apparently vdiff is correct after all and there is this thing it sees - it just took me a bit to find it as I thought it was just a misplaced path rather than...the actual thing,huh
mircea_popescu: phf pretty sure that's the wrong version of it ? iirc there was also a keccak that didn't explode ? diana_coman ?
bvt: trinque: i also confirm that under /cuntoo/portage/profiles there is a directory structure that corresponds to my bootstrap environment
lobbesbot: bvt: Sent 22 hours and 22 minutes ago: <asciilifeform> http://bvt-trace.net/2019/03/ffa-chapter-9-homework-comba-in-x86_64-assembly/comment-page-1/#comment-12
diana_coman: mircea_popescu, when he says "explodes" he means that keccak implementation expects as input a bitstream where each bit is stored in an octet
diana_coman: i.e. there isn't yet a bit-level keccak implemented, no
bvt: something like i.e. /cuntoo/portage/profiles/root/cuntoo/build/usr/portage/profiles/features/musl/use.mask
mircea_popescu: ah, i vaguely recalled we had two of them, one bit the other byte.
trinque: bvt: you confirm that this exists in your genesis, but is not a valid path?
diana_coman: mircea_popescu, that's at...another level
mircea_popescu: what ?
trinque: i.e. one that physically exists on disk?
bvt: i confirm that it is both in genesis and is a valid path. i'm testing live cuntoo though, have no access to bootstrap env currently
bvt: i.e. there is really directory structure /cuntoo/portage/profiles/root/cuntoo/build/...
trinque: o,0
trinque: this is an interesting clue. I'll be back shortly
bvt: but it does but is missing under /usr/portage/...
diana_coman: mircea_popescu, http://btcbase.org/log/2018-10-12#1860813 ☝︎
a111: Logged on 2018-10-12 13:08 diana_coman: asciilifeform, hm, the bit version blows up buffers even more because it uses *internally* arrays of bits as per http://www.dianacoman.com/2018/02/01/eucrypt-chapter-8-bit-level-keccak-sponge/#selection-51.100-51.594
bvt: ugh, *but it is missing under...
diana_coman: trinque, bvt put clearly what I was trying to say: here I have the same: the full directory structure inside /cuntoo/portage/profiles
mircea_popescu: diana_coman do you see the wisdom in implementing a keccak variant that uses eucomms-style fields ? so that something like "hello world" would be passed as 0x01146865 6c6c6f77 6f726c64
bvt: i.e. like this http://p.bvulpes.com/pastes/k88Le/?raw=true
diana_coman: mircea_popescu, from keccak's pov there is no meaning to the input so I don't quite see what you mean there
mircea_popescu: to be clear : i expect that in the regular course of republican work, GB-sized vdiffs will occur -- strictly because we're contemplating confiscating all sort and manner of heathen artefact, and by now bloat is just a synonym for heathen. the "increase stack" fix works ok as a stop-gap, but we can't really 8x everything just for boredom.
mircea_popescu: diana_coman i mean that instead of keccak receiving array of bits stored in octets, keccak receives (and processes) a eucomms field.
diana_coman: that requires simply a bit-level keccak; which requires in turn someone with the time to do the transformation as it were
mircea_popescu: 0x(01 => length of 2nd field is 1) (14 => length of 2nd field is 20) (6865 6c6c6f77 6f726c64 = hello world).
mircea_popescu: !!up bflame
deedbot: bflame voiced for 30 minutes.
diana_coman: that seems to be at most at reading-chunk-from-file level which is not really related to keccak and not a problem if I understand correctly what phf says; specifically on one hand he said http://btcbase.org/log/2019-03-10#1901225 and then option c from http://btcbase.org/log/2019-03-10#1901236 ☝︎☝︎
a111: Logged on 2019-03-10 19:44 phf: http://btcbase.org/log/2019-03-10#1901176 << i'll put it to the top of the stack, i remember fixing it, but never completing the patch.
a111: Logged on 2019-03-10 20:00 phf: there are three possible solutions, a) make sure that stack is arbitrarily large b) feed keccak buffers no larger than some magic size c) rewrite keccak to operate on char arrays directly without the need for bitstream allocation
mircea_popescu: bflame how about you make yourself useful and implement a keccak as discussed ^ then patch diana_coman 's tree with it.
diana_coman: so perhaps the text coding etc would help at chunking-file stage if needed but what is that to do with keccak
mircea_popescu: diana_coman well, apparently it expects to be called with a bitstream, which is a peculiarly inconvenient datastruct in practice.
mircea_popescu: i really do not wish to see c strings, and i don't perceive char buffer to be different. "bitstream" does not exist. so my thinking is, to henceforth mandate datapassing as such a field.
mircea_popescu: as a universal c-string / charbuffer replacement.
mircea_popescu: poor man's tagged data, if you will.
diana_coman: mircea_popescu, what is the gain vs having as input octets or words?
mircea_popescu: that you always know how large the field is.
diana_coman: what, a number attached?
mircea_popescu: the ~problem~ with c-strings is that to know how loing it is you must look ~at the end~.
diana_coman: ada doesn't have c-strings anyway
mircea_popescu: the problem with any other datastruct, such as octets or words, is that you never know how large it is.
mircea_popescu: the correct solution then seems to be, prefix size.
diana_coman: uhm, no
mircea_popescu has to go now, but will bbs to continue this.
diana_coman: k
asciilifeform: mircea_popescu et al : there are no cstrings in ada, unless one explicitly bakes'em in order to throw to c linked liquishit. all arrays carry their bounds with'em.
asciilifeform also gotta bbl
bvt: http://btcbase.org/log/2019-03-09#1901061 << iirc there were restriction on what regs can be used as base and index; another example of isa ugliness is MOV http://archive.is/w0IAC#selection-607.0-945.2 ☝︎☟︎
a111: Logged on 2019-03-09 22:35 asciilifeform: btw, bvt , rax etc. ~are~ encoded as 1-8, the iron dun see reg names at all, the classic names are a convention of the asmers and the vendor docs. and imho remains on acct of the asinine x86isms like MUL which use fixed input and output regs, makes'em slightly easier to remember.
bvt: http://btcbase.org/log/2019-03-09#1901064 << well, IMO nvidia's "denver" managed to beat even them. ☝︎
a111: Logged on 2019-03-09 22:40 asciilifeform: when you build 1 of these things, there's a set of decisions that end up determining shape of whole thing; and it so happens that intel made ~all~ of the most retarded possible choices.
bvt: ('denver' is arm at frontend and vliw inside, dynamic jit tries to continuously improve translation: if you have a loop, the 1st, 100th and 1000th loop iterations can execute totally different vliw code)
bvt: http://btcbase.org/log/2019-03-10#1901101 << I decided against inline assembly because the asm source is quite large, it's inconvenient to have 100+ lines of asm inline with comments. ☝︎
a111: Logged on 2019-03-10 02:44 mircea_popescu: http://bvt-trace.net/2019/03/ffa-chapter-9-homework-comba-in-x86_64-assembly/#selection-15.295-19.176 << why this, specifically ? is there no ada asm calling method besides this ?
bvt: there are Import(Ada,...) and Import(Asm,...), which do the same thing according to the docs (http://archive.is/XEHW0#selection-17075.0-17109.171), and I did not manage to find any ABI docs with 'ada calling sequence'.
mod6: trinque: Ok, immediately I notice that in my /home/mod6/cuntoo/nomods/cuntoo working directory, from which I ran `./bootstrap.sh -k config/cuntoo-test1 -d /dev/sdb` there is currently nothing in the 'build' directory.
trinque: didn't you just say you were going to reboot?
mod6: I've looked at the genesis.vpatch that was genereated ( http://www.mod6.net/cuntoo-blog-2/nomods.genesis.vpatch ), and at first glance I don't see these files in their paths. (even if I remove the preceeding 'a/').
mod6: trinque: aha. yeah, powered down, plugged my gentoo SSD back in, and am booted into gentoo where i've built cuntoo.
trinque: ok. so what happens to mounts when you reboot
mod6: http://p.bvulpes.com/pastes/CLgnR/?raw=true
mod6: Is this what you're asking?
trinque: no dude, why would the drive still be mounted on the build dir if you rebooted?
trinque: I don't know why you find this surprising
mod6: Oh, sorry, I guess I wasn't excatly sure what you were asking me to look for, and where. I never had /dev/sdb mounted when I did the bootstrap.
mod6: It was just "plugged in" to SATA channel 2.
trinque: you didn't read the script either and would otherwise know that it mounted that for you.
mod6: Gotcha.
mod6: Is there anything else I can check for you while I have your ear?
trinque: anyhow, bvt, can I get you to paste an ls -R starting from build/cuntoo ?
mod6: I have also posted the entire typescript (47Mb WARNING) of the build to my website: http://www.mod6.net/cuntoo-blog-2/nomods.cuntoo.build.typescript
mod6: I also have tar'd up the entire cuntoo build directory, but have not posted it. It's like 1.7G, but will send it somewhere if someone wants it.
mod6 bbl
bvt: as i mentioned, currently i can show results only from live cuntoo
bvt: ls -R /cuntoo http://wotpaste.cascadianhacker.com/pastes/hHbuq/?raw=true find /cuntoo http://wotpaste.cascadianhacker.com/pastes/gAtS2/?raw=true
trinque: /cuntoo/portage/profiles/root/cuntoo << and you built this in /root/cuntoo eh?
bvt: correct, it was a liveusb system
trinque: ah for fucks sake, I found it
trinque: scripts/make_portage_tree.sh << line 14, I do string-munging on the path that's specific to my own filesystem layout ☟︎☟︎
trinque: shame on me!
trinque: bvt: thanks very much for posting this for me! I now know what to fix, back shortly.
bvt: yw
mircea_popescu: diana_coman what ended up being the problem then, i'm not getting something here.
mircea_popescu: bvt i see.
feedbot: http://pizarroisp.net/2019/03/10/pizarro-isp-march-10th-update/ << PizarroISP -- Pizarro ISP March 10th Update
trinque: bvt: diana_coman: I wager that if you change line 14 of scripts/make_portage_tree.sh to the following, my sig will verify on the resulting genesis.vpatch : dest=$pdir/profiles/${src#$bdir/usr/portage/profiles/} ☟︎☟︎☟︎
trinque: just running scripts/make_portage_tree.sh again oughta be enough.
mircea_popescu: trinque nice find.