Geiser w/ mit-scheme requires compiled file, but does so at runtime #1

jaor commented 2016年07月25日 16:49:32 +02:00 (Migrated from gitlab.com)

Created by: cwebber

I installed geiser with Guix (currently under the "geiser-next" package, which uses a version from git master which should have mit-scheme support) and discovered the following error:

MIT/GNU Scheme running under GNU/Linux
Type `^C' (control-C) followed by `H' to obtain information about interrupts.
Copyright (C) 2014 Massachusetts Institute of Technology
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Image saved on Saturday May 17, 2014 at 2:39:25 AM
 Release 9.2 || Microcode 15.3 || Runtime 15.7 || SF 4.41 || LIAR/x86-64 4.118
 Edwin 3.116
;Loading "/gnu/store/2g1rn0y1q7vgv9mkid337cqmlppb6vjv-geiser-next-0.8.1-28c85839/share/geiser/mit/geiser/load.scm"...
; Loading "compile.scm"...
; Loading "make.com"...
; Loading "cref-unx.pkd"... done
; Loading "mset.com"... done
; Loading "object.com"... done
; Loading "toplev.com"... done
; Loading "anfile.com"... done
; Loading "conpkg.com"... done
; Loading "forpkg.com"... done
; Loading "redpkg.com"... done
; ... done
; Generating SCode for file: "emacs.scm" => "emacs.bin"...
;The object "/gnu/store/2g1rn0y1q7vgv9mkid337cqmlppb6vjv-geiser-next-0.8.1-28c85839/share/geiser/mit/geiser/emacs.bin", passed as the second argument to primitive-fasdump, is not in the correct range.
;To continue, call RESTART with an option number:
; (RESTART 2) => Skip processing file /gnu/store/2g1rn0y1q7vgv9mkid337cqmlppb6vjv-geiser-next-0.8.1-28c85839/share/geiser/mit/geiser/emacs.scm
; (RESTART 1) => Return to read-eval-print level 1.
2 error> 

It looks like this is trying to compile emacs.scm to emacs.bin at runtime. Of course, if you're running an immutable package like in Guix (or really probably any package manager that installs things in a read-only location, which includes Debian/Fedora/etc), you can't go writing this file after the package has been built.

Maybe at build time, this file could be compiled? Or a script could be provided to optionally compile it?

*Created by: cwebber* I installed geiser with Guix (currently under the "geiser-next" package, which uses a version from git master which _should_ have mit-scheme support) and discovered the following error: ``` MIT/GNU Scheme running under GNU/Linux Type `^C' (control-C) followed by `H' to obtain information about interrupts. Copyright (C) 2014 Massachusetts Institute of Technology This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Image saved on Saturday May 17, 2014 at 2:39:25 AM Release 9.2 || Microcode 15.3 || Runtime 15.7 || SF 4.41 || LIAR/x86-64 4.118 Edwin 3.116 ;Loading "/gnu/store/2g1rn0y1q7vgv9mkid337cqmlppb6vjv-geiser-next-0.8.1-28c85839/share/geiser/mit/geiser/load.scm"... ; Loading "compile.scm"... ; Loading "make.com"... ; Loading "cref-unx.pkd"... done ; Loading "mset.com"... done ; Loading "object.com"... done ; Loading "toplev.com"... done ; Loading "anfile.com"... done ; Loading "conpkg.com"... done ; Loading "forpkg.com"... done ; Loading "redpkg.com"... done ; ... done ; Generating SCode for file: "emacs.scm" => "emacs.bin"... ;The object "/gnu/store/2g1rn0y1q7vgv9mkid337cqmlppb6vjv-geiser-next-0.8.1-28c85839/share/geiser/mit/geiser/emacs.bin", passed as the second argument to primitive-fasdump, is not in the correct range. ;To continue, call RESTART with an option number: ; (RESTART 2) => Skip processing file /gnu/store/2g1rn0y1q7vgv9mkid337cqmlppb6vjv-geiser-next-0.8.1-28c85839/share/geiser/mit/geiser/emacs.scm ; (RESTART 1) => Return to read-eval-print level 1. 2 error> ``` It looks like this is trying to compile emacs.scm to emacs.bin at runtime. Of course, if you're running an immutable package like in Guix (or really probably any package manager that installs things in a read-only location, which includes Debian/Fedora/etc), you can't go writing this file after the package has been built. Maybe at build time, this file could be compiled? Or a script could be provided to optionally compile it?

alezost commented 2016年07月25日 19:08:55 +02:00 (Migrated from gitlab.com)

I know nothing about MIT Scheme, but maybe it's more a problem of
this implementation? For example, Guile always compiles things
successfully as it puts compiled files to
/home/user/.cache/guile/ccache/...

Although maybe there is an option for MIT Scheme analogous to Guile's
--no-auto-compile, and Geiser can use it as the default for
geiser-mit-binary to prevent this compilation.

I know nothing about MIT Scheme, but maybe it's more a problem of this implementation? For example, Guile always compiles things successfully as it puts compiled files to `/home/user/.cache/guile/ccache/...` Although maybe there is an option for MIT Scheme analogous to Guile's `--no-auto-compile`, and Geiser can use it as the default for `geiser-mit-binary` to prevent this compilation.

jaor commented 2016年07月25日 20:27:49 +02:00 (Migrated from gitlab.com)

Created by: ecraven

Unfortunately it isn't that simple. I'd prefer not to clutter the user's home directory with compiled files, so these files should really be compiled when installing the package. However, I'm not sure guix supports compiling these files only iff mit-scheme is installed (that would introduce non-reproducibility into the package).
Also, at the moment the geiser support is in its own environment (~ module), which only works if it is compiled (unless someone with better mit-fu than me solves this).
I need a day or two to think about this, I'll comment as soon as I can think of a proper solution :)

*Created by: ecraven* Unfortunately it isn't that simple. I'd prefer not to clutter the user's home directory with compiled files, so these files should really be compiled when installing the package. However, I'm not sure guix supports compiling these files only iff mit-scheme is installed (that would introduce non-reproducibility into the package). Also, at the moment the geiser support is in its own environment (~ module), which only works if it is compiled (unless someone with better mit-fu than me solves this). I need a day or two to think about this, I'll comment as soon as I can think of a proper solution :)

jaor commented 2016年07月25日 20:40:05 +02:00 (Migrated from gitlab.com)

Created by: davexunit

However, I'm not sure guix supports compiling these files only iff mit-scheme is installed (that would introduce non-reproducibility into the package).

That's not true. One can build geiser with or without MIT Scheme in the build environment, and each variant could have a deterministic build. If you mean that the file could be compiled at runtime and stored somewhere outside of the immutable store if MIT Scheme is on $PATH, then that's also perfectly fine. Determinism applies to the build environment, not the runtime.

*Created by: davexunit* > However, I'm not sure guix supports compiling these files only iff mit-scheme is installed (that would introduce non-reproducibility into the package). That's not true. One can build geiser with or without MIT Scheme in the build environment, and each variant could have a deterministic build. If you mean that the file could be compiled at runtime and stored somewhere outside of the immutable store if MIT Scheme is on $PATH, then that's also perfectly fine. Determinism applies to the build environment, not the runtime.

jaor commented 2016年07月25日 20:45:24 +02:00 (Migrated from gitlab.com)

Created by: cwebber

Yes, a variant would be possible. I could add that... though it seems a bit annoying to me if we have different versions of geiser eventually for every scheme option. I guess that's not that big of a risk. I'd be happy to add code for it if that's the route we'd like to take, it wouldn't be that hard. I'd just like to have fewer variants if we can.

But here's my "path of least resistance" suggestion. It won't result in the fastest code option, but it should work and should result in very little work.

• When loading geiser with mit-scheme, check for the existance of the .bin file, and if it's not there, either
  • check if the directory is writable before trying to compile it
  • try compiling it, and just see if it worked.
• Now you'll either have or won't have a .bin file. @ecraven pointed out that we can have mit-scheme support without it being compiled by just using (load) instead, it'll just be slower.

How's that? It means that we wouldn't have to make a package variant, at the cost of speed. (However, it means we're likely to never bother to do the optional thing either!)

*Created by: cwebber* Yes, a variant would be possible. I could add that... though it seems a bit annoying to me if we have different versions of geiser eventually for every scheme option. I guess that's not that big of a risk. I'd be happy to add code for it if that's the route we'd like to take, it wouldn't be _that_ hard. I'd just like to have fewer variants if we can. But here's my "path of least resistance" suggestion. It won't result in the _fastest_ code option, but it should work and should result in very little work. - When loading geiser with mit-scheme, _check for the existance_ of the .bin file, and if it's not there, either - check if the directory is writable before trying to compile it - _try_ compiling it, and just see if it worked. - Now you'll either have or won't have a .bin file. @ecraven pointed out that we _can_ have mit-scheme support without it being compiled by just using (load) instead, it'll just be slower. How's that? It means that we wouldn't have to make a package variant, at the cost of speed. (However, it means we're likely to never bother to do the optional thing either!)

jaor commented 2016年12月26日 21:38:23 +01:00 (Migrated from gitlab.com)

Created by: cwebber

Hello! I wonder if there are any opinions on this bug still? What can we do to move forward?

*Created by: cwebber* Hello! I wonder if there are any opinions on this bug still? What can we do to move forward?

jaor commented 2020年07月20日 20:42:32 +02:00 (Migrated from gitlab.com)

changed the description

changed the description

jaor commented 2020年07月20日 20:42:32 +02:00 (Migrated from gitlab.com)

moved from jaor/geiser#167

moved from jaor/geiser#167

fedeinthemix commented 2024年09月08日 09:29:00 +02:00 (Migrated from gitlab.com)

What about making the destination path of the compiled file customizable? The MIT scheme 'cf' command supports an optional destination argument.
See https://www.gnu.org/software/mit-scheme/documentation/stable/mit-scheme-user.html#Compiling-Programs.

The destination could be in the user home directory, or, given that compilation is pretty fast, even in a temporary system directory.

What about making the destination path of the compiled file customizable? The MIT scheme 'cf' command supports an optional destination argument. See https://www.gnu.org/software/mit-scheme/documentation/stable/mit-scheme-user.html#Compiling-Programs. The destination could be in the user home directory, or, given that compilation is pretty fast, even in a temporary system directory.