593 entries in 0.11s
bvt: as far as code speed is concerned, i still don't know whether i fucked up something, or the algorithm is fundamentally slow after some bignum size
bvt: re math, i found that htmling it would be unreadable, so decided to use images.
bvt: billymg: i assume v.py pressed genesis, started checking hashes and errored out before applying next vpatch (with your changes).
bvt: i.e. in hanbot genesis, there is a/mp-wp/manifest, while in your vpatch a/manifest
bvt: billymg: it seems that you should move directory mp-wp into directories a, b, not rename them.
bvt: BingoBoingo: thanks, everything works fine
bvt: the result of command from 'enable uploader' message is 'permission denied'. afaik changing owner of a file works only for root.
bvt: hello. BingoBoingo: applied and tested the changes from your first message, everything works. ty!
bvt: !!v D5DED9B7DD684165898340F6744BAC899B3EC60A24D993773C612FB83D45FB11
bvt: hello, i'm back in the saddle. i intend to finish the ada syscalls around next weekend (23.12)
bvt: howeve i see that you are stracing a vk.pl, not vpatch itself. tracing vk.pl would give too much information, it would help to see only strace -f vpatch < patches/eucrypt_genesis.vpatch
bvt: please use strace -f
bvt: lobbes: i am also interested in learning which gnat version/type and vtools leaf was used, and seeing strace output; i thought this error can happen only on adacore gnat >=2017 with a strict libc (which rejects 3-character template)
☟︎ bvt: thanks for discusion, asciilifeform, diana_coman. i'm off to bed.
bvt: i do understand the philosophy behind v (definitely not complaining), but i lack practical experience working with it, so it was useful to get explanations re tree structure.
bvt: no disagreement/misunderstanding here
bvt: but i see how this is the correct process, and just a bit more optimized case of what i planned with branches diverging at the genesis (saves reader some labour of reading same vpatches in each branch). and if tree becomes to messy, can regrind.
bvt: but i would agree that one's understanding of vtronics is determined by ones toposorter implementation.
bvt: alternatively, i could add new functions at common tree part if i don't touch any files included in later vpatches (so adding entries to manifest would be not possible). seems like some quite unnatural acrobatics to me.
☟︎ bvt:
http://btcbase.org/log/2018-11-19#1873650 << well, if i do common part (api) first, then diverging system-specific branches, i still could add new functionality on top of *each* of these branches. i don't like this option.
☝︎ bvt: and also i got useful feedback (thanks, diana_coman!)
bvt: i totally agree with all these points. tree diverging after empty genesis is separate enough in my view.
bvt: i hope that for tmsr.os most of these things will become unnecessary; lower levels of libc/libada are not the right place to fix the underlying problem.
☟︎ bvt: ftr, i don't expect that i will make this tree without a single regrind
bvt: yes, i can definitely see that. scope of the tree must be fixed at the moment of creation. which is not necessarily a bad thing.
bvt: otoh, if system call asm packages are at the tree foundation, the api uniformity will be enforced by convetion only, and the branches will diverge right after genesis.
☟︎ bvt: for example, ftruncate is also useful for mmaptron, should it go in?
bvt:
http://btcbase.org/log/2018-11-19#1873573 << i will have to think more about vtree organization. if i use api as the foundation for the tree, adding new system calls would cause regrind; in this case, the api should be complete from day one.
☝︎☟︎ bvt: i want the platform-specific branches to be glued together because API for users should be the same in all of them. so that user can press a branch for aarch64 or x86 without changing anything in his code.
bvt: 2. i seem to remember but can't find right now a discussion (around time spyked published adalisp) that making such a genesis should be ok. perhaps i am confused about the context of that discussion and did something stupid.
bvt: 1. x86 and arm trees will diverge pretty much from the start, i can't see how anything useful and complete can be packed into genesis.
bvt: mircea_popescu: i understand that empty genesis (well, it's not precisely empty, there is a manifest file) is suboptimal, however:
☟︎ bvt: asciilifeform: is remerging portage with USE=-rsync-verify an option? you can downgrade to gpg1 afterwards
bvt: if i manage to do something usable this weekend, i'll genesis that, otherwise i'll make an empty genesis and just outline the work i expect.
bvt: mircea_popescu: unfortunately i can't provide a timeline for the syscalls yet: between 19.11. and 07.12. i will have time for only very minor work, following logs, etc.
bvt: though i have nothing against work on bignum multiplication and modexp -- but as i see it, it could be a side branch of ffa. ffa already provides a solid foundation for such algorithm exploration.
bvt: i have also restored your comment in it's sane form. separating the < and > with spaces (s#<# < #) avoids html detection, though adapting one's habits to wp behavior is definitely not a solution.
bvt: diana_coman: i have updated the article with links to the logs. i confirm that using -std=gnu89 fixes the issue. -std=c89 -- does not.
bvt: also, i think that pushing gcc-6 patches to frozen system (mpi) defeats the purpose of the standard republican compiler, so the post and vpatch is more of
☟︎ bvt: i'll check wtf is wrong with the comments system
☟︎ bvt: !!v 239ACABD3C860AC0B49ACB3A0A3E941EF260C91E3A89ED0F9CAA218226643CA1
bvt: asciilifeform: thanks. radix-64 (gpg ascii armor) is pretty similar to the RFC base64, so changes to the code will be minimal.
bvt: of course, > 3/4 of all restrictions are contagious, so you are right
bvt: what i have fished out trying to solve the problem is that only a subset of restrictions should be contagious
bvt: i dunno if gnat people even tried to implement finalization for static libs/bins. i guess cpp supports destructors in statically linked code?
bvt: so far i had a look only in the runtime, but never looked into the gcc part
bvt: myeah, i solved it by maximally recreating the ffa project structure, so can't say i did anything informed by the 'first principles' there.
bvt: otoh, when i added a single line 'package SIO is new Ada.Sequential_IO(Positive);' to ffa_calc.adb, it errored out during the compilation in the same way
bvt: when i moved all ada.S_IO usage to a separate package/file, everything worked fine
bvt: ok, i have figured out one solution to the problem (at least on gnat 2017): can't have Ada.Sequential_IO specialization in the GPR_Project'Main file
bvt: to clarify: base64 lib and applications are two separate gprbuild projects, -gnatec=base64/restrict.adc flag is only in the library project
bvt: i have structured the base64 tree as a directory with a library and example applications; only library is supposed to be compiled with restrictions, but some restrictions propagate to applications as well
bvt: just tested ffa-8 where rng was introduced -- it works fine. would be trying to understand what is wrong with my code, then
bvt: but yes, it is adacore -- not the default sad gcc implementation
bvt: that is gnat 2017 with ave1's patches (i.e. musltronic)
bvt: i used gnat 2017. will test ffa rng code and see if it works out.
bvt: in the end, just disabled the restriction.
bvt: i had a look in the .ali file, where presumably list of dependencies for a compiled .adb file is stored, but grep would find nothing in the dependencies
bvt: found and unexpected problem that specialization of Ada.Sequential_IO conflicts with Restriction(No_Unchecked_Access) in the test applications.
☟︎ bvt: hello. i had to delay making a genesis of base64 lib, will try to finish tomorrow.
bvt: mircea_popescu: acronym from my name
bvt: i also intend to genesis a ffatronic base64 encoder/decoder that i wrote as an exercise (also todo for the weekend).
bvt: can't say these results are any useful until i write a summary (todo for saturday).
bvt: at this point -- bis morgen!
bvt: well, i did not suggest learning/utilizing C api, on the contrary, a subset of kernel stuff in ada is the interesting thing. it just happens to be currently defined/documented as C code.
☟︎ bvt: syscalltronic = based on direct invocation of linux syscalls? how this would be possible without haveing sockaddr_in in ada?
bvt: but maybe, only the subset you need for mmaptron, for starters? full conversion is definitely not worth it
bvt: the thing is, structure definitions and all sort of flag numbers appear in the libc via magic. having all this things in ada is possible, and would involve exactly same work that e.g. musl people are doing today
bvt: everything system-dependent that i've seen in gnat runtime goes into C code.