On Sat, Feb 08, 2020 at 10:42:09AM +0000, Aaron Sloman wrote:
> Waldek,
> 
> Thanks for looking at this.
> 
> > > Some input processing invoked from the linux command line works as 
> > > expected
> > > in V16, e.g.
> > >
> > >    % pop11 :"charin()=>"
> > >    : A
> > >    ** 65
> > >    % pop11 :"charin()=>"
> > >    : 0
> > >    ** 48
> > >
> > > But not this:
> > >
> > >    % pop11 :"readline()=>"
> > >
> > > prints the end of stream indicator:
> > >
> > >     ** <termin>
> >
> > I do not understand why you think that you should get anything different?
> 
> > 'readline()' reads from proglist and proglist is read from the same
> > string as 'readline()=>'.  So we are at the end of input and '<termin>'
> > is correct.
> 
> I think things are far more complex, in order to support various kinds of
> functionality summarised above. Some the requirements are spelled out in
> REF SYSTEM.

Well, 'syssetup' (in 'syssetup.p') looks a 'arglist' and when it
is nonempty and first word in not on shortlist of magic words,
then it chains to SS_POPARG1 procedure of current subsystem
(that is pop11).  Corresponding procedure is 'Pop11_poparg1' and
is calls 'sys_process_poparg1'.  'sys_process_poparg1' calls
'pop11_compile' with input coming from string.  AFAICS V16
is doing exactly what sources say it should be doing.  Try

corepop :"readline()=>"

corepop :"readline()=>1 + 1"

V15 corepop gives me results agreeing with sources, that is
<termin> in first case and '[1 + 1]' in the second case.

Now, binary you use may have overriden startup procedures.  AFAICS
there are only few places where it can happen:  'setpop'
(unlikely, as this is responsible for a lot of low-level stuff),
'Poplog_Main', 'syssetup', 'sys_process_poparg1' and
'Apply_ss_procedure' (would be creasy...).  'Pop11_poparg1'
is constant, so no override here is possible.

Of course if subsystem is different than pop11, than something
else can happen, I did not check.

Anyway, main point is that to make progress on 'popracer' we
need to find which _extension_ is resposible for changed
(compared to 'corepop') behaviour and why this extension
does not work in V16 (not inculded???, some bug preventing it
from working???).

> I guess most people reading this will not have V15.65. If anone wants to
> get involved it can be obtained here:
> 
>     http://www.cs.bham.ac.uk/research/projects/poplog/latest-poplog
> 
> using the pre-linked poplog (because linking V15 basepop11 no longer works
> in recent versions of linux).

There is an extra problem: V15.65 does _not_ work on old 32-bit
systems (the only 32-bit ones that I have).  It needs post 2007
(or maybe 2008) ld.so, otherwise it crashes.  It well-known
incompatibilty: any program linked without

--hash-style=both

option to linker will crash on older systems.
 
-- 
                              Waldek Hebisch

Reply via email to