Hi, Jörgen ! Le jeudi 18 mai 2023 à 17:17 +0200, Dr. Jürgen Sauermann a écrit : > Hi Emmanuel, > > I believe your efficiency formula is incorrect. > > when I said: > > Au contraire. It merely moves the work from the user to the > package maintainer, and the work for the maintainer is bigger > than the work for the user. > > I did not mean that the work moved from the user to the maintainer > is essentially the same for both. After maintaining GNU APL for more > than > 10 years I can tell you that saving 1 minute per user in the build > system can > easily take weeks for the maintainer.
That, assuming my initial estimate, would put a threshold of about ×/7 24 60 = 10080 Gnu APL users to justify maintainance. Worldwide, that's not much... But I think that the kind of restructuring I had in mind has probably a steeper bill... > > My computation would be this: > > 1. from the feedback on bug-apl@gnu.org I would assume that there are > less that 10 libapl users in this world (most use the GNU APL > interpreter). That's where we differ : what I had in mind was putting libapl at the *core* of the package, the interpreter being but one ppplication using that core. Therefore making a libapl user af all and any gnu-apl user... Under* your* assumption, the rest of your reasoning looks perfec correct to me. > 2. running configure --with-libapl ; make ; sudo make install > takes less than 2 minutes. > > 3. This amounts to a total of 20 minutes for all users. > > 4. Your proposed packaging scheme will take 20 hours of my time > (at least - I am not at all familiar with Debian packagintly. > > 5. Apart from that, GNU APL handles the presence or non-presence > of a package in the source code. For example ⎕FFT will produce a > SYNTAX ERROR, generate the )MORE command information related > to the SYNTAX ERROR, etc. if libfftw3 is missing. I severely doubt > that > such fine-tuning can be managed with package managing alone, at > least not in 20 hours. > > 5a. Debian would simply fetch libfftw3 if missing. However, I had > several > cases in the past where the automatic loading of packages crashed > my > entire machine badly (the last event of that sort was only a few > weeks ago, > and I still have not fully recovered from that crash). I therefore > want > GNU APL to be as little intrusive as possible, That's interesting ! Did you report this to Debian ? This might reveal a *Debian* bug... What I had in mind was the work necessary to compensate for the introduction *in the system directories* of libraries unknown to the package management system (apt, friends, cousins, nephews twice removed and other distant relatives :-). In >20 years of Debian use, I became wary of messing with this holy mafia... Intrducing unknown libraries implies that manual maintainance operations *have* to be done at each change of configuration of the APL packages *or change in the client programs configuration !* The latter may become a pain... Sincerely, -- Emmanuel Charpentier > Best Regards, > Jürgen > > > On 5/17/23 13:29, Emmanuel Charpentier wrote: > > > > > Partial answer to soime of your points (most of them being well > > taken ! ). More later... > > Le mardi 16 mai 2023 à 13:45 +0200, Dr. Jürgen Sauermann a écrit : > > > > > Hi Emmanue; > > > On 5/15/23 23:23, Emmanuel Charpentier wrote: > > > > > Dear list, > > > > > > > > > after a 37 years (!) hiatus, I have the opportunity to come > > > > back to APL. Gnu apl appears to be the easiest way to do that, > > > > at least partially due to emacs' gnu-apl-mode package, which > > > > appears to be a great interface. > > > Thank you very much for your interest in GNU APL. > > > > > > > However, I wondered why the Debian package distributed by Gnu > > > > comes without support for libapl.so and lib_gnu_apl.so > > > > libraries,which would allow to use APL from other interface. > > > Actually GNU APL has 8 at least primary build options (see the > > > script > > > build/build_all line 309) : > > > configs="standard develop tar git libxcb rational \ > > > libapl parallel_bench erlang python" > > > The most common options are standard (the interpreter) and > > > libapl. > > > Each of these options has maybe 10 or so variants which differ > > > depending on which libraries are installed on the build system. > > > And then there are 3 or more packaging systems (debian, rpm, > > > yum, ...). > > > And finally there are different platforms (i386, amd64, arm, > > > apple, ...). > > > So in order to be fair we would need to produce several millions > > > of > > > binary packages. > > The same is true for most development environments. I'll take the > > example of R in Debian : > > There is : > > * a base package r-base-core, which contains the very core of the > > interpreter ; > > * the basic interpreter, r-base, which uses r-base-core, and therefore > > depends on it : > > * about 138 packages (in Debian testing) depending on r-base including > > various documentation presentation packagings), therefore indirectly > > depending on r-base-core ; > > * 1121 packages wrapping CRAN R packages, all depending more or less > > directly from r-base[-core]? and possibly other. > > The dependencies avoid Debian to have to produce 2^159 packages... > > Furthermore, other packages (e. g. ess might recommend or suggest R > > packages and/or other R-related packages. > > I thought that such a combination could be created for APL > > packages. That would be : > > * gnu-apl-base-core : essentially libapl.so, containing the core of > > the interpreter ; > > * gnu-apl-base: the "vanilla" user interface, essentially emulating a > > 70's terminal, callinglibapl.so` functions for all the APL > > computations ; > > * various gnu-apl-xxx wrappers, depending of either gnu-apl-core or > > gnu-apl-base and calling (directly or not) libapl.so for APL > > computation, allowing APL to interface with either : service > > processors, such as various SQL interface to databases (sqlite3, > > mysql, postgresql, etc...)interface to other languages/services (C, > > Python, erlang, possibly emacs, etc...).Each of them might depend > > also on distribution-specific packages guatranteeing a known > > configuration for each of them. For example, gnu-apl-python could > > depend on gnu-APL-base-core and python3, as well as any python3-xxx > > packages providing a useful service. > > These dependencies avoid the necessity to create a zillion packages > > representing the various combinations you decsribed. In other > > words, gnu-apl-base-core does nothing by itself but enables other > > functionalities without duplication. > > I suppose that the same can be done in rpm and yum packaging > > systems. > > [ Hypothetical Debian gnu-apl package : Snip... ] > > > > > > > > > Furthermore, keeping a packaged version of APL makes its > > > > maintenance much easier. > > > > > Au contraire. It merely moves the work from the user to the > > > package maintainer, and the work for the maintainer is bigger > > > than the work for the user. > > That's the point ;-)... Don't yell too fast : > > This restructuration is indeed more work (say W_m) for one (or n) > > maintainer(s), and less work (W_u) for any of the N users. > > This is efficient if W_m/W_u≤N/n. > > In other words, managing these dependencies is worthy if you > > believe that "easy management" will attract more potential APL > > users... > > In (yet) other words, that's an investment. > > This restructuration might also have long-term benefits in terms of > > cleanliness of the code v=base, but I'll refrain to exress any > > opinion about this : while I'm (relatively) competent enough in C > > to be able to fix a bung in a lbrary, my C++ is rudimentary to the > > extreme. For about 30 years, I've worked almost exclusively with > > higher order languages, such as R, perl, bash, and (more recently) > > Python and Sage (throw in enough emacs-lisp to survive heavy daily > > usage of emacs...), and that's no happenstance... > > > > > > > > > So I'm looking for hints and advice on how to recompile and > > > > repackage APL for Debian(-like) systems with libraries support > > > > (I am aware that this possibly could result in the creation of > > > > distinct packages, at least for lib_gnu_apl.so : libapl.so > > > > could be part of the main apl package, where the binary apl > > > > could be a user front end calling it for computation). > > > This should be quite simple: > > > 1. ./configure GNU APL to build libapl (see README-2-configure). > > > 2. make > > > 3. sudo make install > > > This should have created some /usr/local/lib/apl/libapl.* (static > > > library libapl.a and/or dynamic library libapl.so; the exact > > > names > > > depend on your platform. > > > 1. put the desired libraries into a tar file > > > 2. convert the tar file into a deb file (e.g. dpkg-buildpackage). > > > After all, a deb file is simply an ar archive that contains a tar > > > archive and some meta information (control.tar.zst, you may > > > use debian/* for a start): > > > eedjsa@server68:~/apl-1.8/debian_tmp$ ar tvf apl_1.8-1_amd64.deb > > > rw-r--r-- 0/0 4 Jan 4 13:14 2014 debian-binary > > > rw-r--r-- 0/0 5162 Jan 4 13:14 2014 control.tar.zst > > > rw-r--r-- 0/0 2973074 Jan 4 13:14 2014 data.tar.zst > > I need to experiment with the Debian build package before answering > > this. > > > > > > > > > Secondary question : it appears that this part of Ubuntu, but > > > > not of Debian. Do you know why ? > > > See above. Ubuntu is Debian based but also includes non-Debian > > > packages, Some Ubuntus include GNU APL, some do not. > > > > > > > BTW : I'm not (yet) on the list, so I would appreciate a Cc: > > > > emm.charpent...@free.fr of your (eagerly awaited) replies. > > > You only need to subscribe: > > > https://lists.gnu.org/mailman/listinfo/bug-apl > > I'm a special case : since my (almost) homonym, Emmanuelle > > Charpentier was awarded a Nobel prize, my mail feeds (especially > > the professional ones) are flooded with spam. I tend to be > > extremely cautious about subscribing to mailing lists... > > Sincerely, > > -- > > Emmanuel Charpentier >
