<reepca>hm, strange, I'm getting "no code for module (ice-9 readline)" when I try loading it as per the manual <daviid>reepca: you need to install guile-readline first <reepca>huh, so I do. Wonder when that package was added. Thanks! <rain1>why is readline separate from the rest of guile? <daviid>rain1: I don't remember exactly, but think it because of a license problem, not sure .. but if you dig in our ML back between 1 and 2 decades, you find out :) <daviid>reepca: np! note that most of us use emacs and geiser <rain1>maybe we could get it merged in, it's GNU GPL <daviid>rain1: though I don't remember, I think there is a reason, would have to ask our mantainers <reepca>daviid: speaking of geiser - know any easy way to change the command it runs to start guile? I'm wanting to run ./test-env guile to interactively mess around with some stuff <daviid>reepca: i guess it is possible, but can't answer for sure, look into the manual, it's short and well written ... <daviid>reepca: you can join #geiser as well, and ask for help there, very friendly too ***fibratio` is now known as fibration
<janneke>still wondering if working on Mes is more helpful than trying to create a minimalistic, bootstrappable version of Guile <janneke>also, should i be developing MesCC running on Mes and Guile alike and trying to compile tinycc, or better bootstrap Guile's compiler first and write a GuileCC... <amz3>what would guilecc do? sorry for the noob question <janneke>MesCC is what I call the C compiler written in Scheme and intended to be run on Mes (my simple sort of Guile-compatible scheme interpreter) <janneke>MesCC uses mwette's Nyacc C parser and compiles C into x86 assembly in the form of M1 <janneke>of course Guile can already also run this MesCC C compiler, but as a proper Guile project it could use all kinds of constructs that Mes does not support, or that are very hard to bootstrap (syntax-case) <janneke>so, GuileCC would be a C compiler written in Guile <ArneBab>janneke: isn’t compiling tinycc the step towards compiling gcc 4.7 which is the step towards compiling gcc 4.7+ which is the step towards compiling guile? <rain1>wht you outlined there is the plan, I think <rain1>but there is a gap in it kind of - we also need to build binutils and glibc <OrangeShark>janneke: what would be required for a minimalistic, bootstrappable version of Guile? <amz3>I think guile will not use gcc in the future <janneke>ArneBab: yes, that's right -- mes+mescc->tcc->gcc-4.7 is a very promising path <ArneBab>rain1: can’t we do that with gcc-4.7? <janneke>OrangeShark: if i can put it a bit (too) black and white: make it so that libguile/eval.c can be built without the other 99% of libguile/*.c <rain1>ArneBab, I would like to see it done for real, the exact process and how it is performed, what ./configure flags <janneke>OrangeShark: using #if BOOTSTRAP and moving libguile/*.c parts to module/ice-9 or module/bootstrap/ even <OrangeShark>so just the interpreter from guile is needed to run GuileCC which can then you go from there? <janneke>OrangeShark: yes or to put it differently: everything beyond the interpreter/eval.c that we add to the bootstrap path, makes bootstrapping more heavyweight, more difficult <janneke>OrangeShark: libguile is ~100,000 LOC and depends on libgc (~40,000LOC) <janneke>libguile possibly depends on gnulib too, glibc ... enough to discourage me :-) <janneke>otoh, creating a new GNU Scheme is an equally silly effort :-/ <OrangeShark>yeah, hmm, sounds like a challenge. Also awesome work on mes :) <janneke>OrangeShark: yeah, choices...thanks! <rain1>it's ok to haave multiple schemes <rain1>it just needs to be easily to build each next one <janneke>rain1: yeah, why not build tarot first and have tarot+MesCC build tcc? <rain1>its an option, but last time we checked I thin tarot was same size as mes - let me see <janneke>mes+mescc build mes.c in ~3min (~3000LOC) <rain1>It is a scheme compiler written in 1907 lines of scheme. <rain1>It (when compiled) runs on top of a virtual machine implemented in 2033 lines of C. <janneke>building tcc (~25,000LOC) takes ~1h20 <rain1>but it doesnt really do anything yet <janneke>even if tarot is "only" 10x faster than mes, that would be an amazing speed-up <rain1>tarot can be bootstrapped off tinescheme but in future maybe off sch3 <janneke>what does tarot need that mes doesn't have yet? <rain1>i've never tried to build tarot using mescc, but I guess the main thing would be my use of computed goto for the fast interpter loop <rain1>it could be replaced with a switch/case <rain1>but also I never got around to trying to run nyacc or syntax- <rain1>I guess they are both possible but will take a lot of work <rain1>so tarot might not be the best option <janneke>if mes can run nyacc, tarot surly can <janneke>the most exotic things nyacc needs are fluids and call/cc <rain1>lbl is a variable, and we can do goto *lbl in GCC <rain1>it's a good trick to make a fast interpter loop <rain1>is call/cc used in nyacc for errors (which we could just replace with exit) or is it used for backtracking? <rain1>and i'll look into the fluids, i'll need to learn them <janneke>rain1: about call/cc: wow, that's a good question! -- let's ask mwette when they're around! <janneke>i just assumed it was essential, but dropping call/cc would allow an amazing simplification of mes <rain1>anotheng thing we can possibly do is simply make a copy of whole the tarot-compiler scheme repo and add features to it <janneke>i imagine that goto *var would be a very simple feature to add <janneke>can you supply me with a minimal example in C that exits 1 if goto fails and exit 0 if it passes? <rain1>heres an example using it just like an interpreter loop <rain1>it's supposed to be really good to the branch predictor, which makes it run faster <janneke>guess that should be fairly easy to implement <rain1>i haven't compared speeds against swich/case though <rain1>ok and I will try to run nyacc on tarot <rain1>at least I'll find out why it doesn't (I don't expect it to work)