Aaron Sloman wrote:
>
> I have been using poplog V16 as my main environment (reading and writing
> email, writing papers, invoking latex, tailoring Ved, invoking linux
> facilities from Ved etc.) and there have been remarkably few problems.
>
> 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;
> I have also been trying to expand my installation and testing instructions
> for people unfamiliar with Poplog, here (work in progress)
>
> http://www.cs.bham.ac.uk/research/projects/poplog/V16/AREADME.html
>
> I've started a temporary location for bug reports:
>
> http://www.cs.bham.ac.uk/research/projects/poplog/V16/known-problems.txt
>
> I'll copy there bug reports posted to pop-forum or sent directly to me.
> I'll include name of submitter unless asked not to.
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 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]
>
> There may be others that I have forgotten about.
>
> Removing them would need a small change change to build_pop2
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.
- 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.
>
> ---
> 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.
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.
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 agree, I'll change my version of your tar file poplog_base6.tar.bz2
> to include them (with the fixed help file).
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.
I intend to keep Github repository up to date. poplog_base?.tar.bz2
was/is mostly an intermediate state from sources to working
system, needed because there were troubles using older Poplog
for bootstrap.
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.
Now, concerning "user tarballs". For me it would be most covenient
if documentation were on Github and you updated it there. 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.
--
Waldek Hebisch
