Re: Running Compiled Guile Objects

[Nala Ginrut <nalaginrut@gmail.com>]

I know this mechanism before and I completely agree with what you said. But
I'm not sure if it's still the same before verify.

Maybe there's order issue in my test sequence. Or I will compile Guile
again.

BTW, gmail app added it, out of my control.

Best regards.

On Sun, Dec 15, 2024, 02:48 Maxime Devos <maximedevos@telenet.be> wrote:

> >> 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.
>
> Yes, you need to adjust the default naming. IIUC, the default naming is
> set up for Guile’s auto-compile cache, instead of for Guile’s
> load-compiled-path (these aren’t the same). (Confusingly .go are installed
> in subdirectories of a directory named ‘ccache’ (at least on Debian), but
> IIRC if you look at the .scm->.go mapping go, you’d see that the code for
> the auto-compilation cache is separated from the pre-compiled .go (and
> .cache/guile/2.0/ccache has a different layout), and since it is only
> updated at installation / package upgrades by copying over (pre-)compiled
> files, by definition it isn’t a cache.)
>
> No, I don’t mean that ‘b.scm will try to find b.go’. There is not reason
> for it to try that, and is somewhat against the point of compilation.
> Rather, b.scm is not loaded at all (except for some metadata: the time
> stamp). I also don’t mean ‘auto compile to b.go’. That’s against the point
> of the whole pre-compilation thing.
>
> Instead, when the module (mod a) is loaded (whether from mod/a.scm or
> obj/mod/a.go)), Guile module system is asked to load the module (mod b),
> and it sees mod/b.go exists in load-compiled-path and mod/a.scm exists in
> in load-path (and timestamps are ok), so it loads (obj/)mod/b.go.
>
> Since this mechanism is used for Guile’s own libraries as well ((system
> …), (srfi …), (ice-9 …), …), I would expect this to still work in 3.0.10.
> If you have proof of the contrary you should make a bug report about it.
>
>
>
> >On Sun, Dec 15, 2024, 01:50 Maxime Devos <maximedevos@telenet.be> wrote:
>
> > […]
>
>
>
> I don’t need a copy of my own e-mails.
>
> Best regards,
> Maxime Devos
>
>
>