Re: Running Compiled Guile Objects

[Nala Ginrut]

> Also, post-hoc: your example is wrong, in the sense that you gave the
compiled module the wrong name! You should name it ./obj/mod/X.go, not
./obj/mod/X.scm.go. If it then still not loads the .go, that’s a bug and a
regression.

I'm pretty sure to test both .go and .scm.go under 3.0.10.
If I understand you correctly, you mean b.scm will try to find b.go, or at
least auto compile to b.go, right? Both .go and .scm.go can not deny what I
just described.
And the default naming is .scm.go as what I can see in the terminal.

> Yet, simultaneously you say there is no way (without caches), _and_ you
actually are using that way (“-C obj”).

My opinion is the cached .go is not auto recognised by the cache for deps,
but .scm can be recognised by default. I'm not saying "no way" without a
cache, I mean "no way" even if there is a manual cached object.

On Sun, Dec 15, 2024, 01:50 Maxime Devos <maximedevos@telenet.be> 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 exists.
>
> >I wonder if you have tested the given example. Guile doesn't load .go as
> the dependency, but .scm.
>
> I didn’t test it, because:
>
>    - I know how you described it in the example, is how it works (except
>    for the ‘no way to load deps from .go without cache’ falsehood, and except
>    for the misnaming of the .go which I didn’t notice at first).
>    - As I mentioned in the beginning, I don’t have a Guile setup
>    currently.
>
> Also, post-hoc: your example is wrong, in the sense that you gave the
> compiled module the wrong name! You should name it ./obj/mod/X.go, not
> ./obj/mod/X.scm.go. If it then still not loads the .go, that’s a bug and a
> regression.
>
> >> 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".
>
> No. I don’t care at all about lowercase ‘-c’ here. I mentioned ‘-C’
> precisely _*because*_ it augments the load compiled path. At first I
> didn’t notice the ‘-C’ because of the rest of the message implied you
> didn’t set it.
>
> >- 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.
>
> Namely, this. “-C insert-directory-here” is _*the*_ way to load
> dependencies from .go (at least, dependencies in form of module imports,
> I’m not too sure about how loading the initial file (as .scm) works) and it
> doesn’t need to be a cache. Yet, simultaneously you say there is no way
> (without caches), _*and*_ you actually are using that way (“-C obj”).
>
> Best regards,
> Maxime Devos
>