Hide Idle (>14 d.) Chans
← 2019-03-09 | 2019-03-11 → ↓
mircea_popescu: o right the registers. i recall.
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
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
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
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
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/...
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
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.
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: 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
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.
feedbot: http://trilema.com/2019/antiqua-sanctorum-patrum-or-the-lordship-list-sixth-year/ << Trilema -- Antiqua Sanctorum Patrum, or -- The Lordship list, sixth year.
BingoBoingo: So in trends, the neon nazis shifted to memeing against Trump in favor of a candidate promising 1000 "dollars" a month
hanbot: BingoBoingo please reboot me again at your leisure, any time tomorrow or tuesday'd be fine
← 2019-03-09 | 2019-03-11 → ↑
Random(trilema) | Download hourly DB snapshot | Get Source Code