[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Libgettextpo wrapper for Guile
Re: Libgettextpo wrapper for Guile
Wed, 8 May 2019 16:32:15 +0200
(Links at the end for readability.)
Bruno Haible <address@hidden>:
> Hi Miguel,
After some suggestions made by private email and being suggested in
the savannah admission process to integrate it in gettext, I gave a
second look into the topic, and check the pros and cons more
> > an external project would be useful anyway as
> > does not require a version update of neither Gettext nor Guile to
> > start using it
> A separate project also means an independent release cycle.
This can be a problem until the library reaches an stable status, as
GNU gettext is a mature project and the library may need better advice
in some areas. Nonetheless, the pace of evolution will be reduced
very much when some design issues are clarified and a set of clear
Scheme idioms is found, and it will follow surely libgettextpo
evolution and not Guile. I've tested it with Guile 2.0.14, Guile 2.2.4
and Guile 2.9.1, with all tests are working as expected. It does not
work with Guile 1.8, as the ffi module at least was added with 2.0
release (scm_to_pointer, scm_t_pointer_finalizer, etc.) and I don't
know if it worths the effort porting it over that version, but it
could be a secondary effect of some changes in the implementation.
> How are other Guile bindings organized?
> - guile-cairo separate project
It seems that all language bindings are separate projects.
> - guile-gnome separate project
Gtk+ bindings are separate projects too, even though guile-gnome needs
some updates as it was Gtk+2 last time I played with it.
> - guile-git separate project
Git seems to have all its bindings as separate projects too.
> - libgccjit separate project
This one is quite new and I didn't know about it. GNU Lightning is
there too and it is used for the JIT implementation in the future Guile
> - zeromq at zeromq
This actually is a separate project if you look into the page.
> - guile-gnutls at gnutls
> - gmp part of guile
AFAIK guile does not export bindings from any GMP library, but it uses
GMP internally to implement the number tower required by Scheme.
I would like to add these examples too:
- gettext part of guile
- texinfo manipulation part of guile
- gdb part of gdb
- mailutils part of mailutils
- make part of make
- guile-opengl separate project
- guile-parted separate-project
- guile-gcrypt separate project
> The majority seems to have chosen to be available as separate project.
Most of them are available as separate projects, I agree. Although I
think the integration in any of them (Guile or Gettext) benefits the
GNU Project itself.
> > I think the choice should have more to do with Gettext's desire as a
> > project to extend its code base in Guile in the future, as the Guile
> > library could be the foundation for new tools, or to keep C as the
> > main code base
> There are no plans to use a different implementation language for
> PO file manipulations. With the existing code base as a start, it
> is not much harder to code new functionality in C than it would be
> to code it in Python, guile, Java, or other languages.
> Gettext needs a different implementation language in other areas -
> such as extracting relevant information from HTML pages - and is
> using POSIX sh for this purpose. It's a balance between language
> features, portability, and ease of installation / minimization of
My ideas were not clear at that point, so I must retract of what I
said; your point is more than valid.
In this case I could think the extension as a user of gettext's tools,
not only as the main code of the project. I'm probably the only
user of the library at this moment, but I'm using it for translation
tasks such as translating the same fragment of text again and again.
There is a similar library for Python, and gettext already has the
code to do the same task.
What do you think?
 The main issue in my TODO list is clarifying the non-local exits.
I'm currently checking the code, after I have enough information I'll
open a separate thread probably about this.
 I'm not completely confortable with the /with-po-files/ approach,
but I think it is a good idea to perform file management through
declaration than imperatively, and I'd like to evolve a bit at least
this interface, as most of the functions are mostly calls to the C
 The (gettext po internal-api) module could be removed and the C
source could export all the needed functions instead of relying on
(system ffi). Would this be enough? I thought about that regarding
speed/efficiency, but that can be another reason.