Re: Implementing Guile with a Windows port
Am Samstag, dem 09.10.2021 um 21:32 +0300 schrieb Eli Zaretskii: > > From: Taylan Kammer > > Date: Sat, 9 Oct 2021 20:10:15 +0200 > > > > I can't speak for the developers, but as far as I can tell, there > > isn't the right combination of willingness and resources to support a > > native port of GNU Guile for MS Windows. > > > > As far as I know, there's a MinGW port, but if I'm not mistaken it's > > partly neglected and not as feature-rich as the "normal" GNU/Linux > > version. > > A MinGW port of Guile 2.0.11 can be found on the ezwinports site. > AFAIK, the only feature it omits is threads, because Guile built with > threads is broken on MS-Windows. With a few tweaks, it's also possible to build Guile 2.2 for mingw64, https://github.com/hahnjo/lilypond-binaries/blob/main/scripts/build_native_deps.sh#L474-L492 (with a few things like networking and threads disabled because we don't need them; not sure if this would be functional if enabled). It would be nice if this worked out-of-the-box... signature.asc Description: This is a digitally signed message part
Re: GC + Java finalization
Am Donnerstag, dem 15.07.2021 um 20:44 +0200 schrieb Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library: > Am Samstag, dem 03.07.2021 um 14:05 +0200 schrieb Jonas Hahnfeld via > Developers list for Guile, the GNU extensibility library: > > Hi Guile devs, > > > > I'm hacking on GNU LilyPond and recently wondered if Guile could run > > without Java finalization that prevents collection of chains of > > unreachable objects. I found that the functionality is only needed once > > the first guardian is created, so it's possible to delay enabling the > > mode until then. This required some fixes to free functions that > > assumed dependent objects to be freed only later (see first two > > patches). > > The third patch delays ensuring Java finalization to scm_make_guardian, > > but doesn't disable it explicitly (it's on by default in bdwgc). This > > could now be done right after GC_INIT(), but it's not clear (at least > > to me) whether client applications actually rely it, so I think it's > > better if that's not done in Guile itself. > > > > Please consider applying, the fixes potentially also to stable-2.2. > > I didn't receive other comments than those by Maxime, so here is an > updated version of the first patch. Ping, is there anybody looking at patches sent to the mailing list? signature.asc Description: This is a digitally signed message part
Re: guile and libgccjit
On Sun, Oct 10, 2021 at 09:57:13AM +0200, Linus Björnstam wrote: > The the current JIT is, in my understanding, more or less a stepping stone > towards native compilation. The current JIT is very small and lightweight, > without any tracing, meaning things like register allocation is flexible > going forward. > > I am not a maintainer, nor heavily involved, but I believe libgccjit would be > a step sideways considering the above. I think there's some (very readable!) rationale on why Andy chose a relatively "simple" JIT in his blog [1]. It's a fork of GNU lightning. The post explains why the powerful optimisations built into new versions of Lightning seem contraproductive for Guile. Since libgccjit will have even more powerful optimisations (it's gcc, after all!), I guess the same arguments hold. Note that Emacs is currently integrating an Elisp compiler based on libgccjit. But as far as I can see, it's more an AOT compiler than a JIT. Cheers [1] https://wingolog.org/archives/2019/05/24/lightening-run-time-code-generation - t signature.asc Description: Digital signature
Re: guile and libgccjit
The the current JIT is, in my understanding, more or less a stepping stone towards native compilation. The current JIT is very small and lightweight, without any tracing, meaning things like register allocation is flexible going forward. I am not a maintainer, nor heavily involved, but I believe libgccjit would be a step sideways considering the above. Best regards Linus Björnstam On Sun, 10 Oct 2021, at 01:06, Andy Tai wrote: > can guile make use of libgccjit? > > would be an interesting optional addition to guile
Re: Implementing Guile with a Windows port
> Date: Sat, 9 Oct 2021 22:02:06 -0300 > From: David Pirotte > Cc: Taylan Kammer , andrewgo...@yahoo.com.sg, > guile-devel@gnu.org > > Le Sat, 09 Oct 2021 21:32:23 +0300, > Eli Zaretskii a écrit : > > > A MinGW port of Guile 2.0.11 can be found on the ezwinports site. > > AFAIK, the only feature it omits is threads, because Guile built with > > threads is broken on MS-Windows. > > Fwiw, when I need to, I use msys2: > > https://www.msys2.org/ > > https://packages.msys2.org/search?t=binpkg=guile > => > Package Version > guile 2.2.7-1 > libguile2.2.7-1 > libguile-devel 2.2.7-1 That's not a native MS-Windows program, its behavior differs from native programs in subtle ways. If that doesn't bother the OP, then it's fine to use it. But you cannot, for example, use libguile from that distribution to build a MinGW port of GDB or GNU Make with Guile support, because that libguile can only be linked into MSYS2 executables. So once you start using that library, you are locked into MSYS2 applications and cannot escape into native MS-Windows applications produced by MinGW.
