Gambit's current Git head cannot be directly bootstrapped using the latest release 4.9.3 due to major internal changes.
Could someone give a rough estimate for how many steps are needed from 4.9.3 to head, and which pre-release versions from Git to use as the stepping stones in between (e.g. from which month last year)? Is it possible to make do with one "stepping stone" commit (i.e. use Gambit 4.9.3 to bootstrap that commit, then use the Gambit built from that commit to bootstrap HEAD) or are two or more needed?
I'm trying to build a Docker container tracking Gambit's HEAD at https://hub.docker.com/u/schemers, hence the question. But if we figure this out, it could also help use `git bisect` to find the commit where the MacOS poll() problem was mysteriously solved.
Afficher les réponses par date
I’m not sure I understand the problem you are having. I just tried to build from a fresh clone (on linux) and everything built with no issues and the “make check” passed.
Things are more complex if you want to build the system at many different commits without going through the whole bootstrap process every time. There isn’t a failsafe build method other than the bootstrap process. However, one approach that works most of the time is to build commit C with a gsc-boot that is the gsc/gsc of commit C-1. You could add an “if that fails then go through the complete bootstrap process”. This approach can be extended to do a kind of “bisect”:
- Say that there are N commits since the latest release and that these are numbered from 0 to N (e.g. commit 0 is release 4.9.3 and commit N is HEAD).
- Build the system at commit 0 (this can be done without the full bootstrap because it is a “release” where the .c files match the .scm files).
- To build commit C determine what is the most recent commit before C that has been built (call it B) and in C do “cp B/gsc/gsc gsc-boot;./configure;make clean;make”.
- If that fails and B < C-1, then recursively build commit floor((B+C)/2) and then continue at the previous step.
- Otherwise, use the full bootstrap process, i.e. “rm -rf boot gsc-boot;./configure;make clean;make"
Marc
On Mar 29, 2020, at 1:52 PM, Lassi Kortela lassi@lassi.io wrote:
Gambit's current Git head cannot be directly bootstrapped using the latest release 4.9.3 due to major internal changes.
Could someone give a rough estimate for how many steps are needed from 4.9.3 to head, and which pre-release versions from Git to use as the stepping stones in between (e.g. from which month last year)? Is it possible to make do with one "stepping stone" commit (i.e. use Gambit 4.9.3 to bootstrap that commit, then use the Gambit built from that commit to bootstrap HEAD) or are two or more needed?
I'm trying to build a Docker container tracking Gambit's HEAD at https://hub.docker.com/u/schemers, hence the question. But if we figure this out, it could also help use `git bisect` to find the commit where the MacOS poll() problem was mysteriously solved.
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://mailman.iro.umontreal.ca/cgi-bin/mailman/listinfo/gambit-list
I’m not sure I understand the problem you are having. I just tried to build from a fresh clone (on linux) and everything built with no issues and the “make check” passed.
No matter what kind of gsc-boot I tried, it didn't work.
But finally managed to solve the problem: I had used a shallow clone (`git clone --depth 1`) which caused a mysterious build failure. An ordinary `git clone` with the full history works fine, even with no 4.9.3 gsc on the system.
Anyway, there is now finally a ready-to-run Docker container of Gambit's latest commit!
docker run -it schemers/gambit:head
Should probably add Git to that container so that remote modules work (`gsi github.com/gambit/hello`).
Nice!
I tried it out to check performance, and I’m quite surprized that the docker Gambit is over 3 times slower than the “native” Gambit:
% gsi -e "(define (f x) (if (< x 2) x (+ (f (- x 1)) (f (- x 2)))))(pp (time (f 30)))" (time (f 30)) 0.248934 secs real time 0.248852 secs cpu time (0.247554 user, 0.001298 system) 25 collections accounting for 0.001492 secs real time (0.001458 user, 0.000035 system) 172322368 bytes allocated 1580 minor faults no major faults 832040 % docker run -it schemers/gambit:head gsi -e "(define (f x) (if (< x 2) x (+ (f (- x 1)) (f (- x 2)))))(pp (time (f 30)))" (time (f 30)) 0.823593 secs real time 0.830000 secs cpu time (0.830000 user, 0.000000 system) 26 collections accounting for 0.003341 secs real time (0.010000 user, 0.000000 system) 172322368 bytes allocated 1589 minor faults no major faults 832040 % docker run -it schemers/gambit:head gsi -v v4.9.3 20200101213000 x86_64-pc-linux-gnu "./configure '--prefix=/usr/local' '--enable-single-host' '--enable-multiple-threaded-vms'"
3x is a “big deal”! Do you have an explanation for this? Is this typical of docker apps?
Marc
On Apr 6, 2020, at 9:53 AM, Lassi Kortela lassi@lassi.io wrote:
I’m not sure I understand the problem you are having. I just tried to build from a fresh clone (on linux) and everything built with no issues and the “make check” passed.
No matter what kind of gsc-boot I tried, it didn't work.
But finally managed to solve the problem: I had used a shallow clone (`git clone --depth 1`) which caused a mysterious build failure. An ordinary `git clone` with the full history works fine, even with no 4.9.3 gsc on the system.
Anyway, there is now finally a ready-to-run Docker container of Gambit's latest commit!
docker run -it schemers/gambit:head
Should probably add Git to that container so that remote modules work (`gsi github.com/gambit/hello`).
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://mailman.iro.umontreal.ca/cgi-bin/mailman/listinfo/gambit-list
I tried it out to check performance, and I’m quite surprized that the docker Gambit is over 3 times slower than the “native” Gambit:
3x is a “big deal”! Do you have an explanation for this? Is this typical of docker apps?
Interesting. No obvious explanation.
Docker processes should share the same Linux kernel as host processes, they just have a different view of the process tree and file system than host processes. On that account, speed ought to be roughly on par with host processes.
The container is built with: ./configure --enable-single-host --enable-multiple-threaded-vms
Are you running Docker on Linux or Mac? I think Mac docker internally runs a virtualized Linux instance in the background and runs containers on that. It's easy to imagine that would be somewhat slower than native MacOS programs.
It seems the current HEAD still can't be bootstrapped using 4.9.3 release. The Docker container (docker run -it schemers/gambit:head) is now built with the following commands to first try release gsc, and if that fails, bootstrap from scratch:
ln -s /usr/local/bin/gsc gsc-boot make || (rm -rf boot/ gsc-boot && make)
That approach would seem to work fine, and saves a lot of time in case the build works with the release compiler (Docker Hub builds are really slow - you get what you pay for...)
-
Lassi Kortela -
Marc Feeley