* Libgettextpo wrapper for Guile @ 2019-05-04 22:49 Miguel [not found] ` <20190505004925.24e650e4-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 0 siblings, 1 reply; 7+ messages in thread From: Miguel @ 2019-05-04 22:49 UTC (permalink / raw) To: guile-devel-mXXj517/zsQ, bug-gettext-mXXj517/zsQ Hi to all! I'm crossposting to these lists because I wasn't unable to find a library to work with PO files in Guile after a script written in Python (using polib) was posted in another mailing list. It was really useful, and I cannot thank enough its author. However, I felt what people from Galicia call "morriña" while I was downloading Python for the first time in this machine, missing the parens of my preferred language. To help with the mild pain, I implemented a wrapper library for Guile and a couple of higher level functions, tests and I'm documenting everything. I'd like to contribute it to GNU---a wrapper of a GNU library in the official GNU extension language, I think it's sensible---, but I would like to ask you where it would fit better: - In GNU gettext as part of gettext-tools? It could cause problems in the Guile bootstrap, as several tools from there are needed when NLS is enabled. Nevertheless, it seems to be the better fit in terms of code locality and cross maintenance. - In Guile as an ice-9 module? As readline, it could be a GPLv3+ library, but also available from scratch. From my point of view, it would be a great option in terms of (zero) increment of dependencies and tight integration with the language. - As an external library? I'll choose the last one if the general response doesn't point clearly in any other direction, but I wanted to ask first for advice and ideas, as wise folks like you probably have some I haven't thought of. Happy hacking! Miguel ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <20190505004925.24e650e4-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* Re: Libgettextpo wrapper for Guile [not found] ` <20190505004925.24e650e4-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> @ 2019-05-05 13:45 ` Bruno Haible 2019-05-05 16:34 ` Miguel 0 siblings, 1 reply; 7+ messages in thread From: Bruno Haible @ 2019-05-05 13:45 UTC (permalink / raw) To: bug-gettext-mXXj517/zsQ; +Cc: guile-devel-mXXj517/zsQ Hi Miguel, > I implemented a wrapper library > for Guile and a couple of higher level functions, tests and I'm > documenting everything. This is great. Many thanks for this contribution!! > I'd like to contribute it to GNU---a wrapper of a GNU library in the > official GNU extension language, I think it's sensible---, but I would > like to ask you where it would fit better: > > - In GNU gettext as part of gettext-tools? It could cause > problems in the Guile bootstrap, as several tools from there > are needed when NLS is enabled. Nevertheless, it seems to be > the better fit in terms of code locality and cross > maintenance. Very good question. I think there are two aspects: - Development aspects. Does your guile wrapper need more know-how from the guile world or from the gettext world? (*) Will it need regular changes as guile evolves? Surely it will need changes when gettext-po.h evolves, but gettext-po.h has been stable since 2010. (*) This is relevant, because when at some point in time you will not want to maintain it any more, will it be more easy to find a new maintainer for it among the camp of guile developers or among the gettext developers? - Distributions aspects. Distros will likely package it in a package different from gettext and different from guile, since both gettext and guile can be used without the wrapper library. Right? But distros are already used to create multiple binary packages from a single source package. > - In Guile as an ice-9 module? As readline, it could be a > GPLv3+ library, but also available from scratch. From my > point of view, it would be a great option in terms of > (zero) increment of dependencies and tight integration with > the language. I don't know what an ice-9 module is. I also don't know whether you can define an ice-9 module outside of the guile package. > - As an external library? Would you want to have a project infrastructure with mailing list, bug trackers, etc. for this wrapper library? I would think this is overkill. Bruno ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Libgettextpo wrapper for Guile 2019-05-05 13:45 ` Bruno Haible @ 2019-05-05 16:34 ` Miguel 2019-05-05 18:45 ` Bruno Haible 0 siblings, 1 reply; 7+ messages in thread From: Miguel @ 2019-05-05 16:34 UTC (permalink / raw) To: bug-gettext-mXXj517/zsQ, guile-devel-mXXj517/zsQ Hi Bruno, > Hi Miguel, > > > I implemented a wrapper library > > for Guile and a couple of higher level functions, tests and I'm > > documenting everything. > > This is great. Many thanks for this contribution!! You're welcome! I hope it will be useful. And it would not be possible without your work, so actually thank you all. > > I'd like to contribute it to GNU---a wrapper of a GNU library in the > > official GNU extension language, I think it's sensible---, but I > > would like to ask you where it would fit better: > > > > - In GNU gettext as part of gettext-tools? It could cause > > problems in the Guile bootstrap, as several tools from > > there are needed when NLS is enabled. Nevertheless, it seems to be > > the better fit in terms of code locality and cross > > maintenance. > > Very good question. I think there are two aspects: > > - Development aspects. Does your guile wrapper need more know-how > from the guile world or from the gettext world? (*) Will it need > regular changes as guile evolves? Surely it will need changes > when gettext-po.h evolves, but gettext-po.h has been stable > since 2010. > (*) This is relevant, because when at some point in time you > will not want to maintain it any more, will it be more easy to > find a new maintainer for it among the camp of guile developers > or among the gettext developers? On one hand, this Guile library is tightly coupled with libgettextpo and its integration in the gettext world could drive some of improvements into the C library itself, such as an extension of the iteration interface to a bidirectional or random access one. On the other hand, it only has one source file written in C, it is mainly intended to the Lisp world. Gettext's source code is mainly written in C, with the main exception of the example code and the java runtime. 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, a reasonable position for such a key software and its amount of codified knowledge. It is also coupled to Guile as it uses (system ffi), even though that interface is quite stable too. The other sparsely used modules are (ice-9 format) and (ice-9 regex). Anything else is standard Scheme or available as an SRFI, at least that's what I've tried. I'm sure there are plenty of people in both worlds that are able to hack any bug in my code in an hour, and much better I'd do it. > - Distributions aspects. Distros will likely package it in a > package different from gettext and different from guile, since > both gettext and guile can be used without the wrapper library. > Right? Yes, for sure, breaking any of them would be a huge bug. 0:-) > But distros are already used to create multiple binary packages > from a single source package. That shouldn't be a problem, I agree. > > - In Guile as an ice-9 module? As readline, it could be a > > GPLv3+ library, but also available from scratch. From my > > point of view, it would be a great option in terms of > > (zero) increment of dependencies and tight integration > > with the language. > > I don't know what an ice-9 module is. Ice-nine is a fictional water crystal stable at room temperature from Kurt Vonnegut's novel Cat's Cradle, that makes solid all water it comes into contact with. AFAIK, this reference is used in the Guile world for the official modules that are pervasively useful, including the bootstrapping of the language itself and libraries like readline. I don't remember where I've read it but I think I'm not making it up. > I also don't know whether you can define an ice-9 module outside of > the guile package. You probably can, although Guile has several modules in other namespaces too. My wish is that it is so useful that it deserves that name, although the module I'm using in the implementation right now is (gettext po). The key point for its inclusion in Guile would be its availability right out-of-the-box, not really the name. > > - As an external library? > > Would you want to have a project infrastructure with mailing list, > bug trackers, etc. for this wrapper library? I would think this is > overkill. I was planning to use Savannah, I've prepared the form twice but didn't hit send yet. It might be an overkill, that's true, but I don't want to use other easier and faster (and with extra lack of freedom) repository server as GH, neither keep it to myself. Also, with a small code base there should not be so many maintenance tasks neither, and I think I could face that up. Even more, it would not be available on older versions than the first Guile release with it, so an external project would be useful anyway as does not require a version update of neither Gettext nor Guile to start using it, at least as some kind of "backports"---I'm not aware of any project of this kind. Happy hacking, Miguel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Libgettextpo wrapper for Guile 2019-05-05 16:34 ` Miguel @ 2019-05-05 18:45 ` Bruno Haible 2019-05-05 23:04 ` amirouche 2019-05-08 14:32 ` Miguel 0 siblings, 2 replies; 7+ messages in thread From: Bruno Haible @ 2019-05-05 18:45 UTC (permalink / raw) To: Miguel; +Cc: guile-devel, bug-gettext Hi Miguel, > 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. How are other Guile bindings organized? - guile-cairo separate project https://www.nongnu.org/guile-cairo/ - guile-gnome separate project https://www.gnu.org/software/guile-gnome/ - guile-git separate project https://gitlab.com/guile-git/guile-git - libgccjit separate project https://savannah.nongnu.org/projects/gccjit-guile/ - guile-gnutls at gnutls https://www.gnutls.org/manual/gnutls-guile.html - zeromq at zeromq http://zeromq.org/bindings:guile-binding - gmp part of guile https://gmplib.org/manual/Language-Bindings.html The majority seems to have chosen to be available as separate project. > 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 dependencies. Bruno ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Libgettextpo wrapper for Guile 2019-05-05 18:45 ` Bruno Haible @ 2019-05-05 23:04 ` amirouche 2019-05-08 14:33 ` Miguel 2019-05-08 14:32 ` Miguel 1 sibling, 1 reply; 7+ messages in thread From: amirouche @ 2019-05-05 23:04 UTC (permalink / raw) To: Bruno Haible; +Cc: guile-devel, Miguel, guile-devel, bug-gettext Hello all! On 2019-05-05 20:45, Bruno Haible wrote: > Hi Miguel, > >> 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. > > How are other Guile bindings organized? > - guile-cairo separate project > https://www.nongnu.org/guile-cairo/ > - guile-gnome separate project > https://www.gnu.org/software/guile-gnome/ > - guile-git separate project > https://gitlab.com/guile-git/guile-git > - libgccjit separate project > https://savannah.nongnu.org/projects/gccjit-guile/ > - guile-gnutls at gnutls > https://www.gnutls.org/manual/gnutls-guile.html > - zeromq at zeromq > http://zeromq.org/bindings:guile-binding > - gmp part of guile > https://gmplib.org/manual/Language-Bindings.html > > The majority seems to have chosen to be available as separate project. > Miguel you decide to host, I can create a repository at source hut so that you don't have to pay (the less evil, most free except you must to host project yourself). Also, I can review you code if you send it to me. Best regards, Amirouche ~ amz3 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Libgettextpo wrapper for Guile 2019-05-05 23:04 ` amirouche @ 2019-05-08 14:33 ` Miguel 0 siblings, 0 replies; 7+ messages in thread From: Miguel @ 2019-05-08 14:33 UTC (permalink / raw) To: amirouche; +Cc: guile-devel, bug-gettext amirouche <amirouche@hypermove.net>: > Hello all! Hello, amirouche! > Miguel you decide to host, I can create a repository at source hut > so that you don't have to pay (the less evil, most free except you > must to host project yourself). After looking other options I decided that Savannah was the best option available, mainly as a ethical/moral point of view without having to provide the service myself. Thank you for your offer anyway. > Also, I can review you code if you send it to me. You can find the latest code here: https://savannah.nongnu.org/task/download.php?file_id=46883 Thank you very much, Miguel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Libgettextpo wrapper for Guile 2019-05-05 18:45 ` Bruno Haible 2019-05-05 23:04 ` amirouche @ 2019-05-08 14:32 ` Miguel 1 sibling, 0 replies; 7+ messages in thread From: Miguel @ 2019-05-08 14:32 UTC (permalink / raw) To: Bruno Haible; +Cc: guile-devel-mXXj517/zsQ, bug-gettext-mXXj517/zsQ (Links at the end for readability.) Bruno Haible <bruno-nWNVUoHt2MvYtjvyW6yDsg@public.gmane.org>: > Hi Miguel, Hi Bruno, After some suggestions made by private email and being suggested in the savannah admission process to integrate it in gettext[1], I gave a second look into the topic, and check the pros and cons more thoroughly. > > 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[2] and a set of clear Scheme idioms is found[3], 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[4]. > How are other Guile bindings organized? > - guile-cairo separate project[5] It seems that all language bindings are separate projects[6]. > - guile-gnome separate project[7] 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[8] Git seems to have all its bindings as separate projects too. > - libgccjit separate project[9] 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 3.0[10]. > - zeromq at zeromq[11] This actually is a separate project if you look into the page. > - guile-gnutls at gnutls[12] > - gmp part of guile[13] 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[14] - texinfo manipulation part of guile[15] - gdb part of gdb[16] - mailutils part of mailutils[17] - make part of make[18] - guile-opengl separate project[19] - guile-parted separate-project[20] - guile-gcrypt separate project[21] > 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[22]. > > 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 > dependencies. 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[23], and gettext already has the code to do the same task. What do you think? Best regards, Miguel [1] https://savannah.nongnu.org/task/index.php?15273 [2] 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. [3] 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 library. [4] 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. [5] https://www.nongnu.org/guile-cairo/ [6] https://cairographics.org/bindings/ [7] https://www.gnu.org/software/guile-gnome/ [8] https://gitlab.com/guile-git/guile-git [9] https://savannah.nongnu.org/projects/gccjit-guile/ [10] http://git.savannah.gnu.org/cgit/guile.git/tree/NEWS [11] http://zeromq.org/bindings:guile-binding [12] https://www.gnutls.org/manual/gnutls-guile.html [13] https://gmplib.org/manual/Language-Bindings.html [14] https://www.gnu.org/software/guile/manual/html_node/Gettext-Support.html [15] https://www.gnu.org/software/guile/manual/html_node/texinfo.html [16] https://sourceware.org/gdb/current/onlinedocs/gdb/Guile.html [17] https://mailutils.org/manual/html_node/guimb.html [18] https://www.gnu.org/software/make/manual/html_node/Guile-Integration.html [19] https://www.gnu.org/software/guile-opengl/ [20] https://gitlab.com/mothacehe/guile-parted [21] https://notabug.org/cwebber/guile-gcrypt [22] https://www.gnu.org/prep/standards/html_node/Source-Language.html [23] https://pypi.org/project/polib/ ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-05-08 14:33 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-05-04 22:49 Libgettextpo wrapper for Guile Miguel [not found] ` <20190505004925.24e650e4-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2019-05-05 13:45 ` Bruno Haible 2019-05-05 16:34 ` Miguel 2019-05-05 18:45 ` Bruno Haible 2019-05-05 23:04 ` amirouche 2019-05-08 14:33 ` Miguel 2019-05-08 14:32 ` Miguel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).