Re: Running Compiled Guile Objects

[Nala Ginrut <nalaginrut@gmail.com>]

> 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)

No, my suggestion to modiy load path on the fly is not the way to help load
first .go, but a regular way to take advantage of the cache.
This suggestion implies one give up the manual loading. So of course it's
not the way as you thought.

On Sun, Dec 15, 2024, 01:26 Nala Ginrut <nalaginrut@gmail.com> wrote:

> > 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
>>>
>>>
>>>
>>