Re: Running Compiled Guile Objects

Nala Ginrut <[email protected]>
Newsgroups gmane.lisp.guile.user
Message-ID <CAPjoZoe-r8C4yb7AYY+p=oBhxm33m8Qw=5o=1_=BJMWsV9jSnQ@mail.gmail.com>
> 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 <[email protected]> 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
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.