log
800+ entries in 0.079s
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
asciilifeform: bvt: i have a variant of this in ffa, and yet another subset in mmap
diana_coman: ftr I quite like the neat way in which asciilifeform defined those basic types in FFA; however, he went for the classical types so byte, nibble ; and I find octet SO much easier than I'm reluctant to give it up in my code (though all it takes is anyway a "subtype Octet is Byte" at top if Byte definition is to be adopted)
lobbes: hm interesting. I too have hands tied up but have been meaning to get a few chapters of ffa under my belt. I'll jot this idea down for far off in the conveyor if someone else doesn't get to it first (and by all means, Someone: feel free to beat me to this punch)
ave1: Using the stack makes code less error prone and a lot more readable, please read the FFA code; http://www.loper-os.org/?cat=49.
asciilifeform: i have 1 presently ( switched off, will move it to pizarro in near fyootoor ) , talks to ffa
asciilifeform: i illustrated this in ffa
ave1: asciilifeform, I was looking for mux just now in ffa just now and I came by the add_gated which uses a different method,.
asciilifeform: ave1: use the method illustrated in w_mux, http://btcbase.org/patches/ffa_ch1_genesis#L870
asciilifeform: ave1: you dun need ffa for this, yer dividing single words by single word
ave1: the div variant could be made to be constant time using the ffa primitives but currently is not.
mircea_popescu: we ~needed~ a republican crc32 anyway, it's useful and important, chapter head exactly like "we need a hash" or "we need a ffa", and i was aware extant code is not fit for pitching.
asciilifeform: http://btcbase.org/log/2018-10-04#1857985 << financials -- none; conveyor -- tmsr.udp ; ffa to resume once i wrap up keccakizing ☝︎
a111: Logged on 2018-10-01 15:59 mod6: And before the republic, I was very much a one-thing-at-a-time type of engineer. Seems like over the last year or maybe 18 months, I feel like I'm context switching so much, that I find it hard to get deep into the thinking that I need to. For instance, it bothers me that I still haven't found time to work through FFA.
mod6: Not only FFA, but other parts of TRB that I'd love to educate myself upon. I think you take my meaning.
mod6: And before the republic, I was very much a one-thing-at-a-time type of engineer. Seems like over the last year or maybe 18 months, I feel like I'm context switching so much, that I find it hard to get deep into the thinking that I need to. For instance, it bothers me that I still haven't found time to work through FFA.
a111: Logged on 2018-09-28 16:15 Mocky: asciilifeform, O(1) crapolade packet rejection is already available in software with your FFA lib, if RSA over non-frag UDP was built on top, no?
Mocky: asciilifeform, O(1) crapolade packet rejection is already available in software with your FFA lib, if RSA over non-frag UDP was built on top, no?
asciilifeform: e.g. i can put out ch12 of ffa on keccak.
asciilifeform: http://btcbase.org/patches/ffa_ch11_tuning_and_api/tree/ffa/libffa/fz_io.adb#L59 << example of endian-insensitive routine.
asciilifeform: http://btcbase.org/log/2018-09-14#1850327 >> they are, see e.g. http://btcbase.org/patches/ffa_ch4_ffacalc#L43 example ☝︎
asciilifeform: ( i had'em in the 1st drafts of ffa, then abolished , they interfere with proper compartmentalization )
asciilifeform: diana_coman: currently i am lacking a bigendian iron (or a gnat for such) so never got a chance to truly and properly test endianism conversion (as for ffa, it is endian-insensitive, but this is simple where there is no networking)
asciilifeform: ( and i didn't get a chance to finish the whole thing, was right when i picked up ffa )
asciilifeform: BingoBoingo: i'm willing to talk to 'hey i read ffa and in ch4 you missed this-here obvious optimization, here's proof'. but 'hi i am reddit, hear me roar' can go the fuck perma-away.
mats: depending on how that goes, i'll explore different power plants, and if THAT goes well, there's a gnat port to build future ffa-gossipd
asciilifeform: ( ffa in particular , only needs a stack, and 2 uarts, 1 for commands, 1 for FUCKGOATS ... )
a111: Logged on 2018-08-04 22:05 asciilifeform: ben_vulpes: iirc i proposed at one time an intermediate item on the way to proper gossipd ( 'serpent'-ciphered tunneler to connect coupla ircd instances to each other, and ditto for users ( get otp cookie a la deedbot, get a key that's good for 1 tcp connect ) but so far instead followed mircea_popescu's advice re not wasting sweat on such a thing, but pushing with ffa so as to get with what to gossipd.
asciilifeform: ben_vulpes: iirc i proposed at one time an intermediate item on the way to proper gossipd ( 'serpent'-ciphered tunneler to connect coupla ircd instances to each other, and ditto for users ( get otp cookie a la deedbot, get a key that's good for 1 tcp connect ) but so far instead followed mircea_popescu's advice re not wasting sweat on such a thing, but pushing with ffa so as to get with what to gossipd.
asciilifeform: btw i oughta mention , i had to resort to a modified vdiff.sh : http://p.bvulpes.com/pastes/rB9AD/?raw=true for ch11 , as the ada comment syntax causes inbandism barf with classic vdiff.sh when deleting or modifying the comment headers at the start of ffa modules
asciilifeform: http://btcbase.org/patches/ffa_ch11_tuning_and_api << for the l0gz.
mircea_popescu: o hey. wb ffa.
asciilifeform finally got inlining to work properly in ffa, ave-style . nao, the article!
phf: asciilifeform: while you're at it, ffa_ch4_ffacalc is also binary
mircea_popescu: i'll note that everthying the republicans deliver builds like a fucking charm, be it ffa, avetronics or what have you. i've never had a problem of this sort inside the walls.
a111: Logged on 2018-07-18 13:42 asciilifeform: phf: say what you will re ada standard, but e.g. ffa is ( afaik! ) a nontrivial and at same time ada2012-compliant proggy.
asciilifeform: mircea_popescu: conceivably not all works call for the ffa degree of fascism, where asciilifeform insists on being able to say exactly how many bytes are required after a O(1) look at the inputs, and to say exactly in what order they will be accessed etc
asciilifeform: http://btcbase.org/patches/ffa_ch4_ffacalc#L55 << copies the unix turd into the fixed space, if fits, if not, above.
asciilifeform: observe http://btcbase.org/patches/ffa_ch4_ffacalc#L97 mechanism, i fix a max length of param apriori, and routine will explicitly and pompously end the world if luser insists on trying to stuff it further.
asciilifeform: ( http://btcbase.org/patches/ffa_ch10_karatsuba/tree/ffa/ffacalc/cmdline.ads + http://btcbase.org/patches/ffa_ch10_karatsuba/tree/ffa/ffacalc/cmdline.adb for the curious )
asciilifeform: ( there was not an existing 'profile' corresponding to the degree of 'fascism' asciilifeform wanted , hence the bulk of http://btcbase.org/patches/ffa_ch10_karatsuba/tree/ffa/libffa/restrict.adc item )
asciilifeform: for thread completeness i must add that there are items in the standard (i.e. 'tasks') that i do not use in ffa, but intend to make use of in future ( i.e. trbi ) , and may be let live.
a111: Logged on 2018-07-18 13:45 phf: as far as ada is concerned, the tmsr ada is a subset of standard, that only exists in your head, and can be somewhat inferred from ffa. that's no standard
asciilifeform: ( hence why the logic is brought out to ffa_calc, rather than part of the lib proper -- to emphasize this )
phf: i'm starting to think that maybe it doesn't (my memory of logs are hazy on that point, perhaps ave1 mentioned that he's working on getting ffa_calc working), because i believe you're also using interfaces.c at least to declare the types that you get in/out of c system calls
asciilifeform: phf: my specific motivation in asking ave1 for this, was to enable building e.g. ffa where binary is small enuff to manually disasm and audit.
phf: asciilifeform: i thought that you were arguing that the subset of ada runtime that's included in zfp "ought to be enough for everyone", since at the moment i believe it compiles ffa, my apologies.
phf: as far as ada is concerned, the tmsr ada is a subset of standard, that only exists in your head, and can be somewhat inferred from ffa. that's no standard
asciilifeform: ( ~ffa_calc~ is not, as it uses a gnatism to grab the commandline args. )
asciilifeform: phf: say what you will re ada standard, but e.g. ffa is ( afaik! ) a nontrivial and at same time ada2012-compliant proggy.
asciilifeform: shinohai: otherwise pretty busy, currently with ffa reignition
asciilifeform: trinque: currently massaging ch11 of ffa series, right after this will test-fire your opus
ave1: thx diana_coman, It's now very minimal, mostly so that it can be understood as is. I'm working on adding all the code in so that at least ffa can build.
a111: Logged on 2018-07-05 05:17 mircea_popescu: asciilifeform when's the ffa restart btw ?
mircea_popescu: asciilifeform when's the ffa restart btw ?
asciilifeform wrapping up a very gnarly ffa surgery, >2x speed boost. thx to ave1 for the gnat clues.
asciilifeform: observe that ffa runs , per PeterL, on winblowz, despite asciilifeform having made 0 effort in this direction
a111: Logged on 2018-06-25 12:20 spyked: I think there's great benefit in the ffa chapter-based approach, so I'm not sure yet what the genesis should include. maybe only the lispm piece? or only the spec file from lispm? my sense so far is that after some discussion, at least some of the parts will be rewritten
mircea_popescu: spyked> I think there's great benefit in the ffa chapter-based approach << that ~started with a genesis~.
a111: Logged on 2018-06-25 12:20 spyked: I think there's great benefit in the ffa chapter-based approach, so I'm not sure yet what the genesis should include. maybe only the lispm piece? or only the spec file from lispm? my sense so far is that after some discussion, at least some of the parts will be rewritten
asciilifeform: http://btcbase.org/log/2018-06-25#1829397 << imho a genesis oughta be a proggy, if a minimal one, that introduces some basic functionality of the larger item ( as seen in ffa ch1 ) , rather than a placeholder, '[this is genesis and blah and other things will also go here]' -- if this makes sense ☝︎
spyked: I think there's great benefit in the ffa chapter-based approach, so I'm not sure yet what the genesis should include. maybe only the lispm piece? or only the spec file from lispm? my sense so far is that after some discussion, at least some of the parts will be rewritten
asciilifeform: PeterL: gprbuild is what applies the restrictions, so what you build is not quite ffa
PeterL: asciilifeform: in the interests of science, I built your ffa on a windows system and it appears to work. For some reason gprbuild didn't work, but when I used gnatmake I got a working executable. (I also had to mangle v.py in the process to make it work on my system)
a111: Logged on 2017-11-12 23:07 spyked: in other news, I've been using most of my spare cycles lisping in ada. should be able to wrap up a blog post sharing a very minimal prototype (sane implem. of repl doing nothing but basic ops) in a few weeks. what I've got now adheres to most of ffa constraints. the current version isn't very clean, but getting there...
a111: Logged on 2018-06-03 18:36 asciilifeform: ch10 ffa builds a (stripped) 320kB elf
esthlos: ^^ I'm curious what folx think of the above. Reading through the logs, FFA, etc., I've realized how little I know. So I'm thinking that I'll have to devote the majority of my effort to learning the ropes wrt computing before I can pull my weight in here. Does this make sense?
diana_coman: http://btcbase.org/log/2018-06-03#1820437 <- I can very gladly report that it works! I've re-built gnat on an x86_64; took the aarch64-native to the rockchip; unpacked, set, compiled ffa ch1 and ran, all perfectly fine; ave1 you rock! ☝︎
a111: Logged on 2018-06-03 18:36 asciilifeform: ch10 ffa builds a (stripped) 320kB elf
asciilifeform: on ch10 ffa: exponentiator test from end of ch.7 runs in 9.2s on dulap, and 28.4s on the test rk3328-roc-cc machine, producing correct output.
asciilifeform: ch10 ffa builds a (stripped) 320kB elf
spyked: http://btcbase.org/log/2018-06-02#1820283 <-- reading this thread, it just occured to me: is there a convention re. directory structure? the implicit one (in my own head at least) was that each project lives under its own top-level directory (e.g. b/ircbot, b/ffa, b/eucrypt, where b is the press tree). so then does the manifest reside in b/project_name_toplevel_dir/manifest? ☝︎
a111: Logged on 2018-06-01 23:26 asciilifeform: oh btw ave1 et al, stripped static muslic ch10 ffa_calc, weighs only 256kB !