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://g
>> 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
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
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 obj
Nala Ginrut writes:
> On Sat, Dec 14, 2024, 07:35 Hakan Candar via General Guile related
> discussions 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
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 Maxi
>> 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.
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 GN
> 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 unde
>> 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 de
> 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 trigge
> 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
> 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 wrote:
>
>- IMHO, the manually .go loading will cause more issues.
>- First, h
➢ 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
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.sc
➢ 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 neces
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 p
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
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 real
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 an
Nala Ginrut 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
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 wrote:
> Dear Guile Users,
>
> I am
22 matches
Mail list logo
