log
800+ entries in 0.075s
asciilifeform: the statement is quite serious, i and some yet-unknown number of other people will literally bet arse on our grasp of ffa correctness.
asciilifeform: ffa. see esp the passage re parachute.
zx2c4: hey ffa in ada
asciilifeform: at 1 time, was used in the constant entry ( nibble inserter ) routine, then the latter was replaced with rewritten http://www.loper-os.org/pub/ffa/hypertext/ch13/fz_io__adb.htm#29_14 , nao sole remaining use is in the knuth divider.
asciilifeform: diana_coman: i'ma also note, _O_I is used strictly in fz_mod : http://www.loper-os.org/pub/ffa/hypertext/ch13/fz_divis__adb.htm#83_14 ; prolly oughta be inlined ~there~ and abolished as a global (even internally) function.
asciilifeform: i'ma add commentary/warnings when diana_coman et al point out good additional places where; but no one should live with expectation that ~all~ possible ways to break ffa by monkeying with internals, will be listed
asciilifeform: idea being , exported routines ( current set is shown in http://www.loper-os.org/pub/ffa/hypertext/ch13/ffa__ads.htm ) are to be 'safe on all electrically possible inputs' , with the exception of div0 (user is commanded to test for div0, as example in http://www.loper-os.org/pub/ffa/hypertext/ch13/ffa_calc__adb.htm#172_17 )
asciilifeform: observe that the operators of fz_shifts are not exported in ffa.ads ( ch11 unified api ) , they are strictly for internal use in the lib.
diana_coman: asciilifeform, http://btcbase.org/patches/ffa_ch3_shifts.kv#L462
diana_coman just ate ffa 3, will sign
asciilifeform: ( ffa has 0 deps outside of gnat itself and system character i/o, currently posix's )
asciilifeform at one point tried to systematically fit in head danielpbarron's theology, but it appears to be at least as complicated as ffa; broke teeth
mircea_popescu: asciilifeform myeah. though in fairness, those corner cases rarely in the ffa or ffa-lite deployed.
mircea_popescu: wouldn't it be ~nice~ if you used some kind of sane naming convention ? trb.adding-ffa.alf ? something ?
asciilifeform: ftr 1 of the many ruins that litter asciilifeform's hdds is a half-written ada ecc ( pre-ffa )
asciilifeform: mircea_popescu: could, for example, use diana_coman's. or a modified permissive ffa. or even the thing that came with gnat. but in any case would be 'sapper errs once' component, gotta be bug-free
mircea_popescu: politically, ffa is fine. practically, it might not work.
mircea_popescu: and yes, ffa majorily useful, and no, not necessarily against writing for it. but there may be a timing issue (trb that takes > minute to check block is useless)
asciilifeform: can be written from scratch ( whoever thinks that he can do it faster than asciilifeform's ffa, is welcome to try, i promise to take off hat ) or on ffa, either.
asciilifeform: if mircea_popescu gives signal that we're fucking done with the old flintlock pistols, then i'ma start welding on ffa in trb as soon as the former is battlefield-ready.
asciilifeform: ( it is certainly indexed in the place where it lives -- http://www.loper-os.org/pub/ffa/hypertext/ch13/fz_basic__adb.htm#72_13 -- but for some reason not in ffa_calc__adb... )
asciilifeform: ( e.g. in above example -- FFA_FZ_Get_Head is not linkable, and several hrs of dig failed to tell me why )
asciilifeform: still mighty useful. ( presently i'm continuing with the http://www.loper-os.org/pub/ffa/hypertext/ch13/ffa_calc__adb.htm thing, to fill that niche )
a111: Logged on 2018-11-26 02:46 asciilifeform: !Q later tell phf plox to snarf http://www.loper-os.org/?p=2822 into http://btcbase.org/patches?patchset=ffa , ty
mircea_popescu: i'm sure if someone defaces ffa series to talk about what-ustards-understood-of-foucaults-sexnonsense-half-century-later someone'll notify you.
asciilifeform: pehbot is simply a wrapper around compiled ffa_calc , currently it gives closest possible picture to what you get if you ran the proggy itself locally.
a111: Logged on 2018-11-26 02:46 asciilifeform: !Q later tell phf plox to snarf http://www.loper-os.org/?p=2822 into http://btcbase.org/patches?patchset=ffa , ty
lobbesbot: phf: Sent 11 hours and 19 minutes ago: <asciilifeform> plox to snarf http://www.loper-os.org/?p=2822 into http://btcbase.org/patches?patchset=ffa , ty
asciilifeform: !Q later tell phf plox to snarf http://www.loper-os.org/?p=2822 into http://btcbase.org/patches?patchset=ffa , ty ☟︎☟︎
asciilifeform: mircea_popescu: now you know what half of ffa illustration sweat loox like !
asciilifeform: diana_coman et al: http://ossasepia.com/2018/11/24/proposed-change-to-w_borrow-ffa/comment-page-1/#comment-4500
deedbot: http://ossasepia.com/2018/11/24/proposed-change-to-w_borrow-ffa/ << Ossasepia - Proposed Change to W_Borrow (FFA)
phf: asciilifeform: a downside to your renaming the patches is that it breaks all the old btcbase links. e.g. http://btcbase.org/patches/ffa_ch1_genesis is now http://btcbase.org/patches/ffa_ch1_genesis.kv even though the content is the same
ascii_modem: http://btcbase.org/log/2018-11-23#1874276 << longer even! i have time budget to ffa XOR sand and repaint my www, not currently both tho ☝︎
lobbesbot: phf: Sent 3 minutes ago: <asciilifeform> plox to snarf http://www.loper-os.org/?p=2798 into http://btcbase.org/patches?patchset=ffa , ty
asciilifeform: !Q later tell phf plox to snarf http://www.loper-os.org/?p=2798 into http://btcbase.org/patches?patchset=ffa , ty
asciilifeform: this is the reason why asciilifeform is saving the optional asm subroutines in ffa for ~dead last~ ( per http://www.loper-os.org/?p=2735 proclamation ) rather than given in beginning of series
asciilifeform: i've added all kindsa 'new api' in ffa, but the only regrind was when we took up new hash type for vtrons
a111: Logged on 2018-11-18 20:52 diana_coman: http://btcbase.org/log/2018-11-18#1873291 - noted and added to the list though it might still take some time to get up to speed with ffa again
asciilifeform: http://btcbase.org/log/2018-11-18#1873480 << this is entirely ok, diana_coman , there is not a burning hurry ( tho i expect that anybody who intends on firing ffa on battlefield will first take the time to properly eat it ) ☝︎
asciilifeform: ( e.g. ffa genesis, is very small, but contained all of the basic fundamental moving parts for simple arithm )
a111: Logged on 2018-06-25 16:40 mircea_popescu: spyked> I think there's great benefit in the ffa chapter-based approach << that ~started with a genesis~.
a111: Logged on 2018-11-18 16:57 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
diana_coman: http://btcbase.org/log/2018-11-18#1873291 - noted and added to the list though it might still take some time to get up to speed with ffa again ☝︎☟︎
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 ☟︎
mircea_popescu: http://www.loper-os.org/pub/ffa/ch12_mul_timing.png << so beautifully linear! i would daresay this graph by itself promises corectness.
asciilifeform presently massaging ffa ch12, expects to take most of today
asciilifeform: ffa/p-tron as a dos boot disk would imho rock.
asciilifeform: ( i deliberately wrote ffa in such a way that it oughta work on under 32bit or even plain 16, supposing somehow enuff ram )
asciilifeform: it is on hold pending resolution of http://btcbase.org/log/2018-10-26#1866266 ( and is taking back seat to ffa currently ) ☝︎☟︎☟︎☟︎
asciilifeform: btw i was going through my ffa notebooks and found a margin note that was actually about this, that prolly oughta go in the l0gz : if yer 'pow' is a walk-through-storage, 1 problem is that initial state of the system gives too little material to walk. so 1 interesting answer might be to include a 'ballast', consisting of, say, the first 9 yrs of classical btc blox, 1...N, that is part of the luby'd set (as raw bytes, rather than as m
asciilifeform actually ran 2 printers into the ground since started ffa
asciilifeform: ( no algo in ffa is newer than 1988 or so )
asciilifeform: mircea_popescu: kinda what ffa is
asciilifeform: i wish i could concur, but while baking ffa i had to eat a good 100GB of pdf.
asciilifeform: mod6: have you considered to get a diff heathen gig ? the kind where you dun have to go anywhere ? in '16 asciilifeform pulled this off, yes it took having to run on batteries for a spell, but was 100% worth it, it's the only reason i had strength to actually do FG, ffa, etc
asciilifeform: i was hoping to avoid baking hashing into ffa/p , but loox like it isn't escapable if we're doing oaep
diana_coman: the table with FFA patches looks great; I'll look into carving again some space to re-start on it
asciilifeform: i think just his bigendian vs littlendian speshulcases (why he has any?! ffa doesn't..! ) weigh moar than all of ffa together
asciilifeform: i'd like to be able to put a link in the 'ffa regrind' article, 'and you can press it with ~this~'
a111: Logged on 2018-11-13 14:21 asciilifeform: when i started ffa, i did not plan to bake any asm speedups at all. but there's 2 reasons to do it, eventually : one is that on e.g. x86/x64, getting the upper half of a word-sized multiplication, without asm, takes ~four~ MULs plus a buncha additions : http://www.loper-os.org/pub/ffa/hypertext/ch11/w_mul__adb.htm#95_14
asciilifeform: nao, this being said, my objective is still to give acceptably-performing, re erryday ops, ffa ~without asm~. but asmism will make a serious diff re e.g. key generation, make minutes instead of day+.
ave1: http://www.loper-os.org/pub/ffa/hypertext/ch11/w_mul__adb.htm#33_13, this is the egyptian mul?
asciilifeform: ( there is also the fact that such a simple thing as addition with carry takes not 1 ADD instruction, but an entire http://www.loper-os.org/pub/ffa/hypertext/ch11/word_ops__adb.htm#36_13 orchestra )
asciilifeform: the other is that on iron such as certain ARM ( i have not yet investigated ~which~ ) , and ppc, and certain others, there does not even exist a constant-time MUL, and one is stuck with some variant of http://www.loper-os.org/pub/ffa/hypertext/ch11/w_mul__adb.htm#33_13 -- which really begs to be asmed, is riotously inefficient
asciilifeform: when i started ffa, i did not plan to bake any asm speedups at all. but there's 2 reasons to do it, eventually : one is that on e.g. x86/x64, getting the upper half of a word-sized multiplication, without asm, takes ~four~ MULs plus a buncha additions : http://www.loper-os.org/pub/ffa/hypertext/ch11/w_mul__adb.htm#95_14 ☟︎
asciilifeform: ( but eventually i do want to write e.g., asmtronic MUL, for arm64 ffa )
asciilifeform: i was able to regrind ffa today, using phf's vdiff, but atm cannot yet press and confirm that it actually presses to same thing as the classical
bvt: though i have nothing against work on bignum multiplication and modexp -- but as i see it, it could be a side branch of ffa. ffa already provides a solid foundation for such algorithm exploration.
asciilifeform in the process of keccakizing ffa, hence practical q
asciilifeform: when i have the choice, i'd rather write proggy to need no such cassettes ( observe, streams are not used in ffa )
mod6: So usually that leaves 30min-1hour per night, sometimes more depending on the size. Sometimes I fall down a well in the logs if i'm looking for something specific related to any number of things: pizarro, foundation, ada, ffa, who knows.
asciilifeform: mircea_popescu: after ffa/p beta rollout, i'ma be at yer service for the next thing ( fg2? tmsr.mips ? radio ? or other, take yer pick )
asciilifeform: ( i got one coming in a week or so, tho, for ffa exhaustive tests )
asciilifeform: ^ mircea_popescu , diana_coman , other potential ffa eaters ^
asciilifeform finally finished rereading ffa, nao preparing ch12 + estimate of just-how-long-to-battlefield promised earlier
asciilifeform: phf: i prolly won't get a chance to actually put it to use in near term, hands pretty full with ffa; but would like to have it. if it's there to be had.
asciilifeform: ( it's not ~completely~ fucktarded, all of ffa is still reachable via http://www.loper-os.org/pub/ffa/hypertext/ch11/ffa__ads.htm . but still frustrating )
asciilifeform: phf: it's definitely not perfect, e.g. why the FUCK is FFA_FZ_ZeroP not clickable ?
asciilifeform: phf: the default view ( http://www.loper-os.org/pub/ffa/hypertext/ch11/ ) of gnathtml gives you a frames thing with ~worthless alphabetic index in the left pane. really it oughta show 'where currently clicked symbol used' imho
asciilifeform: 3) -l1 turns on line numbering; -I adds paths to the libraryisms ; -p takes a file containing src_dir=. gpr_file=ffa_calc.gpr .
asciilifeform: 2) cd ffa/ffacalc ; gnathtml.pl -l1 -f -D -I obj -I ../libffa -I ../libffa/obj -p ffa_calc.adp ffa_calc.adb
asciilifeform: mod6: rereading own ffa , from opening shot to 11
asciilifeform: fwiw i've massaged ffa to the point where it's fully static and the problem dun affect it any. but some of my other stuff (mmap) is hobbled by it.
asciilifeform: current ffa relies on the user/caller to wipe
asciilifeform: ( it's not a wholly useless thing, i dun have it in current ffa but my 1st draft used it to wipe all data on the stack erry time it goes out of scope )
bvt: myeah, i solved it by maximally recreating the ffa project structure, so can't say i did anything informed by the 'first principles' there.
bvt: otoh, when i added a single line 'package SIO is new Ada.Sequential_IO(Positive);' to ffa_calc.adb, it errored out during the compilation in the same way
bvt: just tested ffa-8 where rng was introduced -- it works fine. would be trying to understand what is wrong with my code, then
diana_coman: hm, weird; now I'm really curious if you get the same complaint with asciilifeform's ffa (or my smg comms for that matter)
bvt: i used gnat 2017. will test ffa rng code and see if it works out.
asciilifeform: bvt: which gnat are you using ? i've never observed any such thing ( and i use the same restriction, http://btcbase.org/patches/ffa_ch11_tuning_and_api/tree/ffa/libffa/restrict.adc#L76 , ~with~ sequential i/o, http://btcbase.org/patches/ffa_ch11_tuning_and_api/tree/ffa/ffacalc/ffa_rng.adb#L49 )
mircea_popescu: hence the whole effort in ffa, which is nothing else and nothing besides a switching harness for 64 bit cpu so it doesn't leak data while switching it for a 8192 native byte.
a111: Logged on 2018-11-01 21:02 asciilifeform re-rotates desk to ffa pile
a111: Logged on 2018-10-31 17:54 asciilifeform: implicit conditionals aint evil per se , tho ; i banned them in ffa specifically as they get in the way of constanttimeism, is all
asciilifeform re-rotates desk to ffa pile ☟︎
asciilifeform: there is no particular reason why ~erry~ proggy has to have the same pragma fascism as ffa ( and in fact i've written several that cannot function under that set of constraints, e.g. the mmap thing requires System.Address )
asciilifeform: implicit conditionals aint evil per se , tho ; i banned them in ffa specifically as they get in the way of constanttimeism, is all ☟︎
asciilifeform: diana_coman: out of curiosity -- given what mircea_popescu said the other day re necessary speed of rsa ops, could potentially use the current (11) ffa ?
asciilifeform: the funny/sad bit is that this is ALREADY in gnat, for e.g. http://btcbase.org/patches/ffa_ch8_randomism#L132 , but ~not exposed~ ! to user