Waldek
Thanks very much for your rapid and helpful response.
> > A new bug-report is below: sys_host_name no longer works.
>
> Sorry, that was my inattention during port. Patch (applied in
> Github repository):
>
> --- ../trunk/pop/src/sys_host_name.p 2019-02-19 12:41:16.000000000 +0000
> +++ pop/src/sys_host_name.p 2019-12-16 17:49:10.841540819 +0000
> @@ -22,7 +22,7 @@
> lvars _offs;
> lstackmem stackbuff _obuf;
> lconstant _size = _:SIZEOF(stackbuff);
> - if _neg(_extern[SE] gethostname(_obuf, _size)) then
> + if _nonneg(_extern[SE] gethostname(_obuf, _size)) then
> if (_locc(_obuf, @@(b)[_size], _0) ->> _offs) == _-1 then
> @@(b)[_size] -> _offs
> endif;
Thanks very much. Because I use poplog on several different systems with
different directory names, not all controlled by me, my utility programs
need to use sys_host_name to set $usepop when starting up.
I installed your patch and then re-ran
build_pop2
on the three different machines I've been using. (Actually four machines,
but two of the departmental machines (running Centos 7.7 and SL6) use the
same filestore.)
On my mini laptop (Clevo rebranded) it took just under 60 seconds to
recompile everything and rebuild all saved images in $usepop/pop/pop and
$usepop/pop/lib/psv
[I can recall a time (late 1980s I think) when it took about 15 minutes
just to rebuild the lisp saved image.]
Until recently I would have used the pgcomp pglibr and pglink scripts
which reduce the time to rebuild but complicates the system.
Anyhow, I understand your point about Github, although I have never used it
for software development. I once -- over ten years ago -- used it, with
colleagues, to produce a book reporting on a multi-site collaborative
project.
[WH]
> Just a little remark: Github has machinery for bug reports. I am not
> sure if you or other folks here like it, but it is there (click on
> Issues on Github project page) and it automates several things
> that otherwise requires manual work.
I'll investigate and use that in future (if there are any more bugs!),
perhaps with a note to this list, for information.
If poplog ever becomes more widely used again it may need a dual layer
system for bug-reports for different sorts of user e.g. reporting to a
local expert who then could use github. Something like that happens in
universities and other organisations using imported software.
[AS]
> > I also propose that all the *.o and *.w files produced during installation
> > should be removed, saving about 10MB from the installed system.
> >
> > They are in
> > $usepop/pop/src/*.[ow]
> > $usepop/pop/ved/src/*.[ow]
> > $usepop/pop/x/src/*.[ow]
> > ....
[WH]
> Well:
> - during developement in some (admitedly rare) cases the .o files
> are useful for debugging.
> - I have used them in ARM port: .o files created on PC were transfered
> to ARM and linked there. This is still useful, as compiling
> on PC is faster.
Yes I was thinking only that 'ordinary' end-users would never need them.
But perhaps in view of amounts of file space available on modern machines
saving a few megabytes would be insignificant for most users?
> - idealy Poplog would build in 'make' style, rebuilding only needed
> parts based on dependencies. removing files tend to break
> dependencies.
> - clearly *.[ow] are not needed for normal use.
>
> So I view removal of .[ow] files as part of installation, but
> done after build.
Agreed. That's what I had in mind. All the information needed by the system
is in the .obj files.
[AS]
> > I've also updated help message.login, to give the right version of poplog
> > (v16, not v15.65)
> > $usepop/pop/help/message.login
> >
> > This is one of the documentation files not included in Waldek's package,
> > but available here for download and installation
> > http://www.cs.bham.ac.uk/research/projects/poplog/V16/docs.tar.bz2
> > doc help ref teach files.
> >
> > Waldek, I suggest that these files should be added to your package.
[WH]
> Well, there is question what is best way to handle merge (see
> below). Also, my idea was to go trough documentation (here and
> below I mean by this help, ref and teach files (and not other
> documentation)) and remove clearly obsolete/inapplicable parts.
I agree that that is desirable -- but it's a huge task as there is so much.
A possible strategy would be to maintain an archive that is not distributed
and then go through the system purging everything that appears to be out of
date, and then later re-install anything from the archive that turns out to
be necessary.
[WH]
> Realistically I do not have time to do thorough cleanup, but at
> least I think that it possible to quickly remove about 5% of
> documentation (like old news files, docs about removed subsystems
> etc) simultanousy reducing volume and improving quality. However,
> I do not want to do this alone, without advice/agreement from
> experienced Poplog folks, especially you.
If you really have time to produce a candidate list for removal I would be
willing to (quickly) check all items in the list. But I won't be surprised
if you don't have time!
[AS]
> > If you agree, I'll change my version of your tar file poplog_base6.tar.bz2
> > to include them (with the fixed help file).
>
[WH]
> Well, I think that is important to have single current version of
> Poplog. poplog_base6.tar.bz2 on my site is basically a copy of
> Github from July 14 + files not in repository needed for build.
OK I won't change anything that comes from you, though to simplify
instructions for users who want to fetch poplog with the Birmingham
extensions (e.g. the packages directory) I'll use your tar file, but in my
documentation use a link to it without a version number, so that
documentation here doesn't have to change for people fetching your system
and our extensions.
I think that deals with this point:
[WH]
> Now, documentation should be included in user system, but since
> you did most recent documentation work, I wanted to avoid making
> conflicting changes. So I skipped documentation directores
> with intent that adding them from your version is easier than
> merging possibly diverging versions.
However there is one thing that I think would help all users insofar as
there are various scripts that include $usepop to refer to the root of the
poplog tree: currently your poplog_base directory, which can have different
locations in different installations. E.g. on a departmental file store
individual users may not be able put poplog in /usr or /usr/local
directories.
So I was thinking of adding a small script to be run in the poplog_base
directory that would create a file called usepop.txt whose sole contents
would be the path name of usepop (created from output of 'pwd').
Then copies of that file could be used to construct tcsh or bash scripts
that users can source in login or other files to set $usepop as an
environment variable accessed in various utilities. (There's probably a
more elegant way to do this.)
> Now, concerning "user tarballs". For me it would be most covenient
> if documentation were on Github and you updated it there.
When I've caught up with a serious paper backlog I'll look at github
documentation to find out how I can provide items that would be
automatically included in the tar files you create.
That would solve this problem:
[WH]
> However, if you prefer as before to directly work with files and
> directories and create distribution tarball that way, that is fine too. If
> you want me to put documentation on Github and forward changes there I can
> do this. That way documentation would be automatically included in any
> future "base" tarball. If documentation is not on Github, it would be
> somewhat awkward for me to add it each time when I create new "base"
> tarball.
Any existing poplog users should be able easily to combine files from
github and the birmingham site.
For novices (and my own use) I'll continue to provide a download option
from Birmingham that combines your package with the missing documentation
files and the 'packages' directory -- until you tell me that some of that
is no longer necessary because it's on github.
Instead of combining everything in a birmingham tarball I'll create a
script that fetches yours and also my additions, and then installs
everything.
Is there a web link that will always get the latest poplog tar package
created on github? I can then use that, instead of depending on the version
on your personal web site. (Perhaps the answer is 'pull requests' -- I'll
try that later.)
Aaron
