Re: Running Compiled Guile Objects

[Nala Ginrut]

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.

You may test in this way:
- 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.

Now you will see, a scm.go can be loaded without auto-compilation, but it
will cause b.scm.go be auto-compiled to default .go cache directory, and
ignoring the pre-compiled obj/mod/b.scm.go

So the problem is, if you want to bypass the caching, you have to provide
your manual caching comprehensively.

The relative easier way would be modify the loading path on the fly with
Guile related API.

Best regards.

On Sat, Dec 14, 2024, 23:53 Maxime Devos <maximedevos@telenet.be> wrote:

>
>    - It's unnecessary to manually load .go files. You can pre-compile
>    .scm to .go and install to the compiled-load-path. And put .scm to
>    load-path, if your path is correct, and if the .scm is no newer than .go,
>    Guile will automatically load .go directly without auto-compilation.
>
> Neither is it necessary (at least, should be necessary) to manually load
> the .scm file instead. In some cases its pointless indirection. With
> directly loading the .go, sometimes fewer paths need to be adjusted.
>
> Also, you don’t only need to install to compiled-load-path, you may also
> need to adjust compiled-load-path (e.g. if you don’t have the permissions
> to add things to the directories of the default path, or if adding to those
> directories is the wrong thing to do (both of these are the case in Guix,
> for example)).
>
> (All case-dependent)
>
>
>
> Best regards,
> Maxime Devos
>