> 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
Thanks---I didn't know about your work on lua. Should be included in Guile
proper IMO!
(Some people complain about Guile being large. I think it would be good if
there was a way to create a minimal Guile for those that want to ship Guile
with their application. Perhaps even the Guile distribution
Being able to script in Python in Guile would be the strongest yet showcase
for multi-language support in Guile and would be an additional strong
argument for Guile in Emacs.
Den lör 14 dec. 2024 11:23Mikael Djurfeldt skrev:
> While this is interesting, I'd like to have support for Python proper
I believe the Guile compiler tower is flexible enough to allow new
languages to be maintained independently, and it makes installing a new
language quite straightforward.
On Sat, Dec 14, 2024, 20:17 Mikael Djurfeldt wrote:
> Thanks---I didn't know about your work on lua. Should be included in Gu
Oh I didn't try python-for-guile for a while, seems it got a lot
improvements!
I need to polish guile-lua-rebirth, years ago I was working on run Lua code
as GNU Artanis webapp, it booted successfully, however COVID broke all my
plans, I almost forgot I have it...
https://gitlab.com/NalaGinrut/gui
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
While this is interesting, I'd like to have support for Python proper, with
support for Python C interface such that it is possible to load Python
extensions.
Stefan Israelsson Tampe previously implemented Python in Guile
https://gitlab.com/python-on-guile/python-on-guile/
I've tested it and it's
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
➢ 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
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
➢ 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
> 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
> 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
> 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
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
>> 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
> 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
@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 fina
>> 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.
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
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
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
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
>> 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 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
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 GN
> 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.
27 matches
Mail list logo
