Attila Lendvai
2014-01-20 11:03:12 UTC
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?
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)
• 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)