dear list, are the following assertions correct? any insights on them?
the eval.c, eval2.c, and eval3.c are a linear progression, similar to how VCS versions of the same file follow each other as they evolve? (in the current repo eval.c was not changed a single time after eval2.c has been introduced.) this also applies to some other files like boot.l and boot2.l, that are tightly coupled with eval. the reason they are retained with explicit names in the repo is to be able to easily compare the old versions for speed, compatibility and some similar comparative operations? it wouldn't be needed if there were some makefile targets, or some other easy way, that checked out specific old revisions from the repo and built them, so that experiments could be made with both the executables yielded by building the current repo state and yielded by building older states? --- if these are all true above, then i'll look into implementing that last one. basically there could be git branches like 'bootstrap-1', 'bootstrap-2', etc... the idea is that the compiler code in the 'bootstrap-n' branch requires the eval.exe yielded by building the code in 'bootstrap-(n-1)'. if you want to bootstrap from the first hand written eval.c, which is potentially missing countless recent features, then you need a script that goes through all the bootstrap stages and builds the eval.exe's in succession. if bugs or platform issues show up in the process, then you can just push fixes to the appropriate branches and restart. if a new compiler is introduced later that can e.g. emit portable C code, then the emitted code could be checked into the appropriate bootstrap branch and then the C->bleeding-edge bootstrap process could be shortened. e.g. in the current state of maru, the bootstrap-from-C process could start from the 'bootstrap-2' branch that would hold eval2.c and boot2.l (because the current eval2.c is still written by hand and doesn't depend on eval1). this change would imply that the build process becomes somewhat dependent on the repo format. due to the excellent teamwork goodies provided by github, and the social trends, git seems like a good choice. but given that Ian uses hg, and that it also has branches, that's a big weight that i'm willing to give in to easily. (if i was alone on the planet then i'd go with darcs and tags, but i am not, and one of the main points of my current effort is to bring life into maru hacking) there's also http://hg-git.github.io/ which means that the hg client can push into git repos, which may mean the best of both worlds: i record whatever i do in hg, push to github for collaboration, and publish my repo for Ian to be able to pull from it. but how well that works needs to be investigated, unless someone has experience with it. any thoughts? Ian? -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “We will have taken one giant step forward when we face this reality: Powerful people never teach powerless people how to take their power away from them.” — John Henrik Clarke (1915–1998) _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
