1000+ entries in 0.105s
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
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.
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.
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
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
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
☟︎ 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 ?
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
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
☟︎☟︎ 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?
a111: Logged on 2018-06-03 18:36 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 !
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.
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
mircea_popescu: fromdeedbot, you can also compile alf's
ffa and do it all by hand :D
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.
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.
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.
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
mod6: which is the only version i've been able to stand up that seems to work 100% with
ffa.
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...)
☝︎☟︎ 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 mod6: hmmmod6@localhost ~/ada/alf/
ffa/ch10/
ffa/ffacalc $ command -v tr