> 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.
I wonder if you have tested the given example. Guile doesn't load .go as the dependency, but .scm. I think I have to confirm that you don't want to trigger auto-compilation, since your situation is the default cache dir lacking of permission, right? If so, my example showed the simple bypass may not a proper way to go. Best regards. On Sun, Dec 15, 2024, 01:20 Nala Ginrut <nalagin...@gmail.com> wrote: > > You missed ‘-C’ (load-compiled-path) > > I didn't miss load-compiled-path here, I think you confused with -c. > -C obj specified the current load compiled path to "./obj". > > On Sun, Dec 15, 2024, 01:10 Maxime Devos <maximede...@telenet.be> wrote: > >> >> - 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 >> >> >> >
