<stikonas>fossy: ok, so I can create embed.h in perl 5.000, so that's good <stikonas>let's see if I can build miniperl there... <stikonas>hmm, miniperl 5.000 is not easy either :( I managed to build it with gcc, but when trying to build in live-bootstrap, there seem to be incompatibilities with musl and FILE* pointer... <stikonas>although, I still need to create proper config.h <stikonas>the one from my work on 5.8.9 is not usable <stikonas>so I think I'll be able to get something working tomorrow <stikonas>argh, but there are still two header files created by perl scripts... <stikonas>keywords.pl and opcode.pl -> keywords.h opcode.h <stikonas>well, keywords.h is simple enough, either we treat it as original source or write some bash script to generate it... <stikonas>we'll have to decide what to do with them <stikonas>but at least they are simpler than that embed script <stikonas>hmm, maybe we should start with perl4... <gforce_de1977>fossy: ok, had the think the whole night about: checking build-bin-hashes from external or internal and you are right: from internal is better and check from both sides is even better 8-))) i will try to make sha256 working from an early stage and add the hashes, ok? <stikonas[m]>Let's not overcomplicate with both internal and external I think, just one is enough <gforce_de1977>fossy: regarding your fletcher16.kaem: shouldt it be e.g. '-f /M2-Planet/functions/numerate_number.c' instead of '-f functions/numerate_number.c' <fossy>gforce_de1977: no, they are different <fossy>gforce_de1977: we cannot use sha256 <fossy>it is not implemented in coreutils 5.0 <fossy>stikonas[m]: oh, sorry, i forgot <fossy>hm, maybe i should recheck fletcher binaries with sha1sum <fossy>cause fletcher16 has highish collision chance <stikonas[m]>Well, we'll recheck with sha2 later, so rechecking now is optional <fossy>stikonas[m]: oh, i can implement keywords.pl very trivally <fossy>that isn't super duper hard to reimplement in shell <fossy>can you pastebin a real opcodes.h then <fossy>i'm not convinced perl4 will be able to do this <fossy>perl4 is quite different to perl 5 <fossy>if you want me to do that i can probs do that tomorrow <fossy>or you can do it if you want <stikonas[m]>Well, I'll probably spend today fixing other issues and getting it to build <fossy>ok, i'll do opcode.h and keywords.h in shell <fossy>and you can use pregenerated for now <fossy>cause it's pretty easy to slot it in <stikonas[m]>(Just need to renumber everything if you insert something in the middle) <fossy>gforce_de1977: hm ty for this <stikonas[m]>All these implementations seem to use precomputed constants... Does coreutils to that as well? <fossy>stikonas[m]: well they are mathematically generated <fossy>but yeah it is somewhat annoying <fossy>i don't have much of a problem with it either <fossy>even if it was wrong it just is not to spec <bauen1_>i'm pretty sure they're part of every implementation ***bauen1_ is now known as bauen1
<bauen1>sha256 is quite simple (and easy to verify opposed to a C compiler ...) <fossy>gforce_de1977: unfortunatly that implementation is only a library <fossy>if you (or someone else) wrote a frontend for it though i would be happy to use it <gforce_de1977>fossy: here a naive implementation, which compiles with 'tcc sha256sum.c' <fossy>mescc is probably unnessecary <fossy>gforce_de1977: this is a good implementation thanks <gforce_de1977>fossy: whats missing is something like ./sha256sum filename -check $HASHXY <fossy>it's just read from a file and compare generation <gforce_de1977>(ok, have to go in the kitchen now, the bird gets ready, awk for a while...) <stikonas>pder: do you think perl output truncation might be the same problem that you saw with pipes? <stikonas>but maybe not stdout writing but when writing tofile <stikonas>when I replaced commented open file call, it produces correct file <stikonas>anyway, miniperl 5.000 seems doable and once we have something, it will hopefully be much easier to build newer perl using that <pder>stikonas: definitely the truncation is still happening. An easy fix is make sure you close any open file handles in the program <pder>I am still looking at trying to fix this issue properly, but havent had much time to look at it <stikonas>and I think miniperl might be enough to drive autotools... <stikonas>I think I can run automake (have some unrelated problems with autoconf but that's not perl based) <stikonas>hmm, and live-bootstrap's gawk segfaults :( <gforce_de1977>some things are working (Hello World), but this segfaults: gawk '{ print or(4294967295,1) }' <stikonas>hmm, but do we know it's public domain, we can't assume that... <stikonas>yeah, so for now I'm trying to use sed instead of gawk to build miniperl <stikonas>fossy: I've generated keywords.h with sed, defines are off by one, but I don't think that matters <stikonas>this worked sed -e '1,/__END__/ d' keywords.pl | sed -e '1d; s/^/#define KEY_/' | sed -n 'p;=' | paste - - > keywords.h <stikonas>so I think if we make any changes, we can also put GPLv3... <gforce_de1977>stikonas: your sed-oneliner looks like it would be better a shell-script... (just saying), but thats something for later... <stikonas>(opcode.h should be recreated before we can merge it) <fossy>gforce_de1977: stikonas I think I will put sha-2 right after patch, that way we dont have to vendor files (which I dont really enjoy doing) <stikonas>fossy: so I've done the easy file for now in perl (keywords.h) <pder>stikonas: I might have a better musl fix for the truncated output shortly <pder>Did you work around your issue by doing an fclose before exiting? <stikonas>pder: no, I didn't look at it yet, but it might not be critical <stikonas>pder: it might be causing problems with perl scripts that we need to bootstrap perl more properly but I think automake might be working fine <pder>stikonas: I just pushed a branch stdio-flush-on-exit. Seems to be working better and doesnt require my previous patch. <pder>On a side note, we can easily rebuild bash now with CC=tcc AR='tcc -ar' bash configure --without-bash-malloc && make <pder>But I know we would like to have autotools before running configure scripts <stikonas>pder: yeah, I think we should try to run autotools first <stikonas>I'm not an expert on autotools though. Do we need to have different versions of autotools for different software? <stikonas>pder: I guess bash is interactive because it builds with readline?