1000+ entries in 0.11s
bvt: i would try to make some sort of write-up about this. i wanted to suggest making a
Ada library that exposes a subset of Linux system calls without C code, because i clearly needed it for the tempfile.
diana_coman: yes; basically
Ada makes it easy enough to not have to force anything; funny how
Ada is in fact *very* accommodating - where it makes sense to be
lobbes: it would be an interesting project to learn some basic
ada with
diana_coman: mircea_popescu, once this is in place, it should be relatively painless to swap at a later stage (whenever available) the C rsa/mpi for an
Ada implementation since it's basically kept well separate
diana_coman: will probably cut it in 2 parts two, namely the wrappers first and then the whole big .vpatch bringing in everything needed (mpi, keccak, oaep-but-this-time-from-
ada-only)
diana_coman: and everything will be called from
Ada only, not the other way around
diana_coman: in other news from the smg comms front: the rsa pack/unpack turned a bit nastier than the nice serpent because (of course!) of the C element; basically the rsa operations are in C (mpi mess) while the oaep is in
Ada and the current eucrypt wrapper is fine but doing the ugly dance of C to
Ada *and back*; my solution to this is to decree that there will be only ONE direction of calls namely from
Ada to C (because
Ada is the main, desired par
phf: no no, that's an unreleased enable sha512, so my point is that it must be something in
ada/c interop, or the particular way i do it in vdiff: ksum works though it uses same interface, vdiff sha512 works though it uses an architecturally identical sha interface.
phf: hmm, i wonder if it's maybe c/
ada interop? straight ksum gives me the answer, and it uses the same incremental mechanism (already trie)d
deedbot: ave1 rated spyked 2 << wrote a scheme in
Ada ave1: !!rate spyked 2 wrote a scheme in
Ada mircea_popescu: things are kinda deliberately made to dovetail with
ada, so i hope they do and if they don't we fix.
diana_coman: it might really be that my
ada-fu is not up to the task yet
bvt: it seems that 'c strings' in
ada are still controlled by
ada mechanisms, i.e. they are
ada strings (with bounds checking), just with null byte in the end
a111: Logged on 2018-10-15 03:01 mircea_popescu: bvt "
Ada exposes no functions that have 'exclusive open' semantics, so I imported C
bvt: re naming: i agree that it clashes with
Ada naming convention. will rename to Temporary_File.
a111: Logged on 2018-10-15 01:53 phf: oh i guess i see why that would be tricky, because of the specialization. i don't know enough
ada yet to know how to fix that... perhaps just renaming it to Temporary_File is sufficient
a111: Logged on 2018-10-15 01:13 phf: so it looks like bvt is correct, there's no way to make
ada's Create throw an exception if the file already exists
mircea_popescu: bvt "
Ada exposes no functions that have 'exclusive open' semantics, so I imported C
☟︎ phf: oh i guess i see why that would be tricky, because of the specialization. i don't know enough
ada yet to know how to fix that... perhaps just renaming it to Temporary_File is sufficient
☟︎ phf: the other thing, and that's somewhat of a personal preference, i think Create_Temporary_File should either act identical to create or be called something else. right now it clashes with
ada's naming convention
phf: so it looks like bvt is correct, there's no way to make
ada's Create throw an exception if the file already exists
☟︎ Mocky: so long as you can assume one tru packet size, you can get some
ada benefits + extra simplicity, that you don't get otherwise, no?
bvt: right,
Ada.Directories.Exists was the missing piece.
phf: bvt: this doesn't need much C, it's a loop with a termination condition of not
Ada.Directories.Exists(Filename), and the tricky part is the construction of said Filename. it could be a Prefix ("vpatch.") + keccak hash(salt + pid + time + ???).
bvt: i will give it a try. i'm still learning
ada, will have to take a look at how strings and interfacing with C are done properly.
phf: i like that
ada will create a temp file for you and then clean it up on empty string, though that's a bit too magical (the interface, not the behavior)
bvt: 2.
Ada internally uses mkstemp(3) to generate a random name when empty string is passed as filename to Open procedure.
deedbot: asciilifeform rated bvt 1 << n00b,
ada/vtronics experiments
bvt: GNAT 2016 runtime deletes all files with temp bits at the Finalization stage, so everything should work fine. (Not an
ada specialist, so when finalization is actually run is a mistery to me)
phf: differ is also c code, i wanted to figure out how to make the rename tracking algo pure
ada, and then have it drive the differ, rather than writing more c code, but i'll see if i can manage it
diana_coman: aaand if I get it right, GNAT.CRC32 uses
Ada.Streams.Stream_Element and it expects a String as input so overall it really sounds like back to GNAT.Sockets style, ugh
diana_coman: really? I thought there was a site you were recommending precisely for "good
ada code", wasn't there?
mod6: yeah, this is the right approach imho. it's what i'd do with my
ada-vtron, if it ever does breathe.
mod6: I had started on a
ada vtron last year, but I got hung up with some of the string handling, and the fact that I had to use shell-outs for pgp. I'd like to get back to it at some point. I would love to dispense with the shell outs - and can probably do so, but not until 'peh' is finished.
diana_coman: (it can be done though, if one really wants it, basically an
Ada task to be repeated hourly, but I don't see the benefit to that)
diana_coman: asciilifeform, the IP_To_String will return a string with null chars (in
Ada: Character'Val(0)) at the end for IPs that are shorter than 16 chars (e.g. 98.20.105.41); I'm in 2 minds whether to make it change those to spaces (keeps size same) or otherwise return some len; since it's your lib though: what is your take on it?
phf: hmm, i have the path set, but i don't have either of the ADA_* vars
a111: Logged on 2018-09-22 03:05 phf: ave1: i'm getting the following error
http://p.bvulpes.com/pastes/49Tie/?raw=true when building
ada-musl-cross-2018-06-01. i feel like it came up before, but i'm having hard time finding the thread
phf: is
ada-musl-cross-2018-06-01 the latest version of ave1's
ada?
diana_coman: in other pleasant surprises, this generic thing in
ada is very useful
diana_coman: fwiw, I'm also quite grateful that ave1 published it now - it pointed me to
ada inline assembler (I hadn't really looked at it before!) and it gives me some time to hopefully get a bit more used to it *before* I'll need it anyway
mircea_popescu:
ada threading still seems as promising as it did weeks ago. few things survive this long lol
diana_coman:
http://logs.bvulpes.com/trilema?d=2018-9-18#431566 -> I'm thinking of 2 there ; asciilifeform's lib also provides I think a good interface - I don't see any reason why one couldn't just change /swap the underlying .c file with
ada or asm at a later date without having to change otherwise anything of whatever one builds on top of the lib (i.e. relying on the lib's interface)
a111: Logged on 2018-09-18 13:05 diana_coman: for completeness, version 3. GNAT.Sockets.Thin that is an
Ada wrapper on C system calls containing however questionable approaches (e.g. returning access to String so effectively a pointer but worse than this: allocating memory on the heap and leaving the de-alloc to the caller...)
diana_coman: asciilifeform, ah, I forgot to mention it explicitly but yes, my tests include ave1's gnat as well as adacore's gnat; this is pretty much for any
ada code I test
mimisbrunnr: Logged on 2018-09-18 12:37 diana_coman: to round this whole thing up: 2 days ago it seemed I had only the gnat.sockets/ thin layer option which wasn't fit for purpose; now I have 2 more options: 1. ave1's
ADA implementation of UDP sockets using directly ASM inline 2. asciilifeform's light UDP sockets lib that uses C code for needed UDP sockets calls but provides an
Ada wrapper so that any code using the lib can call
Ada methods
diana_coman: asciilifeform, if I understand your lib correctly, it aims to expose only a strict & minimal set of UDP calls; atm it uses C code for the actual socket part but in principle this layer could be replaced at a later time by some
Ada layer while keeping the rest as it is, correct?
diana_coman: for completeness, version 3. GNAT.Sockets.Thin that is an
Ada wrapper on C system calls containing however questionable approaches (e.g. returning access to String so effectively a pointer but worse than this: allocating memory on the heap and leaving the de-alloc to the caller...)
☟︎ diana_coman: to round this whole thing up: 2 days ago it seemed I had only the gnat.sockets/ thin layer option which wasn't fit for purpose; now I have 2 more options: 1. ave1's
ADA implementation of UDP sockets using directly ASM inline 2. asciilifeform's light UDP sockets lib that uses C code for needed UDP sockets calls but provides an
Ada wrapper so that any code using the lib can call
Ada methods only
mircea_popescu: anyway -- fuck 'em, i deeply fucking care some nobody-on-a-stick meanwhile joined the churchgoing group. whatever. but in matters of actual interest : you "were working" on an
ada networking socking thing ; ave "was working" on ~same. had diana_coman not said "here's what ~~~I AM ABOUT TO DO~~~", we would have never known. if the wastefulness of this approach isn't directly obvious...
diana_coman: at any rate ave1 this doesn't look bad at all in that it is an
ada layer rather than just wrapping the c calls
ave1: I'm also working on a thin networking layer for
Ada (using direct system calls in inline assembler). I got stuck on some inline assembly details and once that was resolved I got stuck on the whole select/epoll/kevent support and so forth. So at this point,
http://btcbase.org/log/2018-09-16#1850668 applies.
☝︎ mircea_popescu: how are you going to handle the weird data models implied by teh nutty syscalls in an
ada proggy ?
mircea_popescu: are you going to write an
ada program to treat c-defined syscalls as black boxes and spit out
ada acceptable output ; opr are you going to write a c program to treat c-defined syscalls as compatriots and spit out
ada acceptable output ?
diana_coman: I don't know what an "
ada system call" is, to answer that question; my aim is indeed to wrap them in one place so that everything else makes
ada calls and doesn't care
mircea_popescu: more specifically : what exactly is the limit of the "c-ness" of the system calls ? can we pretend they're
ada system calls until they are ?
a111: Logged on 2016-04-06 15:49 asciilifeform:
ada tasks, afaik, is the only sane implementation of parallelism where you ~never~ specify explicit thread
a111: Logged on 2018-09-14 12:37 mircea_popescu: anyway, reading through this, i suspect
ada threading may turn out to be a pleasure.
diana_coman: I recall a link to examples in
ada; fwiw I think they are even gone from that link at least; was that "nqb"?
mircea_popescu: anyway, reading through this, i suspect
ada threading may turn out to be a pleasure.
☟︎ mircea_popescu: i suspect that the federated calling model of the current bash is actually its strength ; and not necessarily competed by lisp-
ada.
a111: Logged on 2018-04-05 19:11 asciilifeform: imho the long-term answer is '3rd way' , i.e. all the crud i wrote in bash, python, etc over the years really oughta be in the hypothetical little-lisp-in-
ada from old thread.
Mocky: apparently stepanoff wrote the generic list processing for
Ada but saw that c++ would be more popular so then wrote stl as researcher at HP
ben_vulpes: trinque flagged whitaker's words for me as a latin dictionary (an
ada artifact even!)