Thanks Waldek,
> AFAICS current system is inefficient, inflexible and hard to
> maintain. Concerning inflexible: there are many points
> which can _theoretically_ be used to change Poplog behaviour.
> In practice choosing wrong point leads to more or less
> wrong behaviour. Scattered and hidden dependencies make
> it hard to find correct change point.
On reflection, especially noticing my own difficulties in remembering all
the options as I get older, I think you are right.
Some of the original design was chosen because computers were so slow. I
think I can remember a time when it took several minutes to compile the
common lisp subsystem. In that situation, having saved images made sense.
But I can now type pop11, then 'uses clisp' or 'uses prolog' or 'uses
pml' and it's all compiled in less than a second (slowed down by too much
print out, really needed only for debugging?).
On the PC I am using, bought in 2011, running fedora 29:
Intel Core i3 Processor i3-2100 3.10GHz, Dual Core with 3MB Cache
Common lisp compiles in less than a second (startng from pop11).
Perhaps, for a start, any complications due to command line processing
involving use of saved images could be removed?
So the option to specify a saved image in the pop11 command line is no
longer necessary for those cases. For more complex applications that really
need pre-built saved images a new simplified startup mechanism might
suffice.
Could the decision whether to include motif also be taken when you start a
minimal basepop11, or does that have to be statically pre-linked, as now?
I suppose removing or simplifying the command line options (e.g. allowing
only a specified file to be compiled) would also make things simpler (e.g.
removing one of the contexts where readline now has to work).
Another factor that used to be important has now disappeared: in the early
days (1980s on) poplog was often used by multiple users on a time-shared
server who had different startup needs (e.g. with or without prolog, lisp,
etc). Reducing the load caused by multiple users starting up is no longer
necessary.
There may be other kinds of streamlining -- as long as they don't rule out
satisfying the needs of a subset of users, just satisfying them in a
different way.
I still haven't had time to work out whether the popracer problem results
from a bad non-portable design in popracer, or whether there really is
something missing in the startup mechanisms.
I've just seen Steve's message.
> Years ago I wrote a little program that would take a description of the
> environment variables and their defaults and generated a launcher
> program in C. This made everything much faster and much simpler to
> maintain.
And presumably it supports the needs of a variety of users at different
levels of sophistication (e.g. in a teaching environment)?
> I would be happy to revive this if anyone is interested.
Why not at least circulate the specification, to help everyone understand
what you did?
Making it available for testing would also be useful.
Would a user who used poplog in different ways, e.g. as a developer,
as a tester of systems and as an end-user need different launcher
programs?
Aaron
