Running Compiled Guile Objects

Running Compiled Guile Objects

[Hakan Candar via General Guile related discussions]

Dear Guile Users,

I am unable to run guile objects directly from the command line. I inspected the manual
thoroughly, however I did not see any mention of my desired action. Is it possible to execute
guile objects directly, or are they reserved for internal caching mechanism only?

I tried the following commands with no luck:
guile3.0 example.scm.go
guile3.0 --language=bytecode example.scm.go

Your help and interest is much appreciated.

Thanks,
Hakan

Re: Running Compiled Guile Objects

[Nala Ginrut]

Hi Hakan!
The current Guile is not AOT yet. Although the object file is ELF, it's
just bytecode wrapped ELF header. So you can't run it as a regular
executable file.

Best regards.

On Sat, Dec 14, 2024, 07:35 Hakan Candar via General Guile related
discussions <guile-user@gnu.org> wrote:

> Dear Guile Users,
>
> I am unable to run guile objects directly from the command line. I
> inspected the manual
> thoroughly, however I did not see any mention of my desired action. Is it
> possible to execute
> guile objects directly, or are they reserved for internal caching
> mechanism only?
>
> I tried the following commands with no luck:
> guile3.0 example.scm.go
> guile3.0 --language=bytecode example.scm.go
>
> Your help and interest is much appreciated.
>
> Thanks,
> Hakan

Re: Running Compiled Guile Objects

[Keith Wright]

Nala Ginrut <nalaginrut@gmail.com> writes:

> The current Guile is not AOT yet.

Google says: Attack On Titan.

> Although the object file is ELF, it's just bytecode wrapped ELF
> header. So you can't run it as a regular executable file.

I don't think that was the question...Hakan wants to call the
Guile executable and pass it a *.go file.

> On Sat, Dec 14, 2024, 07:35 Hakan Candar via General Guile related
> discussions <guile-user@gnu.org> wrote:
>
>> Dear Guile Users,
>>
>> I am unable to run guile objects directly from the command line. I

>> inspected the manual thoroughly, however I did not see any mention of
>> my desired action. Is it possible to execute guile objects directly,
>> or are they reserved for internal caching mechanism only?
>>
>> I tried the following commands with no luck:
>> guile3.0 example.scm.go
>> guile3.0 --language=bytecode example.scm.go
>>
>> Your help and interest is much appreciated.
>>
>> Thanks,
>> Hakan

Re: Running Compiled Guile Objects

[Nala Ginrut]

Hi Keith!
AOT stands for "Ahead-of-Time," and in this context, it refers to the
process of compiling source code directly into native machine code,
allowing the program to be executed as a regular binary file without
requiring a runtime interpreter.

@Hakan
The current .go file will be generated and loaded automatically, so one
don't have to load it explicitly.

To run a Guile source code, here's the document:
https://www.gnu.org/software/guile/manual/html_node/Running-Guile-Scripts.html

Basically, you run it as script, Guile will compile it to .go and load it.

Best regards.

On Sat, Dec 14, 2024, 10:14 Keith Wright <kwright@keithdiane.us> wrote:

> Nala Ginrut <nalaginrut@gmail.com> writes:
>
> > The current Guile is not AOT yet.
>
> Google says: Attack On Titan.
>
> > Although the object file is ELF, it's just bytecode wrapped ELF
> > header. So you can't run it as a regular executable file.
>
> I don't think that was the question...Hakan wants to call the
> Guile executable and pass it a *.go file.
>
> > On Sat, Dec 14, 2024, 07:35 Hakan Candar via General Guile related
> > discussions <guile-user@gnu.org> wrote:
> >
> >> Dear Guile Users,
> >>
> >> I am unable to run guile objects directly from the command line. I
>
> >> inspected the manual thoroughly, however I did not see any mention of
> >> my desired action. Is it possible to execute guile objects directly,
> >> or are they reserved for internal caching mechanism only?
> >>
> >> I tried the following commands with no luck:
> >> guile3.0 example.scm.go
> >> guile3.0 --language=bytecode example.scm.go
> >>
> >> Your help and interest is much appreciated.
> >>
> >> Thanks,
> >> Hakan
>

Re: Running Compiled Guile Objects

[Nala Ginrut]

If you just want to run the .go file, this is not a good way to go, since
it's binary format inside ELF can be changed in different Guile version.
And Guile compiler will handle these issues for you. So best practice is to
always run from a script and let Guile do the rest for you.

But if you really want to load .go without source code for some reasons,
you may do it in the REPL:
(load-compiled "example.scm.go")

Best regards.

On Sat, Dec 14, 2024, 11:33 Nala Ginrut <nalaginrut@gmail.com> wrote:

> Hi Keith!
> AOT stands for "Ahead-of-Time," and in this context, it refers to the
> process of compiling source code directly into native machine code,
> allowing the program to be executed as a regular binary file without
> requiring a runtime interpreter.
>
> @Hakan
> The current .go file will be generated and loaded automatically, so one
> don't have to load it explicitly.
>
> To run a Guile source code, here's the document:
>
> https://www.gnu.org/software/guile/manual/html_node/Running-Guile-Scripts.html
>
> Basically, you run it as script, Guile will compile it to .go and load it.
>
> Best regards.
>
> On Sat, Dec 14, 2024, 10:14 Keith Wright <kwright@keithdiane.us> wrote:
>
>> Nala Ginrut <nalaginrut@gmail.com> writes:
>>
>> > The current Guile is not AOT yet.
>>
>> Google says: Attack On Titan.
>>
>> > Although the object file is ELF, it's just bytecode wrapped ELF
>> > header. So you can't run it as a regular executable file.
>>
>> I don't think that was the question...Hakan wants to call the
>> Guile executable and pass it a *.go file.
>>
>> > On Sat, Dec 14, 2024, 07:35 Hakan Candar via General Guile related
>> > discussions <guile-user@gnu.org> wrote:
>> >
>> >> Dear Guile Users,
>> >>
>> >> I am unable to run guile objects directly from the command line. I
>>
>> >> inspected the manual thoroughly, however I did not see any mention of
>> >> my desired action. Is it possible to execute guile objects directly,
>> >> or are they reserved for internal caching mechanism only?
>> >>
>> >> I tried the following commands with no luck:
>> >> guile3.0 example.scm.go
>> >> guile3.0 --language=bytecode example.scm.go
>> >>
>> >> Your help and interest is much appreciated.
>> >>
>> >> Thanks,
>> >> Hakan
>>
>

RE: Running Compiled Guile Objects

[Maxime Devos via General Guile related discussions]

Compiling the .scm to .go ahead of time (with guild) and loading the .go directly makes a lot of sense:

• It avoids issues with locating the .go (no need to set .go path when invoking guile, although if it does use additional dependencies, depending on where they are located the script may need to set the .go (and .scm) path).
• It needs to look at less files (no need to compare .scm & .go modification times) (*)
• Easier to set compilation options (e.g. optimisation level)
• It avoids auto-compilation (no "compiling this thing / that thing” messages, no compilation cache filled with old junk, and in case of some forms of containerisation, avoids permission issues & transmission vector).

(*) won’t make a big difference since it most likely uses other modules, but it’s something.

>I tried the following commands with no luck:
>guile3.0 example.scm.go
>guile3.0 --language=bytecode example.scm.go

To my understanding of the language tower, the second is supposed to work. What does “no luck” mean here? (I don’t have a guile setup at the moment.)

(You need to recompile in case of some version changes, but that’s hardly Guile-specific.)

(There is an internal caching mechanism for autocompilation, but AOT (to bytecode) is a fine thing to do, and Guile supports that too. I recommend it for things like libraries and installed software (for random scripts autocompilation is likely good enough unless the extra messages or shared (per-user) cache directory are problematic.).)

Best regards,
Maxime Devos

Re: Running Compiled Guile Objects

[Nala Ginrut]

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.

BTW, I saw some Guile project didn't install .go to correct path. Even if
Makefile compiled .go and installed, the program will trap to
auto-compilation for the first time.
However, it's the matter of tweak the install path, rather than manually
load .go.

Best regards.

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

> Compiling the .scm to .go ahead of time (with guild) and loading the .go
> directly makes a lot of sense:
>
>
>
>    - It avoids issues with locating the .go (no need to set .go path when
>    invoking guile, although if it does use additional dependencies, depending
>    on where they are located the script may need to set the .go (and .scm)
>    path).
>    - It needs to look at less files (no need to compare .scm & .go
>    modification times) (*)
>    - Easier to set compilation options (e.g. optimisation level)
>    - It avoids auto-compilation (no "compiling this thing / that thing”
>    messages, no compilation cache filled with old junk, and in case of some
>    forms of containerisation, avoids permission issues & transmission vector).
>
>
>
> (*) won’t make a big difference since it most likely uses other modules,
> but it’s something.
>
>
>
> >I tried the following commands with no luck:
>
> >guile3.0 example.scm.go
>
> >guile3.0 --language=bytecode example.scm.go
>
>
>
> To my understanding of the language tower, the second is supposed to work.
> What does “no luck” mean here? (I don’t have a guile setup at the moment.)
>
>
>
> (You need to recompile in case of some version changes, but that’s hardly
> Guile-specific.)
>
>
>
> (There is an internal caching mechanism for autocompilation, but AOT (to
> bytecode) is a fine thing to do, and Guile supports that too. I recommend
> it for things like libraries and installed software (for random scripts
> autocompilation is likely good enough unless the extra messages or shared
> (per-user) cache directory are problematic.).)
>
>
>
> Best regards,
> Maxime Devos
>

RE: Running Compiled Guile Objects

[Maxime Devos via General Guile related discussions]

➢ 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

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
>

RE: Running Compiled Guile Objects

[Maxime Devos via General Guile related discussions]

➢ 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

Re: Running Compiled Guile Objects

[Nala Ginrut]

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

Re: Running Compiled Guile Objects

[Nala Ginrut]

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

Re: Running Compiled Guile Objects

[Nala Ginrut]

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

RE: Running Compiled Guile Objects

[Maxime Devos via General Guile related discussions]

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

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
>

Re: Running Compiled Guile Objects

[Basile Starynkevitch]

On Sat, 2024-12-14 at 09:15 +0900, Nala Ginrut wrote:
> Hi Hakan!
> The current Guile is not AOT yet. Although the object file is ELF,
> it's
> just bytecode wrapped ELF header. So you can't run it as a regular
> executable file.
> 

Those willing to contribute a proper ahead-of-time compiler to GNU
guile could use the GNU CC libgccjit library which is part of the GCC
compiler.
https://gcc.gnu.org/onlinedocs/jit/

This libgccjit layer of the GCC compiler is stable and maintained C API
and has some obsolete C++ API (which seems unmaintained in december
2024). Most of the libgccjit code is internally coded (under GPL
license) in C++, but the stable API is for C.

I am using the C API of libgccjit in the RefPerSys open source
inference engine project (GPLv3+ licensed) on
https://github.com/RefPerSys/RefPerSys/

Both libgccjit and GNU lightning (see
https://www.gnu.org/software/lightning/ ...) could be a basis for
adding a genuine compilation layer to GNU guile. And RefPerSys uses
both.

I guess a significant issue would be to use libgccjit (or GNU
lightning) with GUILE's garbage collector (which seems to be Boehm
conservative GC).

The RefPerSys project has a precise garbage collector and some
persistence (to textual files). Since it is GPLv3+ licensed, its code
could be reused in a future GUILE major version. RefPerSys is mostly
coded in C++.

I did contribute to GCC long time ago and hope that RefPerSys could
become a GNU project (but don't know how to make that happen)

Regards from near Paris in France.

-- 
Basile STARYNKEVITCH           <basile-VdE74OAlGqnvXjIo7pOF+l6hYfS7NtTn@public.gmane.org>
8 rue de la Faïencerie
92340 Bourg-la-Reine,          France
http://starynkevitch.net/Basile & https://github.com/bstarynk 

AOT compiler (was: Running Compiled Guile Objects)

[Nala Ginrut]

@basile I'm glad you raise this topic, I've played lobgccjit with a toy
project.
https://gitlab.com/hardenedlinux/screaming-fist

I would say libgccjit is a wrong name since it's more like a tool for AOT.
Of course, one may still use it for JIT, however you have to do your own
work for JIT and finally use libgccjit for codegen. 😁

Best regards.


---------- Forwarded message ---------
From: Basile Starynkevitch <basile@starynkevitch.net>
Date: Sun, Dec 15, 2024, 02:11
Subject: Re: Running Compiled Guile Objects
To: Nala Ginrut <nalaginrut@gmail.com>, Hakan Candar <
hakancandar@protonmail.com>
Cc: guile-user@gnu.org <guile-user@gnu.org>, <jit@gcc.gnu.org>


On Sat, 2024-12-14 at 09:15 +0900, Nala Ginrut wrote:
> Hi Hakan!
> The current Guile is not AOT yet. Although the object file is ELF,
> it's
> just bytecode wrapped ELF header. So you can't run it as a regular
> executable file.
>

Those willing to contribute a proper ahead-of-time compiler to GNU
guile could use the GNU CC libgccjit library which is part of the GCC
compiler.
https://gcc.gnu.org/onlinedocs/jit/

This libgccjit layer of the GCC compiler is stable and maintained C API
and has some obsolete C++ API (which seems unmaintained in december
2024). Most of the libgccjit code is internally coded (under GPL
license) in C++, but the stable API is for C.

I am using the C API of libgccjit in the RefPerSys open source
inference engine project (GPLv3+ licensed) on
https://github.com/RefPerSys/RefPerSys/

Both libgccjit and GNU lightning (see
https://www.gnu.org/software/lightning/ ...) could be a basis for
adding a genuine compilation layer to GNU guile. And RefPerSys uses
both.

I guess a significant issue would be to use libgccjit (or GNU
lightning) with GUILE's garbage collector (which seems to be Boehm
conservative GC).

The RefPerSys project has a precise garbage collector and some
persistence (to textual files). Since it is GPLv3+ licensed, its code
could be reused in a future GUILE major version. RefPerSys is mostly
coded in C++.

I did contribute to GCC long time ago and hope that RefPerSys could
become a GNU project (but don't know how to make that happen)

Regards from near Paris in France.

-- 
Basile STARYNKEVITCH           <basile@starynkevitch.net>
8 rue de la Faïencerie
92340 Bourg-la-Reine,          France
http://starynkevitch.net/Basile & https://github.com/bstarynk

RE: Running Compiled Guile Objects

[Maxime Devos via General Guile related discussions]

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

Re: Running Compiled Guile Objects

[Nala Ginrut]

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

Re: Running Compiled Guile Objects

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 872 bytes --]

Nala Ginrut <nalaginrut@gmail.com> writes:

> On Sat, Dec 14, 2024, 07:35 Hakan Candar via General Guile related
> discussions <guile-user@gnu.org> wrote:
>> I tried the following commands with no luck:
>> guile3.0 example.scm.go
>> guile3.0 --language=bytecode example.scm.go
>>
> The current Guile is not AOT yet. Although the object file is ELF, it's
> just bytecode wrapped ELF header. So you can't run it as a regular
> executable file.

The commands don’t look like running the files as executables, but
rather like running bytecode from Guile.

I think what works is

guile3.0 -C . -L . -e '(example)' -c ''

That should execute the main function in a module created with

(define-module (example) #:export (main))
(define (main args) #t)

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: Running Compiled Guile Objects

[Matt Wette]

On 12/13/24 12:34 PM, Hakan Candar via General Guile related discussions 
wrote:
> Dear Guile Users,
>
> I am unable to run guile objects directly from the command line. I inspected the manual
> thoroughly, however I did not see any mention of my desired action. Is it possible to execute
> guile objects directly, or are they reserved for internal caching mechanism only?
>
> I tried the following commands with no luck:
> guile3.0 example.scm.go
> guile3.0 --language=bytecode example.scm.go
>
> Your help and interest is much appreciated.
>
> Thanks,
> Hakan

This works:

$ cat hello.scm
(display "hello, world\n")

$ guild compile hello.scm -o hello.go
wrote `hello.go'

$ rm hello.scm

$ guile -L . -c '(load-compiled "hello.go")'
hello, world

If you have other .go's maybe adding `--no-auto-compile' is useful.

Matt

Re: Running Compiled Guile Objects

[David Malcolm]

On Sat, 2024-12-14 at 18:11 +0100, Basile Starynkevitch wrote:
> On Sat, 2024-12-14 at 09:15 +0900, Nala Ginrut wrote:
> > Hi Hakan!
> > The current Guile is not AOT yet. Although the object file is ELF,
> > it's
> > just bytecode wrapped ELF header. So you can't run it as a regular
> > executable file.
> > 
> 

[Sorry if I'm missing context here, I'm only seeing the part of the
thread where Basile CCed the jit-/MQLu3FmUzdAfugRpC6u6w@public.gmane.org mailing list]

> Those willing to contribute a proper ahead-of-time compiler to GNU
> guile could use the GNU CC libgccjit library which is part of the GCC
> compiler.
> https://gcc.gnu.org/onlinedocs/jit/

...and https://gcc.gnu.org/wiki/JIT

Indeed, it turns out that everyone using libgccjit is using it for
ahead-of-time compilation, rather than jit-compilation.  Sorry about
picking a bad name :)

Probably of most interest to guile developers might be the gccemacs
project here:
  https://akrl.sdf.org/gccemacs.html
since AFAIK that has successfully used libgccjit from within a lisp-
like language to get noticeable speedups.  But guile developers
probably know more about this than I do; I confess I don't know much
about the lisp/scheme world.
> 
> This libgccjit layer of the GCC compiler is stable and maintained C
> API
> and has some obsolete C++ API (which seems unmaintained in december
> 2024). Most of the libgccjit code is internally coded (under GPL
> license) in C++, but the stable API is for C.

Indeed, it is gcc's code generation source code (which is C++), wrapped
in a C API and header (it looks like a frontend to the rest of gcc, and
like an API to the client code).

Hope this is constructive
Dave

> 
> I am using the C API of libgccjit in the RefPerSys open source
> inference engine project (GPLv3+ licensed) on
> https://github.com/RefPerSys/RefPerSys/
> 
> Both libgccjit and GNU lightning (see
> https://www.gnu.org/software/lightning/ ...) could be a basis for
> adding a genuine compilation layer to GNU guile. And RefPerSys uses
> both.
> 
> I guess a significant issue would be to use libgccjit (or GNU
> lightning) with GUILE's garbage collector (which seems to be Boehm
> conservative GC).
> 
> The RefPerSys project has a precise garbage collector and some
> persistence (to textual files). Since it is GPLv3+ licensed, its code
> could be reused in a future GUILE major version. RefPerSys is mostly
> coded in C++.
> 
> I did contribute to GCC long time ago and hope that RefPerSys could
> become a GNU project (but don't know how to make that happen)
> 
> Regards from near Paris in France.
> 

RE: Running Compiled Guile Objects

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]

>> Those willing to contribute a proper ahead-of-time compiler to GNU
>> guile could use the GNU CC libgccjit library which is part of the GCC
>> compiler.
>> https://gcc.gnu.org/onlinedocs/jit/
>
>...and https://gcc.gnu.org/wiki/JIT
>
>Indeed, it turns out that everyone using libgccjit is using it for
>ahead-of-time compilation, rather than jit-compilation.  Sorry about
>picking a bad name :)

Are we talking about implementing a ‘to machine code’ compiler for Guile, or about implementing an ‘AOT to machine code’? Guile already has the former – it has a JIT (bytecode -> machine code) for some systems.

For what it’s worth -- I never worked with libgccjit or with the JIT code of Guile:

I imagine a basic (POC) AOT approach for Guile would be to let it compile AOT – with the JIT implementation, except adjusted to be relocatable and to add relocation information. As far as I can tell, libgccjit does not seem to support relocations and doesn’t say anything about whether the results are position-independent or not (so not suitable fo AOT), though presumably there are ways around that given the existence of gccemacs.

Best regards,
Maxime Devos

[-- Attachment #2: Type: text/html, Size: 3254 bytes --]

Re: Running Compiled Guile Objects

[David Malcolm]

On Sun, 2024-12-15 at 00:43 +0100, Maxime Devos wrote:
> > > Those willing to contribute a proper ahead-of-time compiler to
> > > GNU
> > > guile could use the GNU CC libgccjit library which is part of the
> > > GCC
> > > compiler.
> > > https://gcc.gnu.org/onlinedocs/jit/
> > 
> > ...and https://gcc.gnu.org/wiki/JIT
> > 
> > Indeed, it turns out that everyone using libgccjit is using it for
> > ahead-of-time compilation, rather than jit-compilation.  Sorry
> > about
> > picking a bad name :)
> 
> Are we talking about implementing a ‘to machine code’ compiler for
> Guile, or about implementing an ‘AOT to machine code’? 

I confess I have no idea what the conversation was about; I was just
responding to Basile's email to the "jit" mailing list :)


> Guile already has the former – it has a JIT (bytecode -> machine
> code) for some systems.
> 
> For what it’s worth -- I never worked with libgccjit or with the JIT
> code of Guile:
> 
> I imagine a basic (POC) AOT approach for Guile would be to let it
> compile AOT – with the JIT implementation, except adjusted to be
> relocatable and to add relocation information. As far as I can tell,
> libgccjit does not seem to support relocations and doesn’t say
> anything about whether the results are position-independent or not
> (so not suitable fo AOT), though presumably there are ways around
> that given the existence of gccemacs.

FWIW libgccjit builds position independent code, and can be used to
build dynamic libraries (which is what I believe gccemacs is doing).

Dave

Re: AOT compiler (was: Running Compiled Guile Objects)

[Nala Ginrut]

[-- Attachment #1: Type: text/plain, Size: 5952 bytes --]

Hi folks! Please reply AOT topic in this thread.


> Indeed, it turns out that everyone using libgccjit is using it for
ahead-of-time compilation, rather than jit-compilation.  Sorry about
picking a bad name :)

Thanks for the work!

At least in Guile community, now that we already have JIT with GNU
Lightening, we won't redundantly talk libgccjit for JIT. But I think it's
still interesting to try libgccjit for JIT in my other project. :-p

> Probably of most interest to guile developers might be the gccemacs
project here:
  https://akrl.sdf.org/gccemacs.html


It looks super interesting!

They created a high level IR just like GIMPLE, which named LIMPLE. It's the
way I preferred in streaming-fist. The basic idea is to provide such an IR,
then try to replace 'bytecode' in Guile compiler tower codegen. And they
choose SBCL for it, I think it can inspire people who are interested in
Guile AOT. Or maybe they could consider to change to Guile to save a lot of
time for both Guile and Emacs.

The compiler tower is so flexible that it's possible to try it as a plugin.

I agreed with @mikael about losing weight of Guile. The AOT feature can be
a plugin to install as guild tools. Of course, plugin unnecessarily mean it
will be small......


Best regards.

On Sun, Dec 15, 2024, 02:45 Nala Ginrut <nalaginrut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> Thanks for the inspiring sharing! 👏
>
> On Sun, Dec 15, 2024, 02:39 Basile Starynkevitch <basile-VdE74OAlGqnvXjIo7pOF+g@public.gmane.orgt>
> wrote:
>
>> On Sun, 2024-12-15 at 02:21 +0900, Nala Ginrut wrote:
>>
>> @basile I'm glad you raise this topic, I've played lobgccjit with a toy
>> project.
>> https://gitlab.com/hardenedlinux/screaming-fist
>>
>> I would say libgccjit is a wrong name since it's more like a tool for AOT.
>> Of course, one may still use it for JIT, however you have to do your own
>> work for JIT and finally use libgccjit for codegen. 😁
>>
>> Best regards.
>>
>>
>> You basically are right. If you want to use get a fast just-in-time
>> compilation, libgccjit might not be the right tool.
>>
>> But in practice, current computers are so fast that I think that in
>> practice libgccjit is quite usable, and it can be tuned to various GCC
>> optimization strategy.
>>
>> A few years ago I did experiment (see https://arxiv.org/abs/1109.0779 ...)
>> generation of C++ code which (on Linux desktop) was GCC compiled to a
>> plugin and dlopen-ed. This works quite well with an elapsed time suitable
>> for human users.
>>
>> A related experiment is my manydl.c thing on
>> https://github.com/bstarynk/misc-basile - it is/was a toy program that I
>> wrote which generates a lot of random C code (in many thousands of C
>> files), compile it to a plugin, and use dlopen and dlsym. It shows that on
>> Linux a process can successfully dlopen do many hundred thousands of
>> plugins (and never bother dlclose-ing them)
>>
>> BTW in France the Lisp syntax and Scheme semantics of GNU guile is sadly
>> becoming impopular. I know few persons using it.
>>
>> Just in case I am attaching a few PDF files on RefPerSys.
>>
>> Some ideas of RefPerSys originated from books and papers by by Jacques
>> Pitrat
>> https://en.wikipedia.org/wiki/Jacques_Pitrat
>>
>> Please mention RefPerSys to your colleagues and forward them this email.
>>
>> Thanks
>>
>>
>>
>> ---------- Forwarded message ---------
>> From: Basile Starynkevitch <basile-VdE74OAlGqnvXjIo7pOF+l6hYfS7NtTn@public.gmane.org>
>> Date: Sun, Dec 15, 2024, 02:11
>> Subject: Re: Running Compiled Guile Objects
>> To: Nala Ginrut <nalaginrut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Hakan Candar <
>> hakancandar-g/b1ySJe57IN+BqQ9rBEUg@public.gmane.org>
>> Cc: guile-user-mXXj517/zsQ@public.gmane.org <guile-user-mXXj517/zsQ@public.gmane.org>, <jit-/MQLu3FmUzdAfugRpC6u6w@public.gmane.org>
>>
>>
>> On Sat, 2024-12-14 at 09:15 +0900, Nala Ginrut wrote:
>> > Hi Hakan!
>> > The current Guile is not AOT yet. Although the object file is ELF,
>> > it's
>> > just bytecode wrapped ELF header. So you can't run it as a regular
>> > executable file.
>> >
>>
>> Those willing to contribute a proper ahead-of-time compiler to GNU
>> guile could use the GNU CC libgccjit library which is part of the GCC
>> compiler.
>> https://gcc.gnu.org/onlinedocs/jit/
>>
>> This libgccjit layer of the GCC compiler is stable and maintained C API
>> and has some obsolete C++ API (which seems unmaintained in december
>> 2024). Most of the libgccjit code is internally coded (under GPL
>> license) in C++, but the stable API is for C.
>>
>> I am using the C API of libgccjit in the RefPerSys open source
>> inference engine project (GPLv3+ licensed) on
>> https://github.com/RefPerSys/RefPerSys/
>>
>> Both libgccjit and GNU lightning (see
>> https://www.gnu.org/software/lightning/ ...) could be a basis for
>> adding a genuine compilation layer to GNU guile. And RefPerSys uses
>> both.
>>
>> I guess a significant issue would be to use libgccjit (or GNU
>> lightning) with GUILE's garbage collector (which seems to be Boehm
>> conservative GC).
>>
>> The RefPerSys project has a precise garbage collector and some
>> persistence (to textual files). Since it is GPLv3+ licensed, its code
>> could be reused in a future GUILE major version. RefPerSys is mostly
>> coded in C++.
>>
>> I did contribute to GCC long time ago and hope that RefPerSys could
>> become a GNU project (but don't know how to make that happen)
>>
>>
>> --
>>
>> Basile STARYNKEVITCH           <basile-VdE74OAlGqnvXjIo7pOF+l6hYfS7NtTn@public.gmane.org>8 rue de la Faïencerie
>> 92340 Bourg-la-Reine,          France <https://www.google.com/maps/search/8+rue+de+la+Fa%C3%AFencerie%0D%0A92340+Bourg-la-Reine,++++++++++France?entry=gmail&source=g>http://starynkevitch.net/Basile & https://github.com/bstarynk
>>
>>

[-- Attachment #2: Type: text/html, Size: 9844 bytes --]

Re: AOT compiler (was: Running Compiled Guile Objects)

[Nala Ginrut]

[-- Attachment #1: Type: text/plain, Size: 6719 bytes --]

> FWIW libgccjit builds position independent code, and can be used to
build dynamic libraries (which is what I believe gccemacs is doing).

To my limited experience, libgccjit can generate executable ELF and
relocatable .so, folks may pass gcc parameters for common considerations in
final codegen.

That's why I think libgccjit is good choice for Guile AOT. The whole
process and codegen can be consistent with common gcc cases and GNU
conventions.
Best regards.

On Sun, Dec 15, 2024, 10:59 Nala Ginrut <nalaginrut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> Hi folks! Please reply AOT topic in this thread.
>
>
> > Indeed, it turns out that everyone using libgccjit is using it for
> ahead-of-time compilation, rather than jit-compilation.  Sorry about
> picking a bad name :)
>
> Thanks for the work!
>
> At least in Guile community, now that we already have JIT with GNU
> Lightening, we won't redundantly talk libgccjit for JIT. But I think it's
> still interesting to try libgccjit for JIT in my other project. :-p
>
> > Probably of most interest to guile developers might be the gccemacs
> project here:
>   https://akrl.sdf.org/gccemacs.html
>
>
> It looks super interesting!
>
> They created a high level IR just like GIMPLE, which named LIMPLE. It's
> the way I preferred in streaming-fist. The basic idea is to provide such an
> IR, then try to replace 'bytecode' in Guile compiler tower codegen. And
> they choose SBCL for it, I think it can inspire people who are interested
> in Guile AOT. Or maybe they could consider to change to Guile to save a lot
> of time for both Guile and Emacs.
>
> The compiler tower is so flexible that it's possible to try it as a
> plugin.
>
> I agreed with @mikael about losing weight of Guile. The AOT feature can be
> a plugin to install as guild tools. Of course, plugin unnecessarily mean it
> will be small......
>
>
> Best regards.
>
> On Sun, Dec 15, 2024, 02:45 Nala Ginrut <nalaginrut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> Thanks for the inspiring sharing! 👏
>>
>> On Sun, Dec 15, 2024, 02:39 Basile Starynkevitch <
>> basile-VdE74OAlGqnvXjIo7pOF+l6hYfS7NtTn@public.gmane.org> wrote:
>>
>>> On Sun, 2024-12-15 at 02:21 +0900, Nala Ginrut wrote:
>>>
>>> @basile I'm glad you raise this topic, I've played lobgccjit with a toy
>>> project.
>>> https://gitlab.com/hardenedlinux/screaming-fist
>>>
>>> I would say libgccjit is a wrong name since it's more like a tool for
>>> AOT.
>>> Of course, one may still use it for JIT, however you have to do your own
>>> work for JIT and finally use libgccjit for codegen. 😁
>>>
>>> Best regards.
>>>
>>>
>>> You basically are right. If you want to use get a fast just-in-time
>>> compilation, libgccjit might not be the right tool.
>>>
>>> But in practice, current computers are so fast that I think that in
>>> practice libgccjit is quite usable, and it can be tuned to various GCC
>>> optimization strategy.
>>>
>>> A few years ago I did experiment (see https://arxiv.org/abs/1109.0779 ...)
>>> generation of C++ code which (on Linux desktop) was GCC compiled to a
>>> plugin and dlopen-ed. This works quite well with an elapsed time suitable
>>> for human users.
>>>
>>> A related experiment is my manydl.c thing on
>>> https://github.com/bstarynk/misc-basile - it is/was a toy program that
>>> I wrote which generates a lot of random C code (in many thousands of C
>>> files), compile it to a plugin, and use dlopen and dlsym. It shows that on
>>> Linux a process can successfully dlopen do many hundred thousands of
>>> plugins (and never bother dlclose-ing them)
>>>
>>> BTW in France the Lisp syntax and Scheme semantics of GNU guile is sadly
>>> becoming impopular. I know few persons using it.
>>>
>>> Just in case I am attaching a few PDF files on RefPerSys.
>>>
>>> Some ideas of RefPerSys originated from books and papers by by Jacques
>>> Pitrat
>>> https://en.wikipedia.org/wiki/Jacques_Pitrat
>>>
>>> Please mention RefPerSys to your colleagues and forward them this email.
>>>
>>> Thanks
>>>
>>>
>>>
>>> ---------- Forwarded message ---------
>>> From: Basile Starynkevitch <basile-VdE74OAlGqnvXjIo7pOF+l6hYfS7NtTn@public.gmane.org>
>>> Date: Sun, Dec 15, 2024, 02:11
>>> Subject: Re: Running Compiled Guile Objects
>>> To: Nala Ginrut <nalaginrut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Hakan Candar <
>>> hakancandar-g/b1ySJe57IN+BqQ9rBEUg@public.gmane.org>
>>> Cc: guile-user-mXXj517/zsQ@public.gmane.org <guile-user-mXXj517/zsQ@public.gmane.org>, <jit-/MQLu3FmUzdAfugRpC6u6w@public.gmane.org>
>>>
>>>
>>> On Sat, 2024-12-14 at 09:15 +0900, Nala Ginrut wrote:
>>> > Hi Hakan!
>>> > The current Guile is not AOT yet. Although the object file is ELF,
>>> > it's
>>> > just bytecode wrapped ELF header. So you can't run it as a regular
>>> > executable file.
>>> >
>>>
>>> Those willing to contribute a proper ahead-of-time compiler to GNU
>>> guile could use the GNU CC libgccjit library which is part of the GCC
>>> compiler.
>>> https://gcc.gnu.org/onlinedocs/jit/
>>>
>>> This libgccjit layer of the GCC compiler is stable and maintained C API
>>> and has some obsolete C++ API (which seems unmaintained in december
>>> 2024). Most of the libgccjit code is internally coded (under GPL
>>> license) in C++, but the stable API is for C.
>>>
>>> I am using the C API of libgccjit in the RefPerSys open source
>>> inference engine project (GPLv3+ licensed) on
>>> https://github.com/RefPerSys/RefPerSys/
>>>
>>> Both libgccjit and GNU lightning (see
>>> https://www.gnu.org/software/lightning/ ...) could be a basis for
>>> adding a genuine compilation layer to GNU guile. And RefPerSys uses
>>> both.
>>>
>>> I guess a significant issue would be to use libgccjit (or GNU
>>> lightning) with GUILE's garbage collector (which seems to be Boehm
>>> conservative GC).
>>>
>>> The RefPerSys project has a precise garbage collector and some
>>> persistence (to textual files). Since it is GPLv3+ licensed, its code
>>> could be reused in a future GUILE major version. RefPerSys is mostly
>>> coded in C++.
>>>
>>> I did contribute to GCC long time ago and hope that RefPerSys could
>>> become a GNU project (but don't know how to make that happen)
>>>
>>>
>>> --
>>>
>>> Basile STARYNKEVITCH           <basile-VdE74OAlGqnvXjIo7pOF+l6hYfS7NtTn@public.gmane.org>8 rue de la Faïencerie
>>> 92340 Bourg-la-Reine,          France <https://www.google.com/maps/search/8+rue+de+la+Fa%C3%AFencerie%0D%0A92340+Bourg-la-Reine,++++++++++France?entry=gmail&source=g>http://starynkevitch.net/Basile & https://github.com/bstarynk
>>>
>>>

[-- Attachment #2: Type: text/html, Size: 10983 bytes --]

Re: AOT compiler (was: Running Compiled Guile Objects)

[Eli Zaretskii]

> From: Nala Ginrut <nalaginrut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date: Sun, 15 Dec 2024 11:08:25 +0900
> Cc: Maxime Devos <maximedevos-CNXmb7IdZIWZIoH1IeqzKA@public.gmane.org>, team-rHw2apc0TIwgsBAKwltoeQ@public.gmane.org, jit-/MQLu3FmUzdAfugRpC6u6w@public.gmane.org,
>  "dmalcolm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org" <dmalcolm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, basile-VdE74OAlGqnvXjIo7pOF+l6hYfS7NtTn@public.gmane.org
> 
> > FWIW libgccjit builds position independent code, and can be used to
> build dynamic libraries (which is what I believe gccemacs is doing).

A nit: there's no such thing as gccemacs.

Perhaps you mean GNU Emacs starting from version 28, which can compile
Lisp into native code using libgccjit?

Re: AOT compiler (was: Running Compiled Guile Objects)

[Nala Ginrut]

[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]

@eli
I’m referring to the mentioned link
https://akrl.sdf.org/gccemacs.html

Though it’s named gccemacs, may not be recognized by gcc or emacs community.

Actually I never heard of it before.


On Reiwa 6 Dec 15, Sun at 16:39 Eli Zaretskii <eliz-mXXj517/zsQ@public.gmane.org> wrote:

> > From: Nala Ginrut <nalaginrut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date: Sun, 15 Dec 2024 11:08:25 +0900
> > Cc: Maxime Devos <maximedevos-CNXmb7IdZIWZIoH1IeqzKA@public.gmane.org>, team-rHw2apc0TIwgsBAKwltoeQ@public.gmane.org,
> jit-/MQLu3FmUzdAfugRpC6u6w@public.gmane.org,
> >  "dmalcolm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org" <dmalcolm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, basile-VdE74OAlGqnvXjIo7pOF+l6hYfS7NtTn@public.gmane.org
> >
> > > FWIW libgccjit builds position independent code, and can be used to
> > build dynamic libraries (which is what I believe gccemacs is doing).
>
> A nit: there's no such thing as gccemacs.
>
> Perhaps you mean GNU Emacs starting from version 28, which can compile
> Lisp into native code using libgccjit?
>

[-- Attachment #2: Type: text/html, Size: 2191 bytes --]

Re: AOT compiler (was: Running Compiled Guile Objects)

[Eli Zaretskii]

> From: Nala Ginrut <nalaginrut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date: Sun, 15 Dec 2024 17:07:24 +0900
> Cc: guile-user-mXXj517/zsQ@public.gmane.org, maximedevos-CNXmb7IdZIWZIoH1IeqzKA@public.gmane.org, team-rHw2apc0TIwgsBAKwltoeQ@public.gmane.org, 
> 	jit-/MQLu3FmUzdAfugRpC6u6w@public.gmane.org, dmalcolm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, basile-VdE74OAlGqnvXjIo7pOF+l6hYfS7NtTn@public.gmane.org
> 
> I’m referring to the mentioned link 
> https://akrl.sdf.org/gccemacs.html

Whose last update was on 2021-02-26, almost 4 years ago.

This is an integral part of Emacs since long ago.

Re: AOT compiler (was: Running Compiled Guile Objects)

[Nala Ginrut]

[-- Attachment #1: Type: text/plain, Size: 787 bytes --]

Was it merged to upstream or abandoned?
Best regards.

On Sun, Dec 15, 2024, 19:41 Eli Zaretskii <eliz-mXXj517/zsQ@public.gmane.org> wrote:

> > From: Nala Ginrut <nalaginrut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date: Sun, 15 Dec 2024 17:07:24 +0900
> > Cc: guile-user-mXXj517/zsQ@public.gmane.org, maximedevos-CNXmb7IdZIWZIoH1IeqzKA@public.gmane.org, team-rHw2apc0TIwgsBAKwltoeQ@public.gmane.org,
> >       jit-/MQLu3FmUzdAfugRpC6u6w@public.gmane.org, dmalcolm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, basile-VdE74OAlGqnvXjIo7pOF+l6hYfS7NtTn@public.gmane.org
> >
> > I’m referring to the mentioned link
> > https://akrl.sdf.org/gccemacs.html
>
> Whose last update was on 2021-02-26, almost 4 years ago.
>
> This is an integral part of Emacs since long ago.
>

[-- Attachment #2: Type: text/html, Size: 1907 bytes --]

Re: AOT compiler (was: Running Compiled Guile Objects)

[tomas-2s+jgvIlYZ2ELgA04lAiVw]

[-- Attachment #1: Type: text/plain, Size: 986 bytes --]

On Sun, Dec 15, 2024 at 07:49:59PM +0900, Nala Ginrut wrote:
> Was it merged to upstream or abandoned?
> Best regards.
> 
> On Sun, Dec 15, 2024, 19:41 Eli Zaretskii <eliz-mXXj517/zsQ@public.gmane.org> wrote:
> 
> > > From: Nala Ginrut <nalaginrut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > Date: Sun, 15 Dec 2024 17:07:24 +0900
> > > Cc: guile-user-mXXj517/zsQ@public.gmane.org, maximedevos-CNXmb7IdZIWZIoH1IeqzKA@public.gmane.org, team-rHw2apc0TIwgsBAKwltoeQ@public.gmane.org,
> > >       jit-/MQLu3FmUzdAfugRpC6u6w@public.gmane.org, dmalcolm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, basile-VdE74OAlGqnvXjIo7pOF+l6hYfS7NtTn@public.gmane.org
> > >
> > > I’m referring to the mentioned link
> > > https://akrl.sdf.org/gccemacs.html
> >
> > Whose last update was on 2021-02-26, almost 4 years ago.
> >
> > This is an integral part of Emacs since long ago.

It's in. It has been extensively discussed in emacs-devel-0jIIvIziipk@public.gmane.org

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: AOT compiler (was: Running Compiled Guile Objects)

[Eli Zaretskii]

> From: Nala Ginrut <nalaginrut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date: Sun, 15 Dec 2024 19:49:59 +0900
> Cc: guile-user-mXXj517/zsQ@public.gmane.org, maximedevos-CNXmb7IdZIWZIoH1IeqzKA@public.gmane.org, team-rHw2apc0TIwgsBAKwltoeQ@public.gmane.org, 
> 	jit-/MQLu3FmUzdAfugRpC6u6w@public.gmane.org, dmalcolm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, basile-VdE74OAlGqnvXjIo7pOF+l6hYfS7NtTn@public.gmane.org
> 
> Was it merged to upstream or abandoned?

It was merged to upstream Emacs 3 years ago, and is part of the
released Emacs versions since Apr 2022.

Re: AOT compiler (was: Running Compiled Guile Objects)

[Nala Ginrut]

[-- Attachment #1: Type: text/plain, Size: 826 bytes --]

Thanks for all your explanation!

Is the IR keeping the design of LIMPLE described in the slide? Maybe Guile
AOT can be inspired from it.
Best regards.

On Sun, Dec 15, 2024, 20:02 Eli Zaretskii <eliz-mXXj517/zsQ@public.gmane.org> wrote:

> > From: Nala Ginrut <nalaginrut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date: Sun, 15 Dec 2024 19:49:59 +0900
> > Cc: guile-user-mXXj517/zsQ@public.gmane.org, maximedevos-CNXmb7IdZIWZIoH1IeqzKA@public.gmane.org, team-rHw2apc0TIwgsBAKwltoeQ@public.gmane.org,
> >       jit-/MQLu3FmUzdAfugRpC6u6w@public.gmane.org, dmalcolm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, basile-VdE74OAlGqnvXjIo7pOF+l6hYfS7NtTn@public.gmane.org
> >
> > Was it merged to upstream or abandoned?
>
> It was merged to upstream Emacs 3 years ago, and is part of the
> released Emacs versions since Apr 2022.
>

[-- Attachment #2: Type: text/html, Size: 1876 bytes --]

Re: AOT compiler (was: Running Compiled Guile Objects)

[Eli Zaretskii]

> From: Nala Ginrut <nalaginrut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date: Sun, 15 Dec 2024 20:09:25 +0900
> Cc: guile-user-mXXj517/zsQ@public.gmane.org, maximedevos-CNXmb7IdZIWZIoH1IeqzKA@public.gmane.org, team-rHw2apc0TIwgsBAKwltoeQ@public.gmane.org, 
> 	jit-/MQLu3FmUzdAfugRpC6u6w@public.gmane.org, dmalcolm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, basile-VdE74OAlGqnvXjIo7pOF+l6hYfS7NtTn@public.gmane.org
> 
> Is the IR keeping the design of LIMPLE described in the slide?

Yes.