log
500+ entries in 0.05s
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 !
asciilifeform: oh btw ave1 et al, stripped static muslic ch10 ffa_calc, weighs only 256kB !
asciilifeform: ave1: when your builder is properly ripe, i'ma feature it in the reignited ffa series !
a111: Logged on 2017-12-30 22:12 asciilifeform: to round off thread -- asciilifeform very much enjoying rewriting ( and it is , yes , a total rewrite ) ffa
spyked: now, the reason why this has been taking me so long is that I hoped I would publish the pieces as I went along. but this is harder than it looked, had to write what is now unreadable (other than by myself) prototype, then (point c. on my list) I'll have to rewrite/refactor and then publish. all this despite the fact that this is "known item", not FFA.
asciilifeform: ( commandline items like ffa generally work; anything with video/audio -- prepare to suffer )
a111: Logged on 2017-07-13 15:16 asciilifeform: the other thing to remember, is that the win from writing in ada - but not in ada in general, but the style demonstrated in ffa in particular -- remains even if YOU HAVE NO ACCESS TO GNAT and gotta compile by hand into asm. because it forces the style of algo that CAN be safely so expressed - i.e. without presumption of pointerolade arithmetic, gc, or other cost-externalizing electrosocialisms
asciilifeform: ( the thing weighs far too much for anyone to ever audit in the sense contemplated with e.g. ffa )
asciilifeform: e.g., ldd ./bin/ffa_calc returns
asciilifeform: i built a ch10 ffa with it, and the result runs.
asciilifeform: AAAAAAnd we have a winner! ave1's musltronic gnat builds static, musltronic ffa !!!!
mircea_popescu: fromdeedbot, you can also compile alf's ffa and do it all by hand :D
asciilifeform: ( and ffa correspondingly delay by a new month ... )
asciilifeform: thing is, i also have massively overdue item that i'm in the process of rolling out ( reignition of ffa series ! )
mod6: One other thing about ada-vtron, at the time, I was using system commands to execute `gnupg'. Where as now, perhaps we can use ffa/peh.
mod6: see, I did think that alf had produced something of this kind that was connected to ffa.
asciilifeform: and it worx for building e.g. ffa.
asciilifeform: ( of the compiler that you produced, that is, when it builds e.g. ffa )
asciilifeform: i'll point out, this is not equivalent to 'build ffa', the gpr file is part of ffa, and contains essential functionality ( mainly , incorporates the restriction flags, mandates staticity )
ave1: asciilifeform, that work has been done, it builds a native compiler with gcc/g++ and gnatmake but not with gprbuild yet (this last one can be build on the target machine). I can build the FFA code on an aarch64 machine with the resulting compiler.
asciilifeform: i'ma read comments/barfology laters; off to ffa room nao!
trinque: have you built your own trb node? used V? understood it? do you have a working gnat? built asciilifeform's ffa? built diana_coman's eucrypt? stood up a gentoo from scratch? fertile ground all over.
mircea_popescu: so, if your desert march results in a jewel of code, a la ffa, sure. if your desert march results in ample "lulz" as we call them, ie, intricate, unforgiving documentation of orcs' idiocy, sure.
spyked: http://btcbase.org/log/2018-04-12#1797815 <-- must confess that I am eager to read FFA spark.☝︎
asciilifeform: ( or see the ffa article series, http://www.loper-os.org/?cat=49 , currently on sabbatical but due to resume after i come back from upcoming biznistrip )
asciilifeform: no-dynamic-allocation is also a Good Thing, for instance in my FFA crypto lib ( http://www.loper-os.org/?cat=49 ) this property exists
a111: Logged on 2018-04-04 00:46 asciilifeform: phf: i was vaguely hoping he might grasp this by playing with pehbot / reading ffa ; but loox like no dice so far
asciilifeform: phf: i was vaguely hoping he might grasp this by playing with pehbot / reading ffa ; but loox like no dice so far
asciilifeform: btw, ftr : ffa comes back from sabbatical next wk !
mod6: which is the only version i've been able to stand up that seems to work 100% with ffa.
asciilifeform: hanbot, mircea_popescu , et al : observe in phf's http://btcbase.org/patches/vtools-vpatch/tree/vtools/vdiff.gpr , he did not forbid the linking of libc into the library ( as i did in http://btcbase.org/patches/ffa_ch1_genesis/tree/ffa/libffa/ffa.gpr#L46 ) . apparently this worx on some gnat, but on hanbot's -- barfs
mircea_popescu: we will evidently have a ffa-based, canonical gpg replacement. EVENTUALLY. until such an eventually, i don't feel so great recommending anyone gpg (or, heavens help us, http://btcbase.org/log/2018-01-22#1774477 -- just as i had to do, and recently). so a drop-in, eucrypt-based, "good enough" item is more than useful.☝︎
a111: Logged on 2018-03-08 14:38 ave1: I've started on http://btcbase.org/log/2018-02-28#1786498, in Ada code and now I'm debating if I shouldn't just move the code to C as the eucrypt interface is C. But then maybe eucrypt will move to FFA someday in the future and Ada will be a benifit. (Working on code with lot's of C calls in Ada is not nice...)
mircea_popescu: http://btcbase.org/log/2018-03-08#1787224 << i don't expect eucrypt will ever move to ffa. this is in no sense a disidence, or any negative comment on ffa whatsoever. they are intended and designed as very different usecase solutions -- note the speed differential incumbent. eucrypt works as a "good enough" item, it principally intends to support a game, and same-level crypto needs. it's consequently to be light, fast, and ~r☝︎
ave1: I've started on http://btcbase.org/log/2018-02-28#1786498, in Ada code and now I'm debating if I shouldn't just move the code to C as the eucrypt interface is C. But then maybe eucrypt will move to FFA someday in the future and Ada will be a benifit. (Working on code with lot's of C calls in Ada is not nice...)☝︎
deedbot: http://ave1.org/2018/on-ffa-chapter-2/ << ave1 - On FFA Chapter 2
deedbot: http://ave1.org/2018/on-ffa-chapter-1/ << ave1 - On FFA Chapter 1
asciilifeform: ada folx: re making ada strings out of the c variety : strlen(char *) is a potentially lethal op ( suppose the nullterminator is missing ) so it will never be called implicitly by ada. you gotta either call strlen deliberately on c side, and then form ( can be on stack , declare ... Foo : String(1 .. Length) ... , say, a la http://btcbase.org/patches/ffa_ch4_ffacalc#L53 ) a proper ada string and copy the cstring into it.
deedbot: http://thetarpit.org/posts/y04/06c-ffa-egypt-proof.html << The Tar Pit - Egyptian div and mul "work": a correctness proof for the arithmetic operations in FFA Chapter 5
a111: Logged on 2018-02-23 15:45 mod6: I was thinking lsat night about my version of V in Ada, and am using shellouts there for the gpg related things. even with an integrated FFA, still need to add in an integrated Keccac from s.mg - those two I can work around. Others might be harder than it sounds.
mod6: I was thinking lsat night about my version of V in Ada, and am using shellouts there for the gpg related things. even with an integrated FFA, still need to add in an integrated Keccac from s.mg - those two I can work around. Others might be harder than it sounds.
spyked: hey mod6, I just checked v99993 using ffa ch1-5 and also used it to test a press of phf's vtools and it works fine. NB: Debian systems are now pretty much broken and won't allow setting the default gpg to v1, so I had to manually replace the gpg calls in v.pl to use gpg1.
mod6: mircea_popescu: well, never the less, I'm still very much behind the utility of ffa
asciilifeform: mod6 tried his hand at 'tester of whether ffa really does constanttime modexp'; asciilifeform comments on 1 set of output. is all.
asciilifeform: after that you can e.g. time echo "??\`\`*[print 0x]##[ == 0x]#[ * 0x]#" | ./bin/ffa_calc 1048576 32 lotsaones.bin | tr -d '\n' | python
asciilifeform: echo ".0~#" | ./bin/ffa_calc 1048576 32 | xxd -r -p > lotsaones.bin
asciilifeform: but know that 'iron mul' has been re-introduced (will be made selectable soon enuff) and you can use ch10 ffa to diagnose 'evil' cpu
mod6: hmmmod6@localhost ~/ada/alf/ffa/ch10/ffa/ffacalc $ command -v tr
asciilifeform: time echo "??\`\`*[print 0x]##[ == 0x]#[ * 0x]#" | ./bin/ffa_calc 1048576 32 /dev/urandom | tr -d '\n' | python
asciilifeform: >> http://btcbase.org/patches/ffa_ch10_karatsuba << ty phf !
mircea_popescu: never you mind, you've got the ffa to do.
asciilifeform: hanbot: and indeed i'm still grunting out prev item (ffa ch10 ) in conveyor.
asciilifeform only nao finished the proggy for ffa ch10, a backbreaker. nao for the text...
gabriel_laddel: asciilifeform: unfortunately not. Am here because I finally have a nice setup where I won't get kicked regularly. While I have been reading some FFA and DC I do not have anything running at the moment
asciilifeform: hey gabriel_laddel -- other than substances... do anything noteworthy in recent times ? ever read ffa series ? interested in s.bisp ? read diana_coman's www ?
mircea_popescu: http://btcbase.org/log/2018-02-02#1779409 << this should prolly be standard preface of ada behaviour discussions ; ffa or non-ffa related. asciilifeform maybe you should add it as a comment you know ? at the top of the pile, "if anything's strange say @me in #trilema, please preface the saying with and-here's-my-grep-v"☝︎
asciilifeform: in other experiments, http://btcbase.org/log/2018-01-09#1767440 appears to hold true across all ffa chapters.☝︎
asciilifeform: and http://btcbase.org/patches/ffa_ch4_ffacalc/tree/ffa/ffacalc/os.ads
asciilifeform: the 'main is in ada; some imports from c' variant is also illustrated in ffa, in http://btcbase.org/patches/ffa_ch4_ffacalc/tree/ffa/ffacalc/cmdline.ads
asciilifeform: ( it is imho unlikely that anyone will demonstrate an rsatron with fewer moving parts than ffa-ch5 )
asciilifeform: diana_coman: in some applications, speed doesn't really matter almost at all. and in those, it is even now possible to, e.g., take ch5 ffa for rsatron.
diana_coman admits that is one of the things she really, really likes about ffa