593 entries in 0.146s
bvt: asciilifeform: http://bvt-trace.net/vpatches/ffa_ch1_genesis.kv.vpatch.bvt.sig http://bvt-trace.net/vpatches/ffa_ch2_logicals.kv.vpatch.bvt.sig http://bvt-trace.net/vpatches/ffa_ch3_shifts.kv.vpatch.bvt.sig
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: hello
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: billymg: i fixed the links to the images manually, working over version rolled out by BingoBoingo (http://btcbase.org/log/2018-11-12#1871585) ☝︎
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: thx asciilifeform
bvt: the genesis.vpatch from vtools vdiff is here: http://bvt-trace.net/pub/genesis.vpatch the one from sha512sum vdiff: http://bvt-trace.net/pub/genesis-sha512.vpatch
bvt: trinque: i also have problems verifying the genesis.vpatch that i got from running ./bootstrap.sh. 1 question: which exactly vdiff should i use? the one from vtools or from http://barksinthewind.com/2018/vdiff-fixes/ ?
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: http://btcbase.org/log/2018-11-19#1873686 << this part is crystally clear ☝︎
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: http://btcbase.org/log/2018-11-19#1873678 << what i did not like was following: specifically going for 'api at the tree root' variant, and then bolting on new (platform-independent) apis later. ☝︎
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: http://btcbase.org/log/2018-11-19#1873583 << this is unfortunate, i won't have possibility to work on this code in coming days; there will be a vtree stump for ~2 weeks. ☝︎
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: http://btcbase.org/log/2018-11-19#1873575 << this is why i'd like to work on struct stat (well, it is also required for mmap): fairly complex structure, which differs across architectures. ☝︎
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: hello
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: ok, so the discussion seems to be here: http://btcbase.org/log/2018-06-25#1829429 , and unlike me, spyked did publish the 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: have you seen https://github.com/Componolit/libsparkcrypto ? their modexp code looks sad, but other components may be interesting
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: http://btcbase.org/log/2018-11-12#1871493 << first, i'd like to do a linux syscall ada tree (focusing on 4 syscalls first: openat,close,mmap,stat) for aarch64 and intel arches. ☝︎
bvt: http://btcbase.org/log/2018-11-12#1871478 << fixing/replacing the theme is on my todo list, however i still haven't fixed all the problems in wp-admin (png/jpg vs svg), so work on the theme will have to wait a bit. ☝︎☟︎
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: trinque: thanks!
bvt: report kind
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: diana_coman: ah, i see. if the c89 vs c99 is the issue, than this vpatch takes the wrong approach, and something along the lines of http://p.bvulpes.com/pastes/o7yc9/?raw=true would work better
bvt: meanwhile, http://bvt-trace.net/2018/11/gnat2017-gcc-breaks-smg_comms-mpi-extern-inline-function-issues/ ☟︎
bvt: trinque: would it be possible to add my blog to deedbot RSS feed? http://bvt-trace.net/feed/ should work.
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: hello, i have finally genesised the ada base64 lib: http://bvt-trace.net/2018/11/base64-genesis/
bvt: of course, > 3/4 of all restrictions are contagious, so you are right
bvt: i.e. https://docs.adacore.com/gnat_rm-docs/html/gnat_rm/gnat_rm/standard_and_implementation_defined_restrictions.html#partition-wide-restrictions
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: No_Unchecked_Access is such restriction; i have tested a dummy application that does nothing but import and instantiate/specialize Ada.Sequential_IO instance for the datatype from base64 library. test application fails to compile, http://p.bvulpes.com/pastes/Vwno8/?raw=true http://p.bvulpes.com/pastes/qgs7E/?raw=true
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: hello. i wrote a summary for linux system call investigation http://bvt-trace.net/2018/11/linux-portability-part-3-summary/ ☟︎
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: http://bvt-trace.net/2018/10/linux-portability-part-2-exploring-musl-ifdefs-or-define-pdp_endian-3412/
bvt: hi, i have made some exploration of linux syscall interface (using musl) http://bvt-trace.net/2018/10/linux-portability-part-1-exploring-musl-architecture-specific-headers/
bvt: at this point -- bis morgen!
bvt: http://bvt-trace.net/2018/10/vpatch-replacing-mktemp3-take-two/ - please have a look
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: well, http://git.musl-libc.org/cgit/musl/tree/src/network/connect.c -- the structure is the same; digging is rather easy, if you don't look into glibc
bvt: *having
bvt: syscalltronic = based on direct invocation of linux syscalls? how this would be possible without haveing sockaddr_in in ada?
bvt: ok
bvt: but maybe, only the subset you need for mmaptron, for starters? full conversion is definitely not worth it
bvt: *these
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.