log☇︎
800+ entries in 0.104s
asciilifeform: http://mocky.org/Log-Reference-Why-Ada/ << also recc'd read.
asciilifeform: verisimilitude: incidentally diana_coman ( http://ossasepia.com/ ) has quite large set of published ada ( & articles re same ), i highly recommend to read.
diana_coman: asciilifeform, it IS stock ada tasks, sure; it's not that the q
asciilifeform: hm interesting, i thought mircea_popescu et al were using the stock ada tasks thing
asciilifeform: trinque: this is common to all gnats (given as gnat is written in ada)
asciilifeform: trinque: configure: error: GNAT is required to build ada << unsurprising , ave1's thing only builds on existing gnat
asciilifeform: ada does not permit multiline comments a la cpp, so this was easier than expected.
a111: Logged on 2017-06-06 19:40 asciilifeform: mod6, phf , et al : http://nosuchlabs.com/pub/ada/horsecocks.tar.gz << i dun recall posting this before, so here it will live, for nao : unofficial release of mmaptron
asciilifeform: iirc this aint new even, was in ada-83.
mircea_popescu: now the question is, if you only need this specifically once, why do you need ada to do it for you
asciilifeform: mircea_popescu: it's very similar to cpp 'destructor' aha. with the diff that ada forces various limitations re the item, to prevent various cpp-esque lulz
asciilifeform: this is done with a standard ada feature called 'controlled limited type'. which i found that, for no documented reason, dunwork in gnat's static lib. ☟︎
asciilifeform: iirc phf attempted also to use it, to make a framebuffer driver in ada, but i dun recall if he ever returned with output
diana_coman: hm; earlier I used "standalone" as "standalone lib" because there is such a thing: it means precisely that it includes ada run-time
asciilifeform: it is actually a complete proggy, correct per the ada standard, but currently doesnt build on acct of the gnat bug described in the linked thread.
a111: Logged on 2018-10-26 02:14 asciilifeform: meanwhile, in gnat bugs : apparently ( and this is documented or mentioned nowhere ) : it is impossible to have a Ada.Finalization.Limited_Controlled type ANYWHERE inside a static library, unless it is generic all the way down (i.e. if the lib package is generic, any sub-packages must also be instantiated as generics )
diana_coman: if encapsulated too then it has to be dynamic but if not "encapsulated" then it can be static (and you need to link the ada libs with main proggy too)
diana_coman: re client/server: client is ALSO cpp+ada at the very least
diana_coman: quite; anyways, now that I have on eulora server c,cpp and ada together, it's a whole new level of madness
asciilifeform already has, of sorts, 'os in ada'. ( it only adds, subs, muls, modexps... but what moar could one want!111 )
mircea_popescu: in other euloraleaks, it seems self-evident that by the time we're done writing a kernel in ada, the os will be called auntoo, right.
asciilifeform: i found last yr, for instance, that unrolled comba ( still in ada ) gives 20-25% speedup.
asciilifeform: bvt: 1 of the reasons why ada doesn't offer e.g. addition-with-overflow , is that there is an abundance of sad iron where there isn't even physically a carry flag.
asciilifeform: ( ada standard btw trivially allows for types where this holds true automatically , i.e. throws exception for overflow. but this is not only massively unconstanttime but the overhead is gigantic )
asciilifeform: mircea_popescu: i'm not surprised, considering that bounds check overhead (in ada with all safeties switched on) magnifies the 'losing' of a losing (for particular width) algo
diana_coman: thanks! one of those days I'll get around to write-up the jam stuff for linking the lib with the client too ; at any rate, the linking seems sorted for now - it's Ada code for all the pieces that is missing
shinohai: I look forward to client updates, also found http://ossasepia.com/2019/01/12/compiling-ada-library-for-use-with-non-ada-main/ quite interesting btw.
diana_coman: shinohai, an Ada lib for client-side logging would be quite useful
diana_coman: mircea_popescu, http://ossasepia.com/2019/01/12/compiling-ada-library-for-use-with-non-ada-main/#selection-79.0-91.300
mircea_popescu: in other news : i'm not entirely current here, but diana_coman does seem to have neatly resolved the ada-cpp linking conundrums. going on which theory, the next step we're upon is what to do with the keys.
feedbot: http://ossasepia.com/2019/01/12/compiling-ada-library-for-use-with-non-ada-main/ << Ossasepia -- Compiling Ada Library for Use with Non-Ada Main
diana_coman: so far I can tell that the static lib has the huge disadvantage that one needs then to link with it everything but the kitchen sink to bring in all it needs from ada runtime
asciilifeform: last time i touched the subj with own hands, i concluded that elaborator isn't even permitted in static ada lib.
diana_coman: because in the docs it's claimed that non-ada main should be with the encapsulated-lib version, ugh
asciilifeform: diana_coman: if your 'main' is a c/cpp proggy , you gotta trigger the elaborator 'by hand', regardless of which type of lib your ada coad is in, afaik.
ave1: all these extra code generation in Ada is managed with gnatbind
ave1: diana_coman, look into https://www.cs.fsu.edu/~baker/ada/gnat/html/gnat_ugn_5.html#SEC73
asciilifeform: phunphakt: in ye olde bolixtron, there is an ada ( and fortran! ) compiler. (however asciilifeform has not tried either item, beyond 'hello world' )
asciilifeform: ( observe that ch1 ffa actually starts out by http://www.loper-os.org/?p=1913#selection-337.0-1150.0 , i.e. banning 90% of ada.. why didja suppose this was. )
mircea_popescu: this guy's write-up makes me want to ban ada.
asciilifeform: the world of the folx who wrote ada for moneys in the saeculum, is not , as i gather, a happy place. sorta why asciilifeform had to learn buncha things from 1st principles, rather than by reading their ugh
asciilifeform: i suspect he was 'old guard' (ada greybeard) and the bottle took its toll.
a111: Logged on 2017-11-20 23:38 asciilifeform: typical, http://adagin.blogspot.com/2013/12/ada-2005-access-types-part-i.html , lively : type Hooker_Array is array (Positive range <>) of Hooker_Class_Ptr; procedure Violate_Bodies (x : Hooker_Array); ... 'We want to track all our victims, presumably in some sort of set or container, so that we might disinter them later as needed. Similarly, we might also want to do strange, awful things with the dead bodies of the hookers.'
asciilifeform: re: ada elaboration, i found http://btcbase.org/log/2017-11-20#1741485 item useful when i was last puzzling over subj ☝︎
asciilifeform: i strongly suspect it'll have to be de-threaded to work reliably with ada-cum-tasks , sadly
mircea_popescu: now obviously, "best place for ada code is in ada program". but the issue here is how to effectually corrupt, stupidity into sense.
a111: Logged on 2019-01-06 17:28 asciilifeform: the 1st step to adaizing a cpp turd is to remove the cpp threadisms, they will not only not work with ada's sane tasking but actually destroy the guarantees of the latter
asciilifeform: diana_coman: i suspect that even if you get the thing to properly link, you will discover new headaches on acct of http://btcbase.org/log/2019-01-06#1885177 . really imho proggy that has ada tasks oughta have ada main , and (if must) call static cpp turdola, not vice-versa ☝︎
a111: Logged on 2019-01-09 14:08 diana_coman: (those are needed to do the elaboration in ada so can't do without them either)
diana_coman: as it is specific to ada, a non-ada main has no idea (nor does it care) about it and therefore won't do it automatically; the only way to have it done is to call explicitly the "init" procedure for the Ada unit that is to be used; and the only way to *have* such an init procedure seems to be the standalone lib thing
diana_coman: re ada elaboration since apparently it's not summarised in the logs as such: it's basically the code that runs *before* the main program starts and what it does is broadly initializing variables that the main program may expect to be able to access (e.g. "global" or in libs that are used) and running the "main" code (aka between begin and end of a package as opposed to that in procedures/functions) from units that are used
mircea_popescu: so basically "the way to call ada from non-ada context is called 'standalone encapsulated dynamic' in ada" is the idea here ?
diana_coman: i.e. if you want to call ada from something-else main then you don't really have any choice that works other than this
mircea_popescu: are we thus the first to try and call an ada library from a c main ?
diana_coman: mircea_popescu, no, it's an ada thing, nothing to do with cpp precisely
diana_coman: basically the only way available to make a non-ada-main do the ada elaboration
diana_coman: (those are needed to do the elaboration in ada so can't do without them either) ☟︎
diana_coman: in other eulora-client headaches: to get the cpp client to use my ada lib (that I want to keep separate! away from cpp swamp!), it seems I need to make my lib "standalone encapsulated dynamic"
asciilifeform: the 1st step to adaizing a cpp turd is to remove the cpp threadisms, they will not only not work with ada's sane tasking but actually destroy the guarantees of the latter ☟︎
asciilifeform: then you dun need to try an' pry open the internal structure of ada task to somehow fiddle it from inside cpp.
asciilifeform: diana_coman: if you 'de-thread' the cpp item, you can call its knobs from ada task. is what i meant 'reentrant'.
asciilifeform: diana_coman: admittedly i dun know enuff about your proggy to say whether it is possible to make ada piece 'prime mover'
asciilifeform: why wouldja need to fork in cpp if you have ada tasks ? make the cpp coad reentrant and call it from the tasks
diana_coman: in the vein of "fork in cpp and from that thread call Ada proc that then spawns tasks"?
asciilifeform: or, vice-versa, import and fire the necessary cpp knobs from the ada.
asciilifeform: ( i.e. ada knobs that are ordinary procedures and can be fired from the cpp )
diana_coman: asciilifeform, the concrete mess is this: smg_comms is in Ada, has sender and receiver task types so one can create those as needed, perfect; onth eulora client is this ball of CPP mess and it's unclear to me if it can even be made to use smg comms as it is or what
asciilifeform: diana_coman: what wouldja even ~do~ with ada task type from cpp ?
diana_coman: does anybody know whether/how can I use Ada task types from C/CPP code? afaik from GNAT docs there isn't a way to export task types as such
asciilifeform: for comparison, ada sores of ch14 ffa, incl. comments, weighs ~300kB
asciilifeform: ideally , one'll be able to implement any crypto scheme without having to rip into the ada; simply by writing pcode.
mircea_popescu: http://ossasepia.com/2018/03/01/eucrypt-chapter-12-wrapper-c-ada-for-rsa-oaep/#selection-133.1-133.132 << right, and you want to use ~constant time~ keccak
a111: Logged on 2018-10-26 02:14 asciilifeform: meanwhile, in gnat bugs : apparently ( and this is documented or mentioned nowhere ) : it is impossible to have a Ada.Finalization.Limited_Controlled type ANYWHERE inside a static library, unless it is generic all the way down (i.e. if the lib package is generic, any sub-packages must also be instantiated as generics )
mircea_popescu: he promised to ask you for an item ? or is this ada n-w published somewhere meanwhile ?
asciilifeform: incidentally i'll add that most published heathen ada proggies use c-style heapism, it isn't banned by the lang per se.
asciilifeform: Mocky collected the whole, iirc, set, i'ma link ftr to http://mocky.org/Log-Reference-Why-Ada/ .
a111: Logged on 2017-05-26 18:10 asciilifeform: for instance, the almost ubiquitous c-ism, of creating a pointer (ada 'access') variable on a procedure's local (stack) and passing it to something -- anything -- is illegal
asciilifeform: http://btcbase.org/log/2019-01-03#1884225 << ada is surrounded by a kind of roman 'sudes' fort , consisting of 'why the fuck does it make me do this', kills 99+% of maggots on the spot. at least that's my hypothesis re why the thing remains usable ~40 yrs after first made, unlike e.g. unix ☝︎
asciilifeform: mats: neat overview, in the style of 'why ada'
feedbot: http://bvt-trace.net/2018/12/ada-system-calls-mmap-and-stat/ << bvt's backtrace -- Ada System Calls: mmap and stat
mircea_popescu: ok, so the idea here is, that while maintaining different code on different boxes is costly and undersirable, nevertheless that is mitigated by the relative ease of the genericization/prototyping mechanism in ada ; whereas single queue model, as logically tempting as it may be, is costlier than it seems (not necessarily because insertion can't be o1, but still, machinery involved).
diana_coman: my implementation is just a bounded queue fifo, 1 item at a time in /out; and yes, I looked again at Ada's standard stuff and I could use I think a bounded_synchronized_queue container but then it forces me to put/get full structure
mircea_popescu: but ada does this.
asciilifeform quite fond of the ada thread model, it's prolly closest one can get to sanity on pc irons
mircea_popescu: in the other line, have you played with ada threads any ? are you friends ?
bvt: hello, i'm back in the saddle. i intend to finish the ada syscalls around next weekend (23.12)
asciilifeform: ( 'swallowing' is not mutually exclusive, necessarily, with supplying patches upstream to orig -- diana_coman , for instance, 'swallowed' ada-udp , but did also post patches for my tree, a+++ )
asciilifeform: no magical feature of ada
zx2c4: what you've described sounds good. im wondering if it's the result of comments, the result of just better organized code, or the result of some nice features of ada you're using
zx2c4: with good comments? or some nice feature of ada? or easy arithmetic youre implementing? or what?
asciilifeform: consider, zx2c4 , i can show that nuffin in my arithm routines can overflow a buffer. even if you were to turn ada's overflow checks off. without any complicated tooling.
zx2c4: hey ffa in ada
a111: Logged on 2017-05-10 21:29 phf`: i'm rewriting everything that asciilifeform is releasing in Ada in Rust, because it's secure AND modern!
zx2c4: also i'm wondering what the usual trilema party line is on rust vs ada
asciilifeform: it will produce garbage, yes. i considered to make OF_in a limited type, but it would slow down the place where the item is actually used, substantially ( ada does not offer a fast bit-count-on-word operation )
asciilifeform: i wasn't even immediately aware that gnat existed, thought that one had to get some TB-sized winliquishit from lockheed etc in order to ada.
phf: ftr i had no objections to ada either, i suspect the barfs were coming from peanut gallery of people who since dropped off
asciilifeform: iirc diana_coman did time in heavy industry tho, possibly less allergic to ada flavour as result
asciilifeform: http://mocky.org/Log-Reference-Why-Ada/ <<
asciilifeform: ( does errybody recall how many barf bags they went through when asciilifeform 1st suggested ada ?? )