RE: Running Compiled Guile Objects

[Maxime Devos via General Guile related discussions]

➢ IMHO, the manually .go loading will cause more issues.
➢ First, here's a fact: manually loading will not bypass the intrinsic .go 
caching. Only the first .go will, and the rest of the deps chain will still be 
managed by the intrinsic caching. [snip]
[snip: module (a) (a.scm / a.go) uses module (b) (b.scm / b.go))
I don’t see ‘more issues’ here. The (non-)issue you mention exists regardless 
of whether module a is loaded as ‘a.scm’ or as ‘b.go’. Also autocompilation 
causes its own issues, if it requires things in the environment during 
compilation that aren’t available at time or use (e.g. a C pre-processor in 
case a library using macros from a FFI library, where you don’t want the C 
pre-processor to have to stay installed when using the binding library), or 
when the compilation is messy, e.g. it uses files from the build directory that 
aren’t installed in the .scm and .go directories (and don’t make sense to be 
installed there).
And in the situation where all used modules are precompiled and already in the 
load paths (e.g. modules of Guile itself, or installed with package manager), 
then no caching happens at all.
➢ - if you have two module, a.scm and b.scm, a imported b's function to use. 
- the .scm are in ./mod directory.
- compile them and put into ./obj/mod directory.
- guile -C obj -L .
- (load-compiled "obj/mod/a.scm.go")
- the deps have to be loaded from the scm path specified by -L. IIRC there is 
no way to load deps from .go, unless you provide a manual caching.
You missed ‘-C’ (load-compiled-path). You can point this to a cache if you 
wish, but it doesn’t need to be a cache. Guile doesn’t care about whether it is 
a cache or not, as long as it has the .go, the timestamps are ok, and (IIRC) 
corresponding .scm exis.
➢ So the problem is, if you want to bypass the caching, you have to provide 
your manual caching comprehensively.
No. You can disable caching without providing manual caching. E.g., in case of 
%.go:%.scm Makefile rules (+ dependency information which in principle could be 
automatically generated by guild, but currently isn’t yet), make takes care of 
compilation. Because of its local nature (no shared cache) (^), lack of 
capacity limits (no time limits, no size limits) and its aesthetics (it’s just 
compilation) (*), this is not a cache system.
(*): for a comparison: you can compile C code to a shared and install it in 
/usr/lib without /usr/lib being a cache – being a cache is more about how it is 
populated and maintained than it is about what it happens to contain.
(^): not a strict requirement for a cache, but it’s an indication when the 
‘known cache’ (that thing in .cache/) is a different and more global thing.
Another option is to only precompile the a.scm (and not additional 
dependencies) and disable autocompilation (when there’s only a single file to 
take care of, comprehensive is trivial).
A third option is to use potentially outdated  .go (unfortunately Guile doesn’t 
fully separate caches from precompiled code, so beforehand you need to update 
the timestamps to make Guile accept them). This can then be separation of ‘code 
I'm currently writing, which might be in a not-ready state, but I already saved 
it to not loose it in case the computer needs to suddenly shut down’ and 
‘latest ‘good’ version of the code – might be incomplete, but is ready for 
testing’. (Other methods exist too, but this can be convenient.)
➢ The relative easier way would be modify the loading path on the fly with 
Guile related API.
You can indeed modify the loading paths from within Guile (I previously 
mentioned this myself). But this doesn’t help with loading the first .go  (so 
it’s not an easier way, it’s not a way) – if a.scm sets up the load paths 
(including compiled path), then by the time that Guile can know where a.go is 
located, it’s too late for that. So, either you need to:
(0) not precompile a.scm (it’s pointless)  (and for dependencies adjust load 
paths when needed, in invocation or in a.scm)
(1) install a.go somewhere in the standard load-compiled-path (not always 
possible) and just ask guile to load a.scm (-> guile loads a.go instead)
(2) add ‘-C insert-go-directory-here’ to the guile invocation (straightforward, 
but not the best option) and load a.scm (-> guile loads a.go instead)
(3) tell Guile to load a.go, and let a.go set load-compiled-path (& load-path) 
to find remaining dependencies
Of these four options, (0) and (3) have the most convenient invocation. Of 
those two options, (3) has the least re-compilation. By these criteria, (3) is 
the best.
Best regards,
Maxime Devos