1200+ entries in 0.159s
ave1: then the
ada-build.sh needs adaptation
diana_coman: asciilifeform, nosuchlabs.com/pub/
ada/ave1/muslaarch64-linux-muslada.tar.gz should be for the rockchip, correct?
ave1: same as last time, ADA_OBJECTS_PATH and ADA_INCLUDE_PATH need to be *not* set. I can add the resetting of these variables to the script, but unsetting a variable is not something I usually do in a script.
mircea_popescu: ave1, if you feel like taking a break from diddling
ada, feel free to walk the github/bitbucket/we db. spit out keys in the republican format (
http://btcbase.org/log/2016-05-20#1469647 ). it'll take a day or two to put in, and the chances of the new set being devoid of lulz are ~0.
☝︎ ave1: I suspect the
ada makefile(s) have a problem with some of the rules
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: mircea_popescu: thanks too for prodding me about
Ada-vtron. I'll poke at it as I can, for sure.
a111: Logged on 2017-06-09 17:17 mod6: speaking of
ada stuff. i did get horsecocks to compile just fine with the changes that were discussed previously with diana_coman
mircea_popescu: mod6, there's no rush there, esthlos had 90% of a working lisp v, i expect it can be tweaked into a deliverable. can have
ada v later on.
mod6: The problem with the
Ada version is the string parsing.
mod6: <+mircea_popescu> hey mod6 how's your
ada v coming along ? << Still stuck in the drawer. I haevn't even touched it since Q3 of 17. I'm distinctly intersted in rawtx tools getting into trb, currently.
lobbesbot: asciilifeform: Sent 8 hours and 46 minutes ago: <ave1> The gcc makefiles use gnatls to find the runtime system directory, they do 'gnatls -v | grep adalib'. When ADA_OBJECTS_PATH is set, that line will return two directories and the build fails. Could you past the output of gnatls -v? (I can fix it with an extra head or tail call, but that also seems fragile)
ave1: !Q later tell asciilifeform The gcc makefiles use gnatls to find the runtime system directory, they do 'gnatls -v | grep adalib'. When ADA_OBJECTS_PATH is set, that line will return two directories and the build fails. Could you past the output of gnatls -v? (I can fix it with an extra head or tail call, but that also seems fragile)
ave1: As far as I can see, the culprit is this part "-I/opt/gnat/lib/gcc/x86_64-pc-linux-gnu/4.9.4/rts-native/adalib /opt/gnat/lib/gcc/x86_64-pc-linux-gnu/4.9.4/rts-native/adalib/../adainclude", It contains a space in the "-I", so now gnatmake thinks it needs to build an "adainclude" which will fail. I'll look into how these vars a set. (It's the ADA_INCLUDES flag in the makefile).
ave1: I've run on multiple systems (ubuntu and redhat), procedure has been to unpack the adacore binary file, set path and go (no ADA_*_PATH)
ave1: ADA_OBJECTS_PATH and ADA_INCLUDE_PATH
ave1: look at build-
ada.sh (I did not update the documents etc)
ave1: (sorry build-
ada.sh)
ave1: You can clear it or keep it, You'll need to run ./
ada-build.sh <DIR>
ave1: Aha, I should have cleared that one, it will be overridden by the build-
ada.sh script
danielpbarron: "huh what's that for? i'm here to show you my
ADA bitcointron i wrote"
mircea_popescu: well, in the sense of, do you bash ? do you c ? do you
ada ? do you what ?
a111: Logged on 2018-04-12 20:55 asciilifeform:
ada's spark is a similar, if somewhat uglier/bulkier, thing
a111: Logged on 2018-02-02 22:32 asciilifeform: idea is a
http server in <1000 ln of
ada, approx.
mircea_popescu: zx2c4 and the good news is, linus permitted
ada modules before.
zx2c4: ill give
ada a look. ive long heard about it but never dived in
mircea_popescu: and could you guess WHY it wouldn't make it upstream ? because
ada object-links with c object code np.
zx2c4: i dont have enough exposure to
ada to say for certain. how come?
mircea_popescu: could you guess, zx2c4 , why we would favour
ada for finnicy work such as crypto libs ?
zx2c4:
ada kernel modules? cool
mircea_popescu: yes, that's how wer dop it. do you happen to be familiar with diana coman's work on the
ada impl of rsa/keccak etc >?
mircea_popescu: mod6 well, which way do you want to go ? i assumed that was kinda your plan, bake
ada vtron, meanwhile maintain perl one functional but not really ugprade or anything. or ?
mimisbrunnr: Logged on 2018-04-09 15:16 mircea_popescu: the good news for you mod6 being that you don't really have to do anything ; v.pl is fine as it is, for now, and once phf has a prototype walker you can just move on to that and it'll be cheaper. continue work on your
ada guy in the meanwhile at your leisure, seems we're converging that way.
mircea_popescu: the good news for you mod6 being that you don't really have to do anything ; v.pl is fine as it is, for now, and once phf has a prototype walker you can just move on to that and it'll be cheaper. continue work on your
ada guy in the meanwhile at your leisure, seems we're converging that way.
phf: i suppose that's one way to release btcbase source: slowly rewrite it all in
ada ave1: asciilifeform, yes I know, I've not tried to separate AdaCore's
ada from AdaCore's gcc backend (to FSF gcc backend). AdaCore's gcc backend has significant canges from FSF. As this would be an interesting experiment, I will put it on the list (other thing to do, is put
Ada 2017 on top of gcc 4.9.4 instead of 7.x)
mircea_popescu: #
ada is asleep ; and in other lulz dbotton disappeared. (guy used to run getadanow.com, maybe still does)
a111: Logged on 2018-03-30 20:47 phf: the retrospectively unpleasant part of this approach is patching vdiff's C, which, after writing a bunch of
Ada, is torture. i believe diana_coman had similar experience
phf: the retrospectively unpleasant part of this approach is patching vdiff's C, which, after writing a bunch of
Ada, is torture. i believe diana_coman had similar experience
☟︎ ave1: I'll try it the coming weeks, I have a minimal
ada anyway
mircea_popescu: anyway, let's restate : "since you're stuck with a c library anyway as long as you're on c-machine, at the very least to do init and end ; and since musl is not that terrible and only links what you use anyway ; just use it and be done with the headache -- the alternative is bloating
ada with nonsense"
ave1: So you've written that part in
Ada but it's more clumsy as it would have been in C (because your shuffling around with C arrays)
ave1:
http://btcbase.org/log/2018-03-29#1790899, I'm saying use the musl C library for the "no C library on a C machine", if you do all the things it does yourself, you get the same kind of code. For example, you could do this all in
ADA but you'll still have to shuffle pointers around and get this "unsafe" but it's written in
Ada code.
☝︎ lobbesbot: mircea_popescu: Sent 6 hours and 18 minutes ago: <ave1> re:
http://btcbase.org/log/2018-03-28#1790127, not close at all. I do have a script to make a musl C library based
ada (and one with a minimal
Ada library). No C library only makes sense for systems without an OS.
ave1: !Qlater tell mircea_popescu re:
http://btcbase.org/log/2018-03-28#1790127, not close at all. I do have a script to make a musl C library based
ada (and one with a minimal
Ada library). No C library only makes sense for systems without an OS.
☝︎ ave1: !~later tell mircea_popescu re:
http://btcbase.org/log/2018-03-28#1790127, not close at all. I do have a script to make a musl C library based
ada (and one with a minimal
Ada library). No C library only makes sense for systems without an OS.
☝︎ phf: in this case the issue is the "legacy" diff code, removing autotools scaffolding means having to track down these kind of portability issues, that appear exclusively around "optimized" code.
ada core is its own, separate can of worms
diana_coman: hanbot, if it's an
ada project, you don't need make, just go "gprbuild" in its dir
hanbot: i haven't put together anything special for
ada yet. what was that supposed to be, install gnat (which ?)?
a111: Logged on 2018-03-08 17:41 asciilifeform: mircea_popescu: the directly analogous to 'hong kong' algo would be (brace yerself) separate processes for
ada and c-crapolade, connected via ipc (under a unixlike, prolly 'domainsocket'). because otherwise, they live in same process, and if c-crapolade is entrusted with making e.g. a valid adastring, it can lie about the length and hose the
ada routine, or simply fandango over address space as c-crapolade is wont to, and so forth.
mircea_popescu: "It is very important for
Ada 95 programs to be able to interface effectively with systems written in other languages. To achieve this goal we have supplied three pragmas for interfacing with non-
Ada software, and child packages Interfaces.C, Interfaces.COBOL, and Interfaces.Fortran which declare types, subprograms and other entities useful for interfacing with the three languages." reads to me like "it is very important for
a111: Logged on 2018-03-08 17:21 phf: so ada95 only has from_c/to_ada, using char_ptrs/char_array, pointers only appear in ada2000. ~maybe~ they ran into limitations of that interfaces, that are somehow imposed by the spec, that we're missing (but running into effects of that), so to address the issue they introduced yet another method.
phf: in this case though hong kong would be if we could beat the authors of c code into providing
ada conformant interfaces for us. because if you're the same person who's writing
ada and who's writing the interop code (in
ada or C, it doesn't matter) you're still "talking in orc"
phf: so ada95 only has from_c/to_ada, using char_ptrs/char_array, pointers only appear in ada2000. ~maybe~ they ran into limitations of that interfaces, that are somehow imposed by the spec, that we're missing (but running into effects of that), so to address the issue they introduced yet another method.
☟︎ phf: i think i might've still used yet another
ada/c interop. it's not the char_ptr, it's interfaces.c.pointer
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...)
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...)
☝︎☟︎ diana_coman: I am not using To_Ada or To_C so they can be removed, not an issue
ave1: After that, as it turns out,
ada still produces some code which is not supported by the zfp lib. I fixed some of this, but this is very much a build - add some code - retry cycle and that will take some time.
ave1: The function versions of To_Ada and To_C need to be removed + exceptions raised
deedbot: diana_coman rated ave1 2 << useful and clearly reported work on
ada &
ada+c; writes at ave1.org
diana_coman: ave1, I tried compiling eucrypt & components using your runtime: need support for Interfaces.C (used by keccak/oaep) and
Ada.Unchecked_Conversion (used by Serpent)
phf: i'll try my implementation against arbitrary binary data, because right now i'm still passing in C strings essentially. (i've discovered the null trim issue because one of the buffers ran short, and had stale data in it, so
ada was getting a character, where null was expected, but the data itself didn't have anything umseemly about it)
diana_coman: that Hash was the very first attempt, taking To_C and To_Ada at face value
diana_coman: and it sometimes stops too soon, basically it fails to copy everything ( this is To_Ada but To_C was even more hairy)
phf: diana_coman: take a look at my recent code for
ada/c interop. i've not read your C code closely, but i think you might be missing Trim_Nul => False/Append_Nul => False on your to_c to to_ada, which would trigger sporadic exceptions in the interface code