REDUCE / Bugs / #144 Common Lisp Reduce 6286 compilation problems

ERROR! The markdown supplied could not be parsed correctly. Did you forget to surround a code snippet with "~~~~"?

> ------------------------------------------------------------
>
> Error 1.
> During compilation one gets the following SBCL error/warning
> The file "pasfbqbb.red" contains a duplicate local variable "m" in the procedure "pasf_BQsubfof1":
>   begin scalar op, v, m, b, al, asgal, newv, allvl, m;
                         ^                             ^
> Renaming one fo the two "m" variables resolves the problem.
Looks like a straightforward glitch there and the authors of that package 
can sort it out easily for you!
> I have a question: is it a normal behaviour, for the psl and/or csl 
> compilers, not complaining about duplicate local varisbles?
Yes. And there are MANY other things that it could be desirable to 
generate warnings about where they do not! Indeed not giving warnings is 
normal behaviour in almost all but the most modern compilers I think you 
will find. These days many developers may like to set things so that "mere 
warnings" are treated as errors and cause compilation to abort so that 
they can re-work their code so it compiles fully cleanly. With the number 
of lines of historical code from many authors that make up Reduce that 
might be a slightly enthusiastic stance to take.

> ------------------------------------------------------------
>
> Error 1.
>
> Compilation with CLISP fails with the following message.
>
> ***** Building bootstrap REDUCE failed
>
> which, according to the log file "bootstrap.blg", is due to
> +++ Reading file: $reduce/packages/arith/paraset.red
> WARNING: in |FIND\!NFPD| : variable Z is assigned but not read
> find!nfpd
> WARNING: in |FIND\!NBFPD| : variable Z is assigned but not read
There are comments in the code that explain where z was used in the past 
before Reduce felt it could properly assume that floationg point 
arithmetic would always be IEEE style - which is its current stance. I am
now deleting the historic code fragment rather than just commenting it 
out.
> WARNING: in |\!MFEFIX| : Function ROUNDCONSTANTS is not defined
> *** - COMMON-LISP:/: floating point underflow
These days (well for some years now) Reduce expects the floating point 
supplied to the underlying Lisp to be IEEE double precision and it likes 
to be able to see overflow etc lead to NaNs, so floating pointr underflow 
in single precision floats is something it sees as belonging in the stone 
age.

> Error 3.
>
> Compilation with ABCL fails.
>
> Building bootstrap REDUCE hangs and fails.
> The last lines of the log file "bootstrap.blg", are
>
> upd-fasl1 module2-to-file nil nil
> Time to build bootstrap REDUCE: 15.887 secs
> Heap left: 0 bytes
++++ is this the system running out of memory?

> Error loading ~/sw/reduce-algebra/work/6286/common-lisp/bootstrap.lisp 
at line 152 (offset 4783)
> <THREAD "interpreter" {35A3A1FD}>: Debugger invoked on condition of type MISSING-COMPONENT
>  Component "bootstrap" not found
> ------------------------------------------------------------
>
> Comments
There are about the build process itself and so I do not know enough to 
respond, but comments and suggestions from you are helpful so keep them 
coming. Do you have a special reason for needing to use a version hosted 
on a Common Lisp rather than one of the systems that Reduce was developed 
on and that most testing and use is on?

Arthur

ERROR! The markdown supplied could not be parsed correctly. Did you forget to surround a code snippet with "~~~~"?

Hi, Arthur 

> Il giorno 24 apr 2022, alle ore 10:19, Arthur Norman <arthurcnorman@users.sourceforge.net> ha scritto:
> > ------------------------------------------------------------
> 
> >
> > Error 1.
> > During compilation one gets the following SBCL error/warning
> > The file "pasfbqbb.red" contains a duplicate local variable "m" in the procedure "pasf_BQsubfof1":
> >   begin scalar op, v, m, b, al, asgal, newv, allvl, m;
>                          ^                             ^
> > Renaming one fo the two "m" variables resolves the problem.
> Looks like a straightforward glitch there and the authors of that package 
> can sort it out easily for you!
> > I have a question: is it a normal behaviour, for the psl and/or csl 
> > compilers, not complaining about duplicate local varisbles?
> Yes. And there are MANY other things that it could be desirable to 
> generate warnings about where they do not! Indeed not giving warnings is 
> normal behaviour in almost all but the most modern compilers I think you 
> will find. These days many developers may like to set things so that "mere 
> warnings" are treated as errors and cause compilation to abort so that 
> they can re-work their code so it compiles fully cleanly. With the number 
> of lines of historical code from many authors that make up Reduce that 
> might be a slightly enthusiastic stance to take.
> 
> > ------------------------------------------------------------
> >
> > Error 1.
> >
> > Compilation with CLISP fails with the following message.
> >
> > ***** Building bootstrap REDUCE failed
> >
> > which, according to the log file "bootstrap.blg", is due to
> > +++ Reading file: $reduce/packages/arith/paraset.red
> > WARNING: in |FIND\!NFPD| : variable Z is assigned but not read
> > find!nfpd
> > WARNING: in |FIND\!NBFPD| : variable Z is assigned but not read
> There are comments in the code that explain where z was used in the past 
> before Reduce felt it could properly assume that floationg point 
> arithmetic would always be IEEE style - which is its current stance. I am
> now deleting the historic code fragment rather than just commenting it 
> out.
> > WARNING: in |\!MFEFIX| : Function ROUNDCONSTANTS is not defined
> > *** - COMMON-LISP:/: floating point underflow
> These days (well for some years now) Reduce expects the floating point 
> supplied to the underlying Lisp to be IEEE double precision and it likes 
> to be able to see overflow etc lead to NaNs, so floating pointr underflow 
> in single precision floats is something it sees as belonging in the stone 
> age.
> 
> > Error 3.
> >
> > Compilation with ABCL fails.
> >
> > Building bootstrap REDUCE hangs and fails.
> > The last lines of the log file "bootstrap.blg", are
> >
> > upd-fasl1 module2-to-file nil nil
> > Time to build bootstrap REDUCE: 15.887 secs
> > Heap left: 0 bytes
> ++++ is this the system running out of memory?
> 
> > Error loading ~/sw/reduce-algebra/work/6286/common-lisp/bootstrap.lisp 
> at line 152 (offset 4783)
> > <THREAD "interpreter" {35A3A1FD}>: Debugger invoked on condition of type MISSING-COMPONENT
> >  Component "bootstrap" not found
> > ------------------------------------------------------------
> >
> > Comments
> There are about the build process itself and so I do not know enough to 
> respond, but comments and suggestions from you are helpful so keep them 
> coming. Do you have a special reason for needing to use a version hosted 
> on a Common Lisp rather than one of the systems that Reduce was developed 
> on and that most testing and use is on?
No, I don't have any special reason. In case I have to use Reduce I'm going to use either psl-reduce or csl-reduce since they are definitely faster than any Common Lisp version of Reduce. 
For example, I use psl-reduce to compile Sheep, Classi and Stensor on my X86-64 Macs. On M1 Macs I use csl-reduce because psl reduce has not been ported to M1 Macs, yet.

When I started using Reduce on a Macintosh the only possibility was to use Macintosh Common Lisp to compile the Common Lisp distribution sold by Rand Co. I bought the tape and I was able to modify the distribution files in order to have a working copy of cl-reduce  on my Macintosh Plus. Later I bought Codemist Reduce version 3.5, 3.6, 3.7 and 3.8. Now I have a working copy of cl-reduce 3.4 and cl-reduce 3.6 which are based on the files of the distribution tape.

> Arthur
> 

Best regards
Marco

alternate

Francis Wright - 2022-04-24

status: open --> accepted

assigned_to: Francis Wright

Group: -->
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Marco Ferraris - 2022-04-25
  
  Hi, Francis
  
  I compiled r6239 and, with some modification you’ll find in the enclosed files, it works fine with SBCL 2.2.2 and CCL64 1.12.1.
  
  Il giorno 24 apr 2022, alle ore 17:30, Francis Wright fjwright@users.sourceforge.net ha scritto:
  
  status: open --> accepted
  
  assigned_to: Francis Wright
  
  Group: -->
  
  Comment:
  
  Hi, Marco
  
  Thanks for your report. It's useful to know what happens on macOS, which I don't use.
  
  I hope I have fixed the pasf error that upset SBCL, and that Arthur has fixed the paraset error that upset CLISP, but I have not seen that error myself.
  
  As I explain in the README file, support for ABCL is incomplete. I am currently working on it. The problem is that ABCL does not provide a way to preserve a Lisp image in the way that all other Lisps I have used do. An approach using ASDF might work and is what I am currently looking at. If that can be made to work then I think it will require a pure Lisp build setup, which is one reason why I introduced bootstrap.lisp instead of bootstrap.sh. (Another reason is that bootstrap.sh duplicated a lot of code in build.sh.)
  
  Why is the bash test [ -z "$reduce" ] better than [ ! -v reduce ] on macOS?
  
  I prefer using if [ -z "$reduce" ]; then ... because using if [ ! -v reduce ]; then … I get the following warning
  
  ./build.sh: line 71: [: -v: unary operator expected
  
  and if the variable reduce is not already defined then it will not be defined and compilation fails.
  
  Using instead export reduce=.; ./build.sh -l sbcl I get again the warning
  
  ./build.sh: line 71: [: -v: unary operator expected
  
  but compilation succeeds.
  
  Compilation of r6239 under GNU CLISP 2.49.92 always fails, while trying to compile bootstrap.mem, with the error message I already reported.
  
  I do not understand why using the combination bootstrap.sh, build.red and build.sh from r6283 the compilation under CLISP succeeds.
  
  I was thinking about adding support for CCL64 (although not on macOS). You're welcome to check in your support code, but since you are using the old build setup it might be easier if you send your files to me and I'll try to merge them into my current build setup.
  
  In order to compile all the stuff under CCL64 1.12.1 I had to modify I had to modify the following files:
  build.sh, bootstrap.lisp, sl-on-cl.lisp, remake.red and provide an executable file redccl.
  Francis
  
  Marco
  
  alternate
  
  bootstrap.lisp
  
  build.sh
  
  redccl
  
  remake.red
  
  sl-on-cl.lisp
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Francis Wright - 2022-04-24

Hi, Marco

Thanks for your report. It's useful to know what happens on macOS, which I don't use.

I hope I have fixed the pasf error that upset SBCL, and that Arthur has fixed the paraset error that upset CLISP, but I have not seen that error myself.

As I explain in the README file, support for ABCL is incomplete. I am currently working on it. The problem is that ABCL does not provide a way to preserve a Lisp image in the way that all other Lisps I have used do. An approach using ASDF might work and is what I am currently looking at. If that can be made to work then I think it will require a pure Lisp build setup, which is one reason why I introduced bootstrap.lisp instead of bootstrap.sh. (Another reason is that bootstrap.sh duplicated a lot of code in build.sh.)

Why is the bash test [ -z "$reduce" ] better than [ ! -v reduce ] on macOS?

I was thinking about adding support for CCL64 (although not on macOS). You're welcome to check in your support code, but since you are using the old build setup it might be easier if you send your files to me and I'll try to merge them into my current build setup.

Francis

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Francis Wright - 2022-05-18

status: accepted --> closed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Francis Wright - 2022-05-18

Marco has advised me that:

The r6304 version of psl reduce, csl reduce, sbcl reduce, clisp reduce and ccl reduce compile without problems under X86_64 macOS Catalina version 10.15.7.

The r6304 version of csl reduce, sbcl reduce and ccl reduce compile without problems under M1 macOS Monterey v12.3.1.

Building REDUCE on ABCL is work in progress and not yet fully supported, so I think it is fair to close this bug report.

Francis
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Common Lisp Reduce 6286 compilation problems

A Portable General-Purpose Computer Algebra System

Group

Searches

Help

#144 Common Lisp Reduce 6286 compilation problems

Discussion