> From: Nala Ginrut
> Date: Sun, 15 Dec 2024 20:09:25 +0900
> Cc: guile-user@gnu.org, maximede...@telenet.be, t...@refpersys.org,
> j...@gcc.gnu.org, dmalc...@redhat.com, bas...@starynkevitch.net
>
> Is the IR keeping the design of LIMPLE described in the slide?
Yes.
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 wrote:
> > From: Nala Ginrut
> > Date: Sun, 15 Dec 2024 19:49:59 +0900
> > Cc: guile-user@gnu.org, ma
> From: Nala Ginrut
> Date: Sun, 15 Dec 2024 19:49:59 +0900
> Cc: guile-user@gnu.org, maximede...@telenet.be, t...@refpersys.org,
> j...@gcc.gnu.org, dmalc...@redhat.com, bas...@starynkevitch.net
>
> Was it merged to upstream or abandoned?
It was merged to upstream Emacs 3 years ago, and
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 wrote:
>
> > > From: Nala Ginrut
> > > Date: Sun, 15 Dec 2024 17:07:24 +0900
> > > Cc: guile-user@gnu.org, maximede...@telenet.be,
Was it merged to upstream or abandoned?
Best regards.
On Sun, Dec 15, 2024, 19:41 Eli Zaretskii wrote:
> > From: Nala Ginrut
> > Date: Sun, 15 Dec 2024 17:07:24 +0900
> > Cc: guile-user@gnu.org, maximede...@telenet.be, t...@refpersys.org,
> > j...@gcc.gnu.org, dmalc...@redhat.com, bas...@
> From: Nala Ginrut
> Date: Sun, 15 Dec 2024 17:07:24 +0900
> Cc: guile-user@gnu.org, maximede...@telenet.be, t...@refpersys.org,
> j...@gcc.gnu.org, dmalc...@redhat.com, bas...@starynkevitch.net
>
> I’m referring to the mentioned link
> https://akrl.sdf.org/gccemacs.html
Whose last upda
@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 wrote:
> > From: Nala Ginrut
> > Date: Sun, 15 Dec 2024
> From: Nala Ginrut
> Date: Sun, 15 Dec 2024 11:08:25 +0900
> Cc: Maxime Devos , t...@refpersys.org,
> j...@gcc.gnu.org,
> "dmalc...@redhat.com" , bas...@starynkevitch.net
>
> > FWIW libgccjit builds position independent code, and can be used to
> build dynamic libraries (which is what I believ
sands 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
t;> 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
>>
>>
>>
>>
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.
ork for JIT and finally use libgccjit for codegen. 😁
Best regards.
-- Forwarded message -
From: Basile Starynkevitch
Date: Sun, Dec 15, 2024, 02:11
Subject: Re: Running Compiled Guile Objects
To: Nala Ginrut , Hakan Candar <
hakancan...@protonmail.com>
Cc: guile-user@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 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
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
34 matches
Mail list logo
