From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Miguel Newsgroups: gmane.comp.gnu.gettext.bugs,gmane.lisp.guile.devel Subject: Re: Libgettextpo wrapper for Guile Date: Wed, 8 May 2019 16:32:15 +0200 Message-ID: <20190508163215.7a1ebe48@gmail.com> References: <20190505004925.24e650e4@gmail.com> <16567687.pgqOOCO6U5@omega> <20190505183409.4a2b8a3e@gmail.com> <1721811.yzKoui1vof@omega> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="56418"; mail-complaints-to="usenet@blaine.gmane.org" Cc: guile-devel-mXXj517/zsQ@public.gmane.org, bug-gettext-mXXj517/zsQ@public.gmane.org To: Bruno Haible Original-X-From: bug-gettext-bounces+gcggb-bug-gettext=m.gmane.org-mXXj517/zsQ@public.gmane.org Wed May 08 16:33:00 2019 Return-path: Envelope-to: gcggb-bug-gettext@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hONcv-000EVQ-9P for gcggb-bug-gettext@m.gmane.org; Wed, 08 May 2019 16:32:57 +0200 Original-Received: from localhost ([127.0.0.1]:38225 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hONcu-0005fx-6n for gcggb-bug-gettext@m.gmane.org; Wed, 08 May 2019 10:32:56 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:53980) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hONck-0005eN-0P for bug-gettext-mXXj517/zsQ@public.gmane.org; Wed, 08 May 2019 10:32:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hONci-0004Cs-93 for bug-gettext-mXXj517/zsQ@public.gmane.org; Wed, 08 May 2019 10:32:45 -0400 Original-Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]:39501) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hONcb-00048X-Kh; Wed, 08 May 2019 10:32:39 -0400 Original-Received: by mail-wr1-x42a.google.com with SMTP id v10so2278323wrt.6; Wed, 08 May 2019 07:32:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=gsOj9/7AYA0pbsprirfyP7mp0vZLMiUwFRyNPelVyUI=; b=kt3Lg3Rwxgx0k+YsXSq3R6ufg5Zl97mM5GzRyMMIzH1ZjX8L5Gt48tS/zciUIF7PYJ G9VSPDEapxba/oX9c/Kh59ejZQNA6qvk6/EEwkjvXgHh8067I8ALdhPlCTi7Xour063/ 2t2H75BjZgyA/J7FaLaV2eeKFXzCD4kGV960lVE1pECG8xxoWfYXlVDXhdVUoM127kl3 owaF7Ou19feksDiQ4hXj9GxUfx/GSLigxDtphDuJGtM/tPUeOGVd3SSeb6VmRoXrrdKQ wlIzmCaxoFN4MarxASeVFZbUQt46uDHIFSEBaOrrMMY+jEgPAZ7/14QQapaDUqeKwEL8 bHzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=gsOj9/7AYA0pbsprirfyP7mp0vZLMiUwFRyNPelVyUI=; b=cgOc/WP/yTvTkhV1Tl9OBU7C/AiT1FyJmJb88zdTd6xSwlo0wECmMI3Dfny4qEqpEc 73+qx3GV0aFphFlCeugSGxEGpU3G12ytyKvJ2c5H4VR6IfUI6Cxlz0DFFg120YrYI5/i U2g6SfOmJETmwM6tGjhowuBUqm/uZkQxIMX460V0EKAKDZld0EO5h2k9y9WKpYhUATUB YMw0vg9ZO8TPJRzfpeJyruX4Mwlq26kBD3MXpKpUVR6jbza5yYPVNLg66ZCAr41l7u7O hf+BC5wjHU3ZLHhNyhx7Ct4PAmk2s8XzqM9BtJKx7LITOqk1iAw2Pi0Qj/OpWKmU4D6a 7pkw== X-Gm-Message-State: APjAAAVIuJAKJ9rcuxZKKUZzF8uxWLTb/VuIm2kHOqZxd5M8sIl3ie1Q EEnbM/FGE60vB/dnAFFXjwJ1nfJVfCI= X-Google-Smtp-Source: APXvYqw4y/EqxfRmIzTlcTQyPVFxsVQ3HsVkT2xp/LqNUZrT/uVf1hiRcjQZ13/kTuJE7dutLhbEsQ== X-Received: by 2002:a05:6000:1250:: with SMTP id j16mr3343508wrx.200.1557325948636; Wed, 08 May 2019 07:32:28 -0700 (PDT) Original-Received: from localhost (19.49.134.37.dynamic.jazztel.es. [37.134.49.19]) by smtp.gmail.com with ESMTPSA id v184sm3379330wma.6.2019.05.08.07.32.27 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 08 May 2019 07:32:28 -0700 (PDT) In-Reply-To: <1721811.yzKoui1vof@omega> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::42a X-BeenThere: bug-gettext-mXXj517/zsQ@public.gmane.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Bug reports for GNU gettext List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gettext-bounces+gcggb-bug-gettext=m.gmane.org-mXXj517/zsQ@public.gmane.org Original-Sender: "bug-gettext" Xref: news.gmane.org gmane.comp.gnu.gettext.bugs:2097 gmane.lisp.guile.devel:19904 Archived-At: (Links at the end for readability.) Bruno Haible : > 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/