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,
calling `libapl.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](https://www.sagemath.org/) (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.
>
> 4. put the desired libraries into a tar file
> 5. 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$](mailto: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:
[[email protected]](mailto:[email protected]) of your (eagerly
awaited) replies.
>
> You only need to subscribe:
>
>
> [https://lists.gnu.org/mailman/listinfo/bug-apl](https://lists.gnu.org/mailman/listinfo/bug-apl)
>
I'm a special case : since my (almost) homonym, [Emmanuelle
Charpentier](https://en.wikipedia.org/wiki/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,
--<br>
Emmanuel Charpentier
