Compiling r7313 through r7319 CSL Reduce on X86_64 Big Sur fails
Problems with 'showtime' PSL Reduce in macOS
Apologies! Of course r5259 should be replaced by r7258.
Hi Thomas, you are right! When I tested bash version number I did it by using the command bash --version (which corresponds to /opt/local/bin/bash --version) instead of using the command /bin/bash --version. I verified it just now that using #!/opt/local/bin/bash instead of #!/bin/bash as first line in the file r5259 build.sh works fine. Best regards Marco
Building r7257 and r5278 Common Lisp Reduce on macOS fails, because 'bash' does not digest the following commands: [ -v lisp ] || ... if [ -v clean ]; then ... [ -v debug ] ... if [ ! -v reduce ]; then ... if [ ! -v revision ] if [ -v bootstraponly ] if [ -v coreonly ] I changed them as follows [ -n "$lisp" ] || if [ -n "$clean" ]; then [ -n "$debug" ] ... if [ -z "$reduce" ] if [ -z "$revision" ] if [ -n "$bootstraponly" ] if [ -n "$coreonly" ] and there was not any problem in building. The 'bash'...
Hi Francis, I did not understand why you insisted in asking me the result of 'svnversion'. Now I understand why: you want to use the command 'svnversion' to set the value of the variable 'revision!*'. Using 'svnversion' to set the value of the variable 'revision!*' as you do in the (e.g. r7253) file 'build.sh' works only if you are using a 'trunk' directory obtained by downloading reduce-algebra code using the standard checkout command svn checkout svn://svn.code.sf.net/p/reduce-algebra/code/trunk...
On my 'Windows 11 Home (25H2)' X86_64 laptop I tested the old revions of Reduce I found in a backup disk. Compiling and running Common Lisp Reduce I got the following results: i) SBCL Common Lisp Reduce r7204, r7205, r7213, r7246, r7251 REDUCE (Free SBCL version, revision ???), build date 11-Jan-2026 ... 1: bye; This seems to suggest that there is some difference between the 7246 revision I downloaded today and the one you used. ii) CLISP Common Lisp Reduce r7204, r7213, r7246, r7251 REDUCE (Free...
Wrong Common Lisp Reduce header message
Comments on compiling r7222 Reduce on macOS
Compiling r7220 Common lisp Reduce (SBCL, CLISP, CCL) under x86_64 macOS Big Sur v11.7.10 and under M1 macOS Tahoe v26.2 works fine. Marco REMARK. Compiling CCL on M1 Macs works well and produces X86_64 code which can be run under Rosetta 2. The file CCL64 does not recognize the Apple Silicon chip so that one has to modify it by adding the code arm64) OPENMCL_KERNEL=dx86cl64 ;; in the Dawin) case section.
On M1 macOS Tahoe 26.1 and X86_64 macOS Big Sur 11.7.10 I use CCL64 Version 1.13 DarwinX8664 GNU CLISP 2.49.95+ (2024-11-03) On Windows 11 I use CCL64 Version 1.12.1 WindowsX8664 GNU CLISP 2.49.92 (2018-02-18) The function 'ccl::getpid' is defined in the file 'level-1/linux-files.lisp' (lines 918 through 922). Using both Clozure Common Lisp Version 1.12.1 (v1.12.1) WindowsX8664 and Clozure Common Lisp Version 1.13 WindowsX8664 I get ? (apropos 'getpid) GETPID CCL::GETPID, Def: FUNCTION ? (quit) and...
CLISP problem with #_getpid in sl-on-cl.lisp
Hi Francis, compiling both r7207 and r7208 Common Lisp Reduce (on x86_64 macOS 11.7.10 Big Sur) is now OK with SBCL , CCL and CLISP. Marco
Compiling r7205 Common Lisp Reduce fails while using CCL and CLISP
Sorry for the missing 'h' in "While reading ..."
Building SBCL and CCL Common Lisp REDUCE on macOS works fine. However, building with CLISP fails. Wile reading the file "$reduce/packages/arith/rounded.red" one gets a "*** - COMMON-LISP:/: floating point underflow", which is due to the fact that the value of the parameter '*float-print-precision*' in "sl-on-cl.lisp" was reduced from 12 to 6. Setting '*float-print-precision*' to 12 solves the problem. There is a small, and probably irrelevant, problem: while building with CLISP, the files "sl-on-cl.lib"...
Hi, in macOS (both x86_64 Big Sur and M1 Tahoe) the installed version of 'bash' is 3.2 while MacPorts installs 'bash' version 5.2. Accordingly I modified the first line of the file "build.sh" as follows: file 'build.sh', line 1 #!/opt/local/bin/bash instead of #!/bin/bash This way the build process works without errors with SBCL and CLISP. As far as building with CCL is concerned, there are three places where I had to make changes. (1) file 'sl-on-cl.lisp', line 3422, function 'faslout' #-(or CLISP...
Problems compiling Common Lisp Reduce
problem compiling r7160 "gf2.red" in Common Lisp Reduce
Compiling r7138 through r7143 csl-reduce on macOS fails.
Compiling psl-reduce fails.
r6999 CSL-Reduce compilation fails on macOS
Problems compiling r6987 CSL-Reduce on Macintosh
compiling r6985 and r6986 csl-reduce fails on macOS
I'm compiling using macports.
Abnormal number of relinkings on macOS
r6890 psl-reduce compiler error message
Running the universal version of CSL-Reduce fails on macOS
Possible solutions for solving the problem of running universal csl-reduce on x86_64 macOS 11 Big Sur.
Hi Arthur, after installing macOS Sequoia 15.0, I reinstalled from scratch Xcode 16.0 with its CommandLineTools and MacPorts. Then I tried to reinstall the universal ports needed for building Reduce. As you pointed out, installing "ossp-uuid+universal" fails on M1 macOS Sequoia 15.0. This prevents the possibility of installing "Xft2+universal" and "fontconfig+universal" and quite a few other universal ports. As a consequence, the compilation of the universal version of CSL-Reduce fails. I was able...
r6873 and r6874 compilation of CSL-Reduce fails on macOS
Hi Arthur, I have two X86_64 Macs: 1) MacBook Pro (Retina, 15-inch, Mid 2014) with 16 GB of ram and 1 TB SSD 2) iMac (Retina 5K, 27-inch, Late 2014) with 32 GB of ram and 1.12 TB Fusion Drive The last supported os on these machines is macOS Big Sur 11.7.10 and they work perfectly well. As I wrote in my previous message, the last revision of CSL-Reduce which compiles without problems on these machines is revision 6842 and the revision which introduces the problem is revision 6843. As you suggested,...
r6846 CSL-Reduce compilation failure on X86_64 macOS Big Sur 11.7.10
Hi, I tested r6810 common-lisp reduce compilation on x86_64 Windows 10 Home and x86_64 macOS Big Sur 11.7.10. All compilers SBCL, CLISP and CCL work fine and produce usable versions of common-lisp reduce. As far as macOS Sonoma 14.5 on an M1 MacBook Air is concerned, CLISP is missing but compilation with SBCL and CCL work fine. Marco
I think I've found the r6806 source of the problem in the clrend.red file : deleting the line where you commented out the definition of seprp!* solves the problem. The comments % carriage return (^M), % form feed (^L) and % tab key (^I) do not create any problem. Probably the LF character contained in the fourth position of the list seprp!* creates the problem.
As You noted, I followed your suggestion about what upset SBCL. I only tried to solve the problem by following what is written in the first comment of the procedure in the simplest (in my opinion) possible way. I also added a symbolic in front of the procedure definition procedure compute!-prompt!-string(count,level); ""; I don't know whether this is correct or not. What surprises me is why the code (global '(blank cr!* ff!* tab!*)) (setq blank (intern (int2id 32))) % blank (" "). (setq cr!* (intern...
r6806 common-lisp reduce compilation with clisp fails
Almost OK. Now compilation with SBCL 2.2.3 (Windows 10 Home) and SBCL 2.4.4 (macOS x86_64 and arm64) works fine. Compiling with ccl64 works fine, however compiling with GNU CLISP fails while bootstrapping the clreduce!
The same problem is present also when compiling under Cygwin64 (2.931) on a Windows 64 Home pc. OK with clisp 2.49+ adn ccl64 1.12.1 but fails with sbcl 2.2.3. May be it is an sbcl bug and not a reduce bug.
Also on M1 macOS Sonoma 14.5 the behaviour is the same: remaking common-lisp reduce noncore packages fails in revision r6781 and following revisions when compiling with SBCL 2.4.4. Compiling with Clozure Common Lisp Version 1.12.2 works fine.
On x86_64 macOS Big Sur 11.7.10 seems to be restricted to SBCL 2.4.4; compiling with GNU CLISP 2.49.93+ and Clozure Common Lisp Version 1.12.2 works fine.
r6781 common-lisp reduce compilation of noncore packages fails
OK, now it works! Il giorno 15 apr 2024, alle ore 20:06, Rainer Schöpf schoepf@users.sourceforge.net ha scritto: status: open --> closed assigned_to: Rainer Schöpf Group: --> Comment: Hi, you found a bug in the build process on Windows. There are two very similar files compat.b and pslcompat.b where there should have only been only pslcompat.b. In fact, pslcompat.b is the newer version, but both were used leading to the error. I have renamed compat.b to compat-old.b so that it can no longer interfere...
Segmentation Violations in Windows 10 X86_64 r6762 PSL-Reduce
Hi Arthur, what I don't understand is why compilation of CSL Reduce works fine under macOS Sonoma on my MacBook Air M1 while it fails under macOS Big Sur om X86_64 Macs. There are several csl source files in which the identifier 'nullptr' is used. Whether implicitly or explicitly, in all of them, the prolog of the file contain the instructions: include <cstdlib></cstdlib> include <cstddef></cstddef> In flatten.cpp one has only include <cstdlib></cstdlib> and adding include <cstddef></cstddef> solves...
X86_64 Mac OS r6712 CSL reduce.app fails to compile
Compiling both native and universal r6697 csl-reduce on x86_64 macOS Big Sur 11.7.10 and on M1 macOS Sonoma 14.2.1 seems to work fine.
Compilation still fails for r6695 csl-reduce on my macOS Sonoma 14.2.1 MacBook Air M1. This is the relevant part of the log file. ~/sw/reduce-algebra/trunk/csl/cslbase/newallocate.h:966:12: error: use of undeclared identifier 'consFringe'; did you mean 'continue'? while (consFringe < consEnd && ^~~~~~~~~~ continue ~/sw/reduce-algebra/trunk/csl/cslbase/newallocate.h:966:12: error: expected expression ~/sw/reduce-algebra/trunk/csl/cslbase/newallocate.h:968:9: error: use of undeclared identifier 'consFringe'...
r6692 and r6693 csl-reduce compilation fails on MacBook Air M1
ERROR! The markdown supplied could not be parsed correctly. Did you forget to surround a code snippet with "~~~~"?Hi Arthur, I’m attaching the relevant parts of the files bootstrat.blg which show the error that the four compilers (abcl, ccl, clisp, sbcl) while compiling the reduce modules. All of them complain about the fact that ‘bullet’ is not, or cannot be coerced to, a character. Marco ======================================================================================================== ABCL...
OK, now both native and universal Macintosh r6679 CSL reduce.app work well. This happens both on x86_64 (2.8 GHz Intel Core i7 quad-core) macOS Big Sur v11.7.10 and on M1 macOS Sonoma v14.2.1. I compiled also the (1.8 GHz Intel Core i7 quad-core) Cygwin64 Windows 10 Home 64 version of it, which works as expected. Compilation is very slow, probably because of my computer. Once it was faster. Greek letter are concerned, they work as expected. It seems that also the menu sub-items "Font…" "Reset Font"...
Mac OS r6676 CSL reduce.app does not work
Mac OS r6676 CSL reduce.app does not work
Problems after upgrade to macOS 13.6: run.sh not working for universal bilds of csl-reduce.
6589 CSL Rreduce linker error (Windows 10, Cygwin)
r6503 common-lisp compilation fails
Hi Arthur, yesterday evening I downloaded the r6380 release. The compilation (X86_64 under macOS Catalina 10.15.7 and universal under macOS Monterey 12.6) of CSL Reduce succeded without problems. Both applications seem to work as expected. Best regards Marco Il giorno 15 set 2022, alle ore 18:53, Arthur Norman arthurcnorman@users.sourceforge.net ha scritto: The "possible infiite loop" is because clang is much meaner than gcc so does not fill in the tables I wanted with as much generality. I had replaced...
Compiling r6377 CSL Reduce under macOS fails
CSL not launching on M1-Macs
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,...
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...
Common Lisp Reduce 6286 compilation problems
r6233 CSL-Reduce compilation fails
Hi Arthur, Compilation under macOS Catalina 10.15.7 (x86_64-mac_10.15_catalina-darwin19.6.0) is OK. There is still something wrong when trying to compile r6223 cslreduce under macOS Monterey 12.1 (aarch64-apple-darwin21.2.0) without using the "--enable-universal" option. Compiling r6223 cslreduce under macOS Monterey 12.1 with the "--enable-universal" option enabled, I got universal applications which are not recognized as applications by macOS Catalina. Best regards Marco Ferraris A possible workaround...
Compiling r6221 cslreduce fails
CSL Reduce 6183 compilation fails on macOS 10.15 x86_64
The fastest way in order to install "sheep, classi and stensor" on my M1 MacBook Air is to have a native M1 version of PSL. I’ll wait until you release it. Best regards Marco Il giorno 15 nov 2021, alle ore 18:47, Rainer Schöpf schoepf@users.sourceforge.net ha scritto: A bpsl for Apple M1 needs a rewrite of PSL's memory layout, because of the W^X security feature on "Apple Silicon". W^X isn't a bad thing (OpenBSD has it since a couple of years which is the reason PSL doesn't run on OpenBSD), but...
Hi Norman, compiling CSL Reduce 6172 works well both on macintel64 and aarch64-mac_11_bigsur-darwin20.6.0. Compiling PSL Reduce 6172 works well on on macintel64 but fails on M1 Mac with the following message: ~/sw/reduce-algebra/trunk/psl/bootstrap.sh aarch64-mac_11_bigsur-darwin20.6.0 ~/sw/reduce-algebra/trunk/pslbuild/aarch64-mac_11_bigsur-darwin20.6.0 ++++++ Build initial bootstrap system ++++++ ~/sw/reduce-algebra/trunk/psl/bootstrap.sh: line 110: ./bpsl: No such file or directory ~/sw/reduce-algebra/trunk/psl/bootstrap.sh:...
CSL Reduce 6170 compilation fails on macOS 10.15 x86_64
Now csl reduce compilation works.
The file 'fwin.cpp' fails to compile in macOS 10.15.7
Hi Arthur, the compilation now works fine both in macOS Catalina and Windows 10. Best Regards Marco Il giorno 2 mag 2021, alle ore 22:32, Arthur Norman arthurcnorman@users.sourceforge.net ha scritto: The relevant section should read { if defined CONSERVATIVE && defined DEBUG cout << "bad synonym stream " << Addr(f1) << "\n"; cout << "header = " << std::hex << vechdr(f1) << std::dec << "\n"; simple_print(stream_type(f)); simple_print(stream_write_data(f)); endif return aerror("bad synonym stream");...
compilation of csl-reduce fails both in Mac OS X Catalina and Windows 10
Probably there was something wrong in the svn update procedure which did not update the "trunk/csl/cslbase/configure.ac" file in the 5348 sources. Therefore, my comment applies only when you try to compile older revisions (e.g. 5348) of CSL Reduce after having updated the port of freetype. As you know, there is no need to update "trunk/csl/cslbase/configure". The file "trunk/csl/cslbase/configure.ac" should be updated also in macports "reduce @20181123_2".
Compiling macOS CSL Reduce
missing csl apps in Reduce-snapshot_5237.dmg and compilation failures
unbound variable name in procedure proc!-add!-info
errors while compiling under cygwin64
I updated to revision 5054 and everything works fine. Thanks, Marco Il giorno 10 lug 2019, alle ore 10:46, Arthur Norman arthurcnorman@users.sourceforge.net ha scritto: Please try the latest revision - I had what should have been at worst a temporary glitch then where some files had been updated but others not. I am away on a trip now but have just checked and externs.h declare those and restart.cpp defined them now. Arthur On Wed, 10 Jul 2019, Marco Ferraris wrote: [bugs:#100] https://sourceforge.net/p/reduce-algebra/bugs/100/...
error compiling csl.cpp