<stikonas>ok, yacc uses only 13 headers... from libc <stikonas>but yeah, it might not be wchar, could very well be something else, like ctype <stikonas>fossy: I did some debugging, so yacc chokes on ' <stikonas>although, my printf was just symptom, not a cause <stikonas>fossy: in case you look at yacc later today, I suggest starting from y2.c file and tokname stuff <stikonas>e.g. on line about 446 there is j = chfind(0, tokname); <stikonas>and as parsing goes on, j's become different in glibc and mes versions <mihi>hi, quick status about my guile psyntax bootstrapping attempts: I managed to build a (~60 lines) implementation of Lisp-style unhygienic macros using only Guile primitives that can be loaded before psyntax-pp.scm is loaded. It may still have some bugs or missing corner cases, but works well enough to load janneke_'s quasiquote and syntax-rules implementation. My plan would be to use this crude macro support to <mihi>define simple/incomplete versions of more things needed by psyntax.scm (e.g. syntax, quasisyntax, syntax-case ...) and then try to load psyntax.scm to then finally dump psyntax-pp.scm. <mihi>Should be easier than implementing all of this in C, the main question is "will 70% of (Lisp/scheme) programmers understand it?" :) <xentrac>I don't know what 70% of Scheme programmers will understand <mihi>xentrac, you can have a look if you understand it <xentrac>but it would still probably take me an hour or two to figure out what things I didn't understand <xentrac>it'd probably be helpful to have a one-line comment above each definition explaining what it's for <mihi>xentrac, be assured it took me more than an hour or two to dig through the bowels of guile to find the primitives I need :) <xentrac>if I were kibitzing I'd suggest breaking out s1*-subexpand into s1*-subexpand-args, s1*-subexpand-top, and s1*-subexpand-let-args, but since I'm not actually going through the work to really understand this, just consider that as a possible idea to consider, rather than an actual recommendation <mihi>xentrac, comments for step 1 added <mihi>xentrac, I was considering this too, but at this point of guile's loading we cannot reference future functions, and the functions would be mutually recursive. so I'd have to use some ugly letrec* syntax instead (at least I find it ugly) <mihi>I should add a comment here too. <OriansJ>mihi: thank you for looking into psyntax.pp for us <OriansJ>as guile should be able to be compiled by TCC and once we solve psyntax.pp Guix will be fully bootstrapped (provided fossy and stikonas work on live-bootstrap can be tweaked leverage that work to generate the Guix bootstrap) <OriansJ>although I think janneke will be happy to no longer have to develop mes.c and just use Gnu Guile <OriansJ>once guile is properly bootstrapped. <OriansJ>and then guix's bootstrap binary is reduced to just that bootstrapped guile. <OriansJ>Then guix becomes "Once you have Scheme, you are bootstrapped" ***ChanServ sets mode: +o rekado
<OriansJ>siraben: no, but mihi is starting to work on it from another direction <siraben>OriansJ: what's the other direction? <OriansJ>siraben: using guile without psyntax.pp and trying to implement syntax-case in only the scheme primitives it has in C. <OriansJ>well we will know more as it goes along. Right now it is missing some essentials like an explicit FSF approved license; so I haven't seen past the first 14 lines <fossy>i'm sure it will be licensed as such eventually <fossy>s/eventually/sooner rather than later/ <stikonas[m]>fossy: I guess no new info on yacc? Maybe I'll try to gdb it today then... <OriansJ>fossy: well by default in copyright law it is already licensed but as non-free. Which is why explicit copyright headers are supposed to be done on the first commit. So we don't have the when is it going to have a free license discussion. <fossy>stikonas[m]: sorry, no, didn't get to it, was doing more kernel shenanigans <stikonas[m]>OK, I started looking yesterday anyway, just without gdb yet... <mihi>OriansJ, thanks for the heads up, licensing information added. <mihi>As I posted the content to GitHub, per their termas of use it is automatically licensed under GitHub Content License, but I believe that license is neither FSF nor OSI approved (as it does not give any rights to distribute binaries). But I agreee that an explicit license ia always better. Usually GitHub nags you once you create a repository, but at this stage I did not want to create a repo yet in case somebody <mihi>here shouts that he has already tried that approach and can argue why it is impossible. <mihi>and I hope janneke_ will continue maintaining mes, even when it is no longer needed for guix's bootstrap (at least as long as we depend on it to get from M2-Planet to tcc). <siraben>multiple bootstrap paths would be a good idea <civodul>Mes no longer needed for Guix's bootstrap? <stikonas>civodul: I think OriansJ was thinking about how to bootstrap Guix bootstrap binaries, which I think is mkdir, xz, bash, guile and I guess you can't get rid of those <stikonas>initially idea was maybe replace guile with mes but if we can bootstrap guile, then we can just use it <stikonas>(those are from bootstrap.scm, not commencement.scm) <civodul>stikonas: i see, but i guess it'll always be much easier to build Mes from "very little" than it is to build Guile and all its dependencies <stikonas>civodul: well, we build guile via mes anyway <stikonas>but like I said I think this was more related to what is done in bootstrap.scm <stikonas>there is sometimes more than one way to proceed <civodul>re mkdir/xz/bash/tar, we could do away with them via some trickery <civodul>namely, we could extract the tarball "out-of-band" <stikonas>yeah, that's what we do in live bootstrap <stikonas>and compile tar as one of the first things <stikonas>mkdir is compiled a bit later... we are working on bash... <stikonas>and we haven't tried xz, it's probably more complicated but we don't need it that early <stikonas>by the way, how were those binaries initially generated? Are they build manually or according to guix recipe? <civodul>they're from the "coreutils&co" tarball <civodul>in effect, they were manually extracted from that <stikonas>pder: have you done debugging of code compiled with tcc? When you were debugging ls <stikonas>somehow I can't print values of variables <stikonas>ok, so problem with heirloom-yacc (mes libc) is that tokname's are truncated to 1 character <stikonas>argh, that might indeed be because of wchar's... <stikonas>I guess that means gettok function is broken... <stikonas>fossy: ok, so I think I know whats going wrong with yacc <stikonas>I was now able to compile parser.y into C file (atlhough, C file failed to compile, but that might be because my yacc "workaround" was not applied everywhere) <stikonas>so at the moment in chfind I've replaced wcscmp functions with the ones from musl <stikonas>and that alone allows compiling .y file into .c <OriansJ>Hagfish: well it is pushing the limits of what is defined as a scheme because instead of lambda it has fun; it has no support for macros or #\chars or even garbage collection. It is more like C with parens than scheme. <stikonas>fossy: ok, I was able to get a working lex too (manually for now) <stikonas>(had to manually rename wchar_t into char in fakewchar's wchar.h <stikonas>and it was enough to build scan.lex.l that is in old flex <stikonas>well, had to use mix of gdb debugging and printf statements... <stikonas>somehow I couldn't get tcc binaries to play nicely with gdb <stikonas>so I've got nice frames, with line numbers <stikonas>but p variable worked only for very few variables <stikonas>I didn't check why exactly strlen trips yacc... <stikonas>so once I automate this, we should be able to easily go all the way to bash <stikonas>flex and bison have nice makefiles written by gio <gio>stikonas: nice is a bit of a stretch... <stikonas>this wouldn't work for us echo 'extern int yylval;' >> parse.h <stikonas>but I think those problems should be easier... <fossy>stikonas: just change them both to patches <stikonas>anyway, first I should finish heirloom yacc/lex ... <stikonas>fossy: would you mind if I didn't install yacc/lex into /after/bin? <stikonas>we are getting flex and bison immediately afterwards <fossy>stikonas: hm, dont really mind, but it would be breaking convention <fossy>Is there a particular reason to not <stikonas>fossy: well, a couple of small reasons (although, I don't feel too strong about both). 1) it's very temporary, 2) binaries are not redistributable anyway (due to libc license) <stikonas>so I wanted to make some kind of distinction... <stikonas>or maybe I should install them and later delete once we have flex... <fossy>we have other quite temporary tools so I feel better sticking to convention <fossy>the redistributible thing dosent care to installing <pder>There sure is some weirdness with seq compiled by tcc+meslibc. Just doing a printf on a global static double gives me a different result when done from main vs print_numbers <pder>Trying to find the simplest test case that demonstrates the broken behavior <stikonas>pder: yeah, it was very strange, but since you were looking at it I didn't investigate more <stikonas>now I'm trying to build in clean environment, so yacc have built lex'es parser.c but in clean environment now it fails to compile... <stikonas>I might have used wrong y.tab.c file when building lex before (from yacc(glibc)) <stikonas>yep, I probably need to replace all wcscmp (and maybe others) <stikonas>ok, but diff between good generated .c file and bad .c file is not big <stikonas>pder: could it be that doubles are broken on our tcc? <stikonas>possibly went unnoticed before because doubles are not used much for bootstrapping