Re: Running Compiled Guile Objects

[Nala Ginrut <nalaginrut@gmail.com>]

> 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 <nalaginrut@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 <maximedevos@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
>>
>>
>>
>