<markjenkinsznc>which should make for an easy hex2 audit as you'll see the instruction comments from the hex2 side by side with the dissasemblers opinion <OriansJ`>although I will be making a small tweak with the make test target and breaking it into test and test-all <OriansJ`>To preserve the previous behavior of only needing to run make clean test to validate all of the core binaries are built identically <OriansJ`>I've finally gotten around to fixxing the kaem 32bit regression I caused when I remerged kaem into mescc-tools. (I'm sorry fossy for breaking it on you and then disappearing for a bit) <OriansJ`>markjenkinsznc: well it isn't uncommon to get stuck on tiny assumptions. it is why when we work together we always succeed so much more <markjenkinsznc>the broader assumption I was carrying and procrastinating on was that my code had got too messy and had a complicated bug that was going to take awhile to fix, but the issue turned out to be strait forward to understand when I gave it a go <xentrac>OriansJ`: collaboration also helps with motivation <OriansJ`>the last 4 months of dealing baby, really took me out of the zone of working on code in my free time and I have to get back into the habit of trying to code a little everyday <OriansJ`>That way I can get the M3 and mes-m2/slow-utils work back on track <OriansJ`>stikonas: it is 3 things actually, a proper ELF linker, a Gnu Assembler compatible assembler (so that mescc can output binutils standard assembly and get even faster binaries and easier porting) and TCC converted into something M2-Planet can build <OriansJ`>also a play on being the stage after M2-Planet <OriansJ`>janneke: Sorry if I am asking an insanely stupid question but assuming one git clones mes; cd mes and has guile installed and wished to compile hello_world.c into the standard M1 output with mescc. Would the command be: guile -e main -s modules/mescc.scm -c hello_world.c -o hello_world.S ?? because when I do that I get a hard failure. <janneke>OriansJ`: not such a stupid question -- in fact i see that some ARM work has broken guile-compatibility <janneke>OriansJ`: this seems to work: SCHEME=guile ./pre-inst-env mescc -c -o hello.S scaffold/hello.c <OriansJ`>also why would a configure script need to be run to enable a scheme interpreter to run a program written in scheme? <OriansJ`>if it makes it easier, we can bash on mes-m2 together to make this workflow easier to implement <janneke>the configure script could tell you that guile can't find nyacc (that check was disabled, though) <OriansJ`>aka git clone mes-m2; cd mes-m2; guile -e main -s scripts/mescc.scm -c hello.c -o hello.S <OriansJ`>as I can just put a pinned version of nyacc in mes-m2 to remove these sorts of complexities <OriansJ`>possibly guile -L module/ -e main -s scripts/mescc.scm -c ../mes/scaffold/hello.c -o hello.S <janneke>the idea is that `pre-inst-env', created by configure, sets up these directories and paths when running from the working tree <janneke>ah, we used to have ./configure --with-cheating to set-up for guile, but that's bitrotted apparently <OriansJ`>we need a core of mescc that works out of the box <OriansJ`>we can cheat with guile to ensure it works while I make mes-m2 compatible <OriansJ`>but using just git clone and a single guile command to get it to simply build a single C file to M1 output is all I need right now <OriansJ`>that way when mes-m2 is done; we simply swap the guile command with a mes-m2 compatible. <OriansJ`>I know being out of it for 4 months might mean I am missing obvious stuff but honestly people who show up are going to know even less. <OriansJ`>so let us get mescc in mes-m2 into a state where git clone and having fuile is the only thing they need to know to bootstrap some C with MesCC ***xwvvvvwx- is now known as xwvvvvwx
<OriansJ`>janneke? yes/no/working on it/nope bad idea/$INPUT <janneke>i'm pretty stressed-out atm; need to get some real work (tm) done <janneke>sure, having it "just work" will save a lot of time and frustration <janneke>i do not like bundling, that's what all the evil guys do, right ;) <OriansJ`>janneke: bundling is sometimes what is required when you can't depend upon anything else. <janneke>i won't have time to work on mes the coming weeks <OriansJ`>and I am sorry if I cause(d) any additional stress <janneke>OriansJ`: np, i feel bad for mostly ignoring the question :-) <janneke>i've been anticipating to return to mes development for about 2months now, <janneke>but i guess that will have to wait a bit <OriansJ`>heck I am just comming back after nothing for 4 months <OriansJ`>always take time for yourself and your life first <janneke>i think using guile for debugging/development, like you suggest, is a great idea <OriansJ`>remember it is an 80 year old problem and we are miles ahead of everyone else. No need to rush <janneke>you'll want to use 'make' to compile .go files and catch errors early <janneke>OriansJ`: a pitfall of course, is that the mes+mescc build may bitrot once in a while <janneke>at least, that happened to me a few times <janneke>that's mostly why i moved back to using mes for development (and the guile option bitrotted) <OriansJ`>janneke: well that is the nice thing about mes-m2; I am not advancing the state of MesCC but rather building a foundation under a stable and stale scheme program that "works" <OriansJ`>a yearly update schedule is fine in that paradigm. <OriansJ`>heck getting MesCC v0.1 or v0.20 working raw in mes-m2 is lightyears ahead of "here is a bag of scheme and it needs other things to work, good luck" <OriansJ`>that is why I switched to the submodules method, it makes it easier for new users to get started using it immediately. <OriansJ`>So deal with your current problems and when you get back we can collaborate on getting Mescc, gash and slow-utils working together in mes-m2; thus providing a single package of scheme which will in the short term need guile but after will be everything needed to bootstrap guix in a single tar <stikonas>that's nice. At the moment guile-bootstrap is the biggest remaining binary in bootstrap tarballs <OriansJ`>and while you are away, I'll hammer on the M3 pieces (linker, assembler and then compiler) so that you'll have more fun with MesCC porting in the future as you'll be able to be leverage binutils as compatibles <OriansJ`>stikonas: well getting guix to run on anything other than guile is going to require alot of work in mes-m2 <janneke>OriansJ`: sounds great...phew, build problem bisected, stress is gone <janneke>not knowing what and where and how long to bisect against a deadline is no fun <OriansJ`>janneke: well that is a risk that comes with your aggressive code style janneke <OriansJ`>which has many other benefits to productivity <OriansJ`>me, I just am not smart enough to work that way. So I tend to be stopped on the sorts of things you just seem to blow through janneke <OriansJ`>but I guess my style is better if you need to write a C compiler in Assembly and yours is if you wish to bootstrap GCC with scheme ***xwvvvvwx- is now known as xwvvvvwx
<fossy>OriansJ`: the minimum version required for mes-m2 to run mescc which can compile tinycc iirc is v0.11