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.
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).
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 packaging).
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,
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, 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 :
o
service processors, such as various SQL interface to databases
(sqlite3, mysql, postgresql, etc...)
o
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$ 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
<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,
--
Emmanuel Charpentier
