Waldek wrote:
> Well, I was writing specificaly about startup image. V15.65 in
> 'pop/com/mkstartup' among others contains:
>
> $packages/teaching/teaching.p \
> $packages/bhamlib/bhamlib.p \
> $packages/vedutils/vedutils.p \
> $packages/rclib/rclib.p \
> $usepop/pop/lib/lib/prwarning.p \
> $usepop/pop/lib/lib/emacsreadline.p \
> $packages/vedutils/lib/vedscreendown.p \
> $packages/bhamlib/auto/vedsetwindow.p \
> $packages/rclib/auto/rc_control_panel.p \
> $packages/rcmenu/rcmenu.p \
> $packages/vedmail/vedmail.p \
>
> If any of the files above is missing, then 'mkstartup' will
> fail.
When the packages mechanism was created to allow greater flexibility I must
have assumed that for the time being people fetching poplog from Birmingham
would want all the old functionality in pop11 (= basepop11 + startup).
[I can't remember exactly what I was thinking at that time!]
At the same time the directory
$usepop/pop/packages/lib/
allowed new packages to be added to an installed system, or new packages to
be made availble in future installations without being included in
startup.psv
I agree with your aim of providing the option to download and use a
smaller, more focused, poplog tree and making that work well with or
without the packages library, which may not be included in all
installations, and which may include different packages in different
places.
This may require changing several design decisions -- a process you have
already begun!
When you set up a system that could run without the packages directory. I
tried to work out a minimally intrusive way to add the packages for users
who wanted it, with a default replicating the old functionality, but
perhaps the whole thing now needs to be redesigned?
E.g. instead of providing a monolithic packages directory should we make
available a list of packages and a mechanism that allows users to select
the ones to include, and also allows them easily to import packages
developed elsewhere?
We nearly have that at the moment.
The INSTRUCTIONS.txt file now fetched after installation
http://www.cs.bham.ac.uk/research/projects/poplog/V16/INSTRUCTIONS.txt
[still need to replace mechanism for setting up $usepop]
could include a section on how to remove or disable some packages, or add
new local packages, and how to specify which should be in startup.psv, with
(pointers to) instructions for rebuilding the main saved images.
I accept your arguments about the need for more redesign to provide greater
flexibility (plus special instructions for installing the equivalent of the
latest 32 bit Poplog V15.65?)
That raises the question whether that should remain the default, or whether
the default installation should be slimmer. (It's already slimmer insofar
as the latest default does not include motif, whereas V15.65 did.)
Just as we now provide instructions (in INSTRUCTIONS.txt) at the time of
installation for adding motif, we could also provide add instructions for
expanding startup.psv. Then the default could be fairly minimal?
> For V16 'mkstartup' was just as in Sussex version: it
> only loaded 'pop/lib/lib/startup.p' (and 'startup.p' was as
> before). For V16.0001 I moved some position from Birmingham
> 'mkstartup' to 'startup.p'. However, trying to add files
> from list above would lead to build failure if package tree
> is not present. To put it differently, in V16.0001 agrees
> with your text above. V15.65 loaded files from packages
> tree to startup image with two consequences:
>
> - build would fails if package was not present. I discovered
> problem during porting, when my code which worked in
> earlier versions (IIRC V15.53) failed when I tried to use
> 'mkstartup' from V15.65
> - some 'uses ....' are not needed
>
> The second point affects user programs. In some cases
> when Poplog reports undefined operation, user can
> infer need for appropriate 'uses'. Some other cases
> are more nasty: without uses operations are available,
> but work differently.
In general this indicates a need for well defined tailorable mechanisms and
good documentation for users (of various levels of sophistication?)
In the past I have assumed that the default installation should provide a
lot of teaching libraries (code and documentation, with working demos)
especially for pop11. That could now include a copy of or link to your
'book' on pop11 and this site:
http://www.math.uni.wroc.pl/~p-wyk4/pop11_en/
a link to this:
http://www.rosettacode.org/wiki/Category:Pop11
and a link to Hakan Kjellerstrand Pop11/Poplog site:
http://www.hakank.org/poplog/
Others??
I suspect having that documentation easily available via summaries with
links is still a requirement, even if it is never included in the Github
package.
We also need instructions for expert users on how to produce a minimal
system to meet their needs, though I suspect that is not urgent.
> General isssue is how to avoid fragmentation. With flexible
> and customizable system like Poplog users can easily create
> incompatible versions. Incompatiblities may inhibit sharing
> of code... One solution is to have standard base version that
> is accepted by comunity and in code have explicit 'uses' for
> local extentions (or appropriate loader type code which creates
> environment expected by rest of the code).
Plus documentation on information and code available elsewhere on the
internet?
> AFAICS in last
> 20 years Birmingham version de facto served as such standard
> version. But as I wrote, there is technical problem
> with V15.65 (build without package tree), and trying
> to fix this problem introduces incompatibility
I agree with all of that, and what I have been doing recently is mainly
attempting to make it easy for current users to replicate familiar
functionality.
But I agree that the long term objective should allow for a wider range of
interests and uses.
[WH]
> Let me reiterate that I am here concerned only with
> 'startup' image. Other images stacked on 'startup' are
> different story.
>
> > > Another issue are extra commans: doc, help, im, ref, teach
> > > During porting I had to rebuid multiple times and
> > > not having those commands made my work a bit simpler.
> > > So I changed build to avoid making them (and this
> > > wnet to git repo). But if they are expected by users
> > > I can add them back.
[AS]
> > As long as they are available once poplog/pop11 starts up (with similar
> > comments for the other languages) that should suffice.
> >
> > At present this is handled in the directory
> >
> > $usepop/pop/pop
> >
> > which includes, besides basepop11 (hard) links to it with different names,
> > e.g.
> > pop11, clisp, pml, prolog, ved, xved
> >
> > which are all hard links to basepop11.
>
[WH]
> All what changed is that there are less links. More precisly
> newpop no longer creates links to doc, help, im, ref and teach.
> OTOH 'teach teach' in pop11 or ved works as before.
>
> I changed 'pop/src/newpop_options', changing it back to old
> version would give back the links.
Perhaps we can leave it to expert users who want all of those to be shell
commands to define suitable aliases or scripts for themselves?
At present
help lists
does not work, but
pop11 help lists
does work, which I think is fine!
Have to go now...
Aaron
