CoCoA » CoCoA-5

Decision: distrubution with two executables.
John does the cocoa-5 script
Anna does the release script (and the releases)

An alternative solution is to ask the user to use an install script: this script could then determine which executable works on the current platform, and then "install" just that one (here "install" could probably mean "make a symbolic link (from CoCoAInterpreter to the actual version which works).

A disadvantage of checking which version to use each CoCoA is started is that it could become "costly" to start cocoa:
(1) try executable 1 with no packages and empty input (to see if dynamic linking works)
(2) ditto for executable 2...
(3) finally start the working executable properly (i.e. with packages & any user specified input files).

This "check every time" approach might have some advantages: e.g if a missing dynamic library is subsequently installed...

I'm not sure how large the overhead might be: 2 or 3 executables must be started each time CoCoA is used. I do recall one user (Migliore?) wanting to use CoCoA to make thousands of quick, simple computations, starting a new session for each one.

It is not entirely clear to me how to make --packageDir NoPackages work portably.
One solution is to make NoPackages an absolute path, but that means the script has to be changed if moved to elsewhere.
If it is a relative path, then where is it relative to? The dir containing the cocoa5 script, or the "current directory" when cocoa5 was called?

I now think it is probably cleaner/neater to have a new command line option, say --do-nothing, which simply tells CoCoAInterpreter to exit (without trying to read packages or init files). If we do this, what should the option be called?

If --do-nothing is specified then no other args are allowed.

UPDATE: I have made a first impl of --do-nothing; it is faster than --packageDir NoPackages

I have made a first attempt at modifying the start-up script. It took me a lot longer than anticipated :-(

It is hard to produce helpful error mesgs given that so many things could go wrong... :-/

I now have a new cocoa5 script for GNU/linux. I have developed it "blind", so it probably does not work correctly (yet).

I have also realised a disadvantage of specifying readline in the configuration for cocoalib: to make two versions of CoCoAInterpreter with/without readline, we are forced to recompile cocoalib too (even though this is unnecessary). I believe the correct solution is to have two separate configuration procedures for cocoalib and cocoa5 (see #933).

I have tried testing with the current public version of CoCoA-5 for linux: it fails because the interpreter does not recognise --do-nothing.
Anyway, the error mesgs now seem reasonable. Hope to check in soon.

Here is a little doc (where should it really go?)

• there is just 1 file called CoCoAInterpreter (which must be executable)
• there are exactly 2 files, called CoCoAInterpreter-with-readline and CoCoAInterpreter-without-readline

The script checks how many files are in bin/: error if fewer than 1 or more than 2.
Then it checks that one of the two expected situations is actually present (o/w error).
If there are two files, it tries first with readline and if that does not start then it tries without.

I wonder if we will test it with the imminent interim release?

Closing after 1 year in feedback.
The only thing left is to remember to make 2 executables (if we want to do that).