aldor fricas interoperability... call for testers

Ralf Hemmecke

unread,

Aug 2, 2008, 11:43:31 AM8/2/08

to fricas-devel

Hello,

I've just committed some code that should enable you to install the
aldor-fricas interface. See branches/aldor-interface/src/aldor/README
(see below).

Of course, the installation process needs fine tuning. But since I also
want to get rid of that needless warning

#1 (Warning) Deprecated message prefix: use `ALDOR_' instead of `_AXL'

I first have to look where I can change the parameters for the aldor
compiler. I'll also add some "-I path/to/axiom_as" so that axiom.as can
live inside the fricas installation dir.

Anyway, if there aren't many people who complain then the interface is
pretty much finished. Try it out!

Ralf

mkdir fricas
cd fricas
FRICASSVN=https://fricas.svn.sourceforge.net/svnroot/fricas
svn co $FRICASSVN/branches/aldor-interface fricas-src
mkdir fricas-build
cd fricas-build
../fricas-src/configure
# Write
# ../fricas-src/configure --prefix=/some/where/else
# if you want to install somewhere else but not in /usr/local
make
cd src/aldor
make
cp axiom.as $ALDORROOT/include
cd ../..
make install

------------------------------------------------------------------
sieve.as is the program that can be found (as test.as) at
http://groups.google.com/group/fricas-devel/browse_thread/thread/3ee15417dffa9ef7/a6a67e60a9f5f58f#a6a67e60a9f5f58f

(1) -> )co sieve.as
Compiling FriCAS source code from file
/home/hemmecke/scratch/fricas/fricas-build/src/aldor/sieve.as
using AXIOM-XL compiler and options
-O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom -Y
$AXIOM/algebra
Use the system command )set compiler args to change these
options.
#1 (Warning) Deprecated message prefix: use `ALDOR_' instead of `_AXL'
Compiling Lisp source code from file ./sieve.lsp
Issuing )library command for sieve

(1) -> sieve 10

(1) 4
Type: PositiveInteger
(2) -> sieve 100

(2) 25
Type: PositiveInteger

Bill Page

unread,

Aug 2, 2008, 5:36:34 PM8/2/08

to fricas...@googlegroups.com

Ralf,

On Sat, Aug 2, 2008 at 11:43 AM, Ralf Hemmecke wrote:
>
> I've just committed some code that should enable you to install the
> aldor-fricas interface. See branches/aldor-interface/src/aldor/README
> (see below).
>

Great, I am giving it a try right now. It is still in progress. I will
let you know the result when it finishes.

> Of course, the installation process needs fine tuning.

As I watch the progress on the console I am curious about why I see so
many messages of the form:
....
ar r al/libaxiom_PADICRAT.al ao/VECTOR.ao
ar r al/libaxiom_PADICRAT.al ao/MATRIX.ao
ar r al/libaxiom_PADICRAT.al ao/PI.ao
ar r al/libaxiom_PADICRAT.al ao/SEGCAT.ao
ar r al/libaxiom_PADICRAT.al ao/SEGXCAT.ao
ar r al/libaxiom_PADICRAT.al ao/SEG.ao
ar r al/libaxiom_PADICRAT.al ao/SINT.ao
....

repeated over and over again - probably once for each call to the
aldor compiler? It appears almost as if the library is being re-built
after each new module is compiled. Is this necessary?

Regards,
Bill Page.

Ralf Hemmecke

unread,

Aug 2, 2008, 6:45:32 PM8/2/08

to fricas...@googlegroups.com

> As I watch the progress on the console I am curious about why I see so
> many messages of the form:
> ....
> ar r al/libaxiom_PADICRAT.al ao/VECTOR.ao
> ar r al/libaxiom_PADICRAT.al ao/MATRIX.ao
> ar r al/libaxiom_PADICRAT.al ao/PI.ao
> ar r al/libaxiom_PADICRAT.al ao/SEGCAT.ao
> ar r al/libaxiom_PADICRAT.al ao/SEGXCAT.ao
> ar r al/libaxiom_PADICRAT.al ao/SEG.ao
> ar r al/libaxiom_PADICRAT.al ao/SINT.ao
> ....
>
> repeated over and over again - probably once for each call to the
> aldor compiler? It appears almost as if the library is being re-built
> after each new module is compiled. Is this necessary?

I thought, I have documented it somewhere. But to be honest, onces some
people have successfully built and used the interface with the current
build process, I will certainly try to make those messages disappear.

The aldor compiler is know not to be totally reliable. In particular, if
one has a big library and compiles against that the compiler might
produce garbage (I guess just because optimization does the wrong thing
depending on the size of the library... I've no idea why that is).
I personally remember a situation where Manuel Bronstein and me compiled
a file with -laldor and the same file with -lalgebra -laldor. Although
libalgebra was not used, the program crashed.

So that as a history. Peter Broadbery actually initiated that way of
building libaxiom.al.

For each clique file c.ap there are some dependencies d1.ap,
d2.ap,...,dn.ap. All the dependencies will of course be compiled before
c.ap. Then for c.ap the library libaxiom_c.al is created which contains
d1.ao,...,dn.ao. c.ap is then compiled against libaxiom_c.al.

Of course, libaxiom_c.al is a bit smaller than libaxiom.al when it comes
to compile c.ap, because it really only contains the dependencies of c.ap.

In the future, I will certainly try to simplify that process to just use
libaxiom.al during its own build. But I first wanted something working,
before I produce a buggy libaxiom.al that I would be unable to debug.

Hope that helps.

Ralf

Bill Page

unread,

Aug 3, 2008, 12:17:15 AM8/3/08

to fricas...@googlegroups.com

Ralf,

On Sat, Aug 2, 2008 at 5:36 PM, Bill Page wrote:
>
> On Sat, Aug 2, 2008 at 11:43 AM, Ralf Hemmecke wrote:
>>
>> I've just committed some code that should enable you to install the
>> aldor-fricas interface. See branches/aldor-interface/src/aldor/README
>> (see below).
>>
>
> Great, I am giving it a try right now. It is still in progress. I will
> let you know the result when it finishes.
>

The build just finished with an error message:

"No rule to make target `runtime.ao', needed by `lsp/runtime.lsp'."

Any idea what I did wrong? I guess I will start over completely with a new

..........
ar r al/libaxiom_ZMOD.al ao/STREAM.ao
ar r al/libaxiom_ZMOD.al ao/UNISEG.ao
ar r al/libaxiom_ZMOD.al ao/axlit.ao
ar r al/libaxiom_ZMOD.al ao/axextend.ao
aldor -Wname=axiom -Mno-abbrev -Mpreview -Y al -L AxiomLib=axiom_ZMOD
-fao=ao/ZMOD.ao ap/ZMOD.ap
ar r al/libaxiom.al ao/ZMOD.ao
rm ao/.dir
make[1]: Leaving directory `/home/page/fricas-aldor/fricas-build/src/aldor'
echo ')fin' > tmp/mko_runtime.lsp
echo '(load "/home/page/fricas-aldor/fricas-build/src/interp/foam_l.o")'
>> tmp/mko_runtime.lsp
echo '(compile-file "lsp/runtime.lsp" :output-file "lib/runtime.o")'
>> tmp/mko_runtime.lsp
echo '(quit)' >> tmp/mko_runtime.lsp
make: *** No rule to make target `runtime.ao', needed by
`lsp/runtime.lsp'. Stop.
root@sage:~/fricas-aldor/fricas-build/src/aldor#

--------

I deleted the build directory and restarted everything from the
beginning, but I get the same error.

Any ideas.

Regards,
Bill Page.

Ralf Hemmecke

unread,

Aug 3, 2008, 9:34:49 AM8/3/08

to fricas...@googlegroups.com

> The build just finished with an error message:
>
> "No rule to make target `runtime.ao', needed by `lsp/runtime.lsp'."
>
> Any idea what I did wrong? I guess I will start over completely with a new

Yep. That seems to be an error on my part.

You find

lsp/runtime.lsp: runtime.ao lsp/.dir
ar x $(ALDORROOT)/lib/libfoam.al $<
$(ALDOR) -flsp=$@ $<

in src/aldor/Makefile.in

But that is a stupid leftover, since as you see 'runtime.ao' will be
extracted from libfoam.al. So that should be something like

lsp/runtime.lsp: runtime.ao lsp/.dir
$(ALDOR) -flsp=$@ $<

runtime.ao: $(ALDORROOT)/lib/libfoam.al
ar x $< $@

Bill, please wait another few minutes, I am just about to commit another
patch that changes a number of other issues, too.

Sorry.

Ralf

Ralf Hemmecke

unread,

Aug 3, 2008, 6:58:55 PM8/3/08

to fricas...@googlegroups.com

Hi Bill,

an update on this one. If you like to try without those intermediate
libraries, then modify src/aldor/Makefile2 according to the patch below.

The compilation of libaxiom.al is quite some bit faster.

It works on my computer together with the sieve program.

Ralf

=== Makefile2.in
==================================================================
--- Makefile2.in (revision 2142)
+++ Makefile2.in (local)
@@ -39,8 +39,8 @@
$(patsubst %,ao/%.ao,$(aldor_src)): extra_ao_options=
$(patsubst %,ao/%.ao,$(AXIOM_CLIQUES)): extra_ao_options=-Wname=axiom
-Mno-abbrev -Mpreview
.PRECIOUS: ao/%.ao
-ao/%.ao: ap/%.ap al/libaxiom_%.al ao/.dir
- $(ALDOR) $(extra_ao_options) -Y al -L AxiomLib=axiom_$* -fao=$@ $<
+ao/%.ao: ap/%.ap ao/.dir
+ $(ALDOR) $(extra_ao_options) -Y al -L AxiomLib=axiom -fao=$@ $<

# We compile a seperate temporary library for the compilation of each
# .ao file in order to avoid trouble with big libraries and the aldor

Bill Page

unread,

Aug 3, 2008, 8:02:09 PM8/3/08

to fricas...@googlegroups.com

Ralf,

On Sun, Aug 3, 2008 at 6:58 PM, you wrote:
>
>
> an update on this one. If you like to try without those intermediate
> libraries, then modify src/aldor/Makefile2 according to the patch
> below.
>
> The compilation of libaxiom.al is quite some bit faster.
>

Yes, this patch works fine for me. It is much faster.

> It works on my computer together with the sieve program.
>

> === Makefile2.in
> ==================================================================
> --- Makefile2.in (revision 2142)
> +++ Makefile2.in (local)
> @@ -39,8 +39,8 @@
> $(patsubst %,ao/%.ao,$(aldor_src)): extra_ao_options=
> $(patsubst %,ao/%.ao,$(AXIOM_CLIQUES)): extra_ao_options=-Wname=axiom
> -Mno-abbrev -Mpreview
> .PRECIOUS: ao/%.ao
> -ao/%.ao: ap/%.ap al/libaxiom_%.al ao/.dir
> - $(ALDOR) $(extra_ao_options) -Y al -L AxiomLib=axiom_$* -fao=$@ $<
> +ao/%.ao: ap/%.ap ao/.dir
> + $(ALDOR) $(extra_ao_options) -Y al -L AxiomLib=axiom -fao=$@ $<
>
> # We compile a seperate temporary library for the compilation of each
> # .ao file in order to avoid trouble with big libraries and the aldor
>

Of course I still require the hashcode patch for anything to work on my system.

Regards,
Bill Page.

Martin Rubey

unread,

Aug 3, 2008, 9:15:00 PM8/3/08

to fricas...@googlegroups.com

Hi Ralf,

congratulations!

I compiled on my machine (some kubuntu) with GCL and Aldor 1.0.3 without any
problems, and iso-experiment compiles and runs perfectly!!!

Next step for me is to get sbcl working. First thing here was to change all .o
to .$(FASLEXT). Second is to make IN-PACKAGE understand the old 3-argument
form. That part I am currently unable to do, sbcl doesn't let me unlock the
package... Help needed here.

Another tiny thing: sbcl treats arguments of compile-file differently, it
seems.

Martin

Index: src/interp/vmlisp.lisp
===================================================================
--- src/interp/vmlisp.lisp (revision 333)
+++ src/interp/vmlisp.lisp (working copy)
@@ -1556,6 +1556,17 @@

(in-package "BOOT")

+;;; Aldor 1.1.0 produces in-package statements with :use options. These can
be
+;;; ignored, so we do not use
+;;; (defpackage package options)
+;;; (in-package package)
+#+sbcl
+(progn
+ (declare (disable-package-locks COMMON-LISP:IN-PACKAGE))
+ (shadow "IN-PACKAGE" "BOOT")
+ (defmacro IN-PACKAGE (package &rest options)
+ (COMMON-LISP:IN-PACKAGE ,package)))
+
;; Contributed by Juergen Weiss from a suggestion by Arthur Norman.
;; This is a Mantissa and Exponent function.
#-:CCL
Index: src/interp/foam_l.lisp
===================================================================
--- src/interp/foam_l.lisp (revision 333)
+++ src/interp/foam_l.lisp (working copy)
@@ -157,7 +157,7 @@
(deftype |Bool| () '(member t nil))
(deftype |Byte| () 'unsigned-byte)
(deftype |HInt| () '(integer #.(- (expt 2 15)) #.(1- (expt 2 15))))
-(deftype |SInt| () 'fixnum)
+(deftype |SInt| () '(integer #.(- (expt 2 31)) #.(1- (expt 2 31))))

#+:AKCL
(deftype |BInt| () t)
@@ -511,7 +511,7 @@
(defmacro |FunProg| (x) x)

(defstruct FoamProgInfoStruct
- (funcall nil :type function)
+ (funcall #'(lambda () (error "FoamProgInfoStruct: funcall not assigned"))
:type function)
(hashval 0 :type |SInt|))

(defun |ProgHashCode| (x)
@@ -617,8 +617,15 @@
;; macros for defining things

(defmacro declare-prog (name-result params)
- `(proclaim '(function ,(car name-result) ,params ,@(cdr name-result))))
+ `(proclaim '(ftype (function
+ ,(mapcar #'cadr params)
+ ,(or (cadr name-result) 't))
+ ,(car name-result))))

+;(defmacro declare-prog (name-result params)
+; `(proclaim '(function ,(car name-result) ,params ,@(cdr name-result))))
+
+
(defmacro declare-type (name type)
`(proclaim '(type ,name ,type)))

Index: src/aldor/Makefile.in
===================================================================
--- src/aldor/Makefile.in (revision 333)
+++ src/aldor/Makefile.in (working copy)
@@ -275,8 +275,8 @@
###################################################################
# Runtime - things required to run aldor files
# It is not clear whether actually all files in $(aldor_srcs) are needed.
-runtime_files := $(patsubst %,lib/%.o, runtime $(aldor_srcs))
-$(runtime_files): lib/%.o: lsp/%.lsp
+runtime_files := $(patsubst %,lib/%.$(FASLEXT), runtime $(aldor_srcs))
+$(runtime_files): lib/%.$(FASLEXT): lsp/%.lsp
aldor_lsp_files := $(patsubst %,lsp/%.lsp, $(aldor_srcs))

lsp/runtime.lsp: runtime.ao lsp/.dir
$(ALDOR) -flsp=$@ $<

@@ -289,15 +289,16 @@
$(ALDOR) -flsp=$@ $*.ao
rm $*.ao

-foam_l=$(abs_top_builddir)/src/interp/foam_l.o
-$(runtime_files): lib/%.o: tmp/mko_%.lsp lsp/%.lsp lib/.dir
+foam_l=$(abs_top_builddir)/src/interp/foam_l.$(FASLEXT)
+$(runtime_files): lib/%.$(FASLEXT): tmp/mko_%.lsp lsp/%.lsp lib/.dir
$(INTERPSYS) < $< > tmp/mko_$*.log
test -f $@

tmp/mko_%.lsp:
echo ')fin' > $@
+ echo '(in-package "BOOT")' >> $@
echo '(load "$(foam_l)")' >> $@
- echo '(compile-file "lsp/$*.lsp" :output-file "lib/$*.o")' >> $@
+ echo '(compile-file "$(abs_top_builddir)/src/aldor/lsp/$*.lsp"
:output-file "$(abs_top_builddir)/src/aldor/lib/$*.$(FASLEXT)")' >> $@
echo '(quit)' >> $@

runtimefiles: $(runtime_files)

Waldek Hebisch

unread,

Aug 3, 2008, 10:25:24 PM8/3/08

to fricas...@googlegroups.com

> Next step for me is to get sbcl working. First thing here was to change all .o
> to .$(FASLEXT). Second is to make IN-PACKAGE understand the old 3-argument
> form. That part I am currently unable to do, sbcl doesn't let me unlock the
> package... Help needed here.
>

AFAICS there is no need to unlock the COMMON-LISP package. Just
shadowing should do. Another possiblity is to avoid importing
IN-PACKAGE from COMMON-LISP -- in FriCAS standard Common Lisp
symbols are imported to FRICAS-LISP package and then
re-exported and used from there in other packages.

> Another tiny thing: sbcl treats arguments of compile-file differently, it
> seems.
>
> Martin
>
> Index: src/interp/vmlisp.lisp
> ===================================================================
> --- src/interp/vmlisp.lisp (revision 333)
> +++ src/interp/vmlisp.lisp (working copy)
> @@ -1556,6 +1556,17 @@
>
> (in-package "BOOT")
>
> +;;; Aldor 1.1.0 produces in-package statements with :use options. These can
> be
> +;;; ignored, so we do not use
> +;;; (defpackage package options)
> +;;; (in-package package)
> +#+sbcl
> +(progn
> + (declare (disable-package-locks COMMON-LISP:IN-PACKAGE))
> + (shadow "IN-PACKAGE" "BOOT")
> + (defmacro IN-PACKAGE (package &rest options)
> + (COMMON-LISP:IN-PACKAGE ,package)))
> +

It looks that you should split this into two parts:

#+sbcl
(shadow "IN-PACKAGE" "BOOT")
#+sbcl

(defmacro IN-PACKAGE (package &rest options)

(COMMON-LISP:IN-PACKAGE ,package))

AFAIK in your version the IN-PACKAGE after defmacro is read before
shadow is executed, so instead of defining new version in "BOOT"
package you are re-defining Common Lisp version.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Is this neccessary and correct? On 32 bit machine fixnum may
be smaller than 32-bits and FriCAS SingleInteger assumes that
values fit into fixnum.

--
Waldek Hebisch
heb...@math.uni.wroc.pl

Martin Rubey

unread,

Aug 4, 2008, 3:27:57 AM8/4/08

to fricas...@googlegroups.com

Waldek Hebisch <heb...@math.uni.wroc.pl> writes:

> It looks that you should split this into two parts:
>
> #+sbcl
> (shadow "IN-PACKAGE" "BOOT")
> #+sbcl
> (defmacro IN-PACKAGE (package &rest options)
> (COMMON-LISP:IN-PACKAGE ,package))

> AFAIK in your version the IN-PACKAGE after defmacro is read before
> shadow is executed, so instead of defining new version in "BOOT"
> package you are re-defining Common Lisp version.

Thanks a lot, I didn't understand progn...

> > ===================================================================
> > --- src/interp/foam_l.lisp (revision 333)
> > +++ src/interp/foam_l.lisp (working copy)
> > @@ -157,7 +157,7 @@
> > (deftype |Bool| () '(member t nil))
> > (deftype |Byte| () 'unsigned-byte)
> > (deftype |HInt| () '(integer #.(- (expt 2 15)) #.(1- (expt 2 15))))
> > -(deftype |SInt| () 'fixnum)
> > +(deftype |SInt| () '(integer #.(- (expt 2 31)) #.(1- (expt 2 31))))
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Is this neccessary and correct? On 32 bit machine fixnum may be smaller than
> 32-bits and FriCAS SingleInteger assumes that values fit into fixnum.

That's the problem: Aldor (the compiler) assumes that SInt can hold values in
the 32 bit range (for the hash function), and that's not true on sbcl... with
this patch (which is incorrect, I admit) I get further.

I guess the true patch is to patch aldors hash function to compute smaller
numbers.

Unfortunately, there are still problems:

* it seems that the IN-PACKAGE statement is not shadowed in the right package:
loading runtime.fasl still fails. For the moment, I simply removed the
offending arguments in runtime.lsp etc.

* it still doesn't run:

(1) -> )re ../lib/test
)se me au off

l: SetSpecies ACINT := set [i::ACINT for i in 1..4]

>> System error:
AxiomXL file "KOERCE" is missing!

(1) -> )se br br
(1) -> )re ../lib/test
)se me au off

l: SetSpecies ACINT := set [i::ACINT for i in 1..4]

debugger invoked on a SIMPLE-ERROR in thread #<THREAD "initial thread"
{BC02D41}>:
AxiomXL file "MATRIX" is missing!

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

(no restarts: If you didn't do this on purpose, please report it as a bug.)

(FOAM::PROCESS-IMPORT-ENTRY (G-MATRIX "MATRIX" |initializer| ""))
0] backtrace

0: (FOAM::PROCESS-IMPORT-ENTRY (G-MATRIX "MATRIX" |initializer| ""))
1: (SB-IMPL::MAP1
#<FUNCTION FOAM::PROCESS-IMPORT-ENTRY>
(((G-MATRIX "MATRIX" |initializer| "") (G-VECTOR "VECTOR" |initializer| "")
(|G-axlit| "axlit" |initializer| "") (G-SEG "SEG" |initializer| "")
(G-UNISEG "UNISEG" |initializer| "")
(|G-rtAddStrings| "rtAddStrings" 0 "")
(|G-uniseg_UniversalSegment_1006388609| "UniversalSegment" 1006388609
"uniseg")
(|G-seg_Segment_199524315| "Segment" 199524315 "seg")
(|G-domainAddDefaults!| "domainAddDefaults!" 0 "")
(|G-categoryAddParents!| "categoryAddParents!" 0 "")
(|G-domainTestExport!| "domainTestExport!" 0 "")
(|G-categoryMake| "categoryMake" 0 "") ...))
:LIST
T)
2: (MAPCAR
#<FUNCTION FOAM::PROCESS-IMPORT-ENTRY>
((G-MATRIX "MATRIX" |initializer| "") (G-VECTOR "VECTOR" |initializer| "")
(|G-axlit| "axlit" |initializer| "") (G-SEG "SEG" |initializer| "")
(G-UNISEG "UNISEG" |initializer| "")
(|G-rtAddStrings| "rtAddStrings" 0 "")
(|G-uniseg_UniversalSegment_1006388609| "UniversalSegment" 1006388609
"uniseg")
(|G-seg_Segment_199524315| "Segment" 199524315 "seg")
(|G-domainAddDefaults!| "domainAddDefaults!" 0 "")
(|G-categoryAddParents!| "categoryAddParents!" 0 "")
(|G-domainTestExport!| "domainTestExport!" 0 "")
(|G-categoryMake| "categoryMake" 0 "") ...))
3: (SB-EVAL::EVAL-PROGN
((WHEN (FBOUNDP 'FOAM::PROCESS-IMPORT-ENTRY)
(MAPCAR #'FOAM::PROCESS-IMPORT-ENTRY
'((G-MATRIX "MATRIX" |initializer| "")
(G-VECTOR "VECTOR" |initializer| "")
(|G-axlit| "axlit" |initializer| "")
(G-SEG "SEG" |initializer| "")
(G-UNISEG "UNISEG" |initializer| "")
(|G-rtAddStrings| "rtAddStrings" 0 "")
(|G-uniseg_UniversalSegment_1006388609| "UniversalSegment"
1006388609 "uniseg")
(|G-seg_Segment_199524315| "Segment" 199524315 "seg")
(|G-domainAddDefaults!| "domainAddDefaults!" 0 "")
(|G-categoryAddParents!| "categoryAddParents!" 0 "")
(|G-domainTestExport!| "domainTestExport!" 0 "")
(|G-categoryMake| "categoryMake" 0 "") ...)))
NIL)
#<SB-EVAL::ENV {C8F9E81}>)
4: (SB-EVAL:EVAL-IN-NATIVE-ENVIRONMENT
(FILE-IMPORTS
'((G-MATRIX "MATRIX" |initializer| "")
(G-VECTOR "VECTOR" |initializer| "")
(|G-axlit| "axlit" |initializer| "") (G-SEG "SEG" |initializer| "")
(G-UNISEG "UNISEG" |initializer| "")
(|G-rtAddStrings| "rtAddStrings" 0 "")
(|G-uniseg_UniversalSegment_1006388609| "UniversalSegment" 1006388609
"uniseg")
(|G-seg_Segment_199524315| "Segment" 199524315 "seg")
(|G-domainAddDefaults!| "domainAddDefaults!" 0 "")
(|G-categoryAddParents!| "categoryAddParents!" 0 "")
(|G-domainTestExport!| "domainTestExport!" 0 "")
(|G-categoryMake| "categoryMake" 0 "") ...))
#<NULL-LEXENV>)
5: (SB-FASL::LOAD-AS-SOURCE
#<SB-SYS:FD-STREAM for "file
/tmp/lib/fricas/target/i686-pc-linux/aldor/lib/axextend.lisp" {C2C63F1}>
NIL
NIL)
6: (SB-FASL::INTERNAL-LOAD
#P"/tmp/lib/fricas/target/i686-pc-linux/aldor/lib/axextend.lisp"
#P"/tmp/lib/fricas/target/i686-pc-linux/aldor/lib/axextend.lisp"
:ERROR
NIL
NIL
:SOURCE
:DEFAULT)
7: (LOAD "/tmp/lib/fricas/target/i686-pc-linux//aldor/lib/axextend")
8: (BOOT::INIT-FILE-GETTER
(|G-axextend|
. "/tmp/lib/fricas/target/i686-pc-linux//aldor/lib/axextend"))

(the actual backtrace is much longer, of course)

Here is the current set of patches:

Index: interp/patches.lisp
===================================================================
--- interp/patches.lisp (revision 333)
+++ interp/patches.lisp (working copy)
@@ -171,12 +171,12 @@
(browseopen)
(|makeConstructorsAutoLoad|)
(let ((asharprootlib (strconc (|getEnv| "AXIOM") "/aldor/lib/")))
- (set-file-getter (strconc asharprootlib "runtime.o"))
- (set-file-getter (strconc asharprootlib "lang.o"))
- (set-file-getter (strconc asharprootlib "attrib.o"))
- (set-file-getter (strconc asharprootlib "axlit.o"))
- (set-file-getter (strconc asharprootlib "minimach.o"))
- (set-file-getter (strconc asharprootlib "axextend.o")))
+ (set-file-getter (strconc asharprootlib "runtime"))
+ (set-file-getter (strconc asharprootlib "lang"))
+ (set-file-getter (strconc asharprootlib "attrib"))
+ (set-file-getter (strconc asharprootlib "axlit"))
+ (set-file-getter (strconc asharprootlib "minimach"))
+ (set-file-getter (strconc asharprootlib "axextend")))
)

(defun whocalled (n) nil) ;; no way to look n frames up the stack
Index: interp/vmlisp.lisp
===================================================================
--- interp/vmlisp.lisp (revision 333)
+++ interp/vmlisp.lisp (working copy)
@@ -1556,6 +1556,16 @@

(in-package "BOOT")

+;;; Aldor 1.1.0 produces in-package statements with :use options. These can
be
+;;; ignored, so we do not use
+;;; (defpackage package options)
+;;; (in-package package)
+#+sbcl

+(shadow "IN-PACKAGE" "BOOT")
+#+sbcl
+(defmacro IN-PACKAGE (package &rest options)
+ `(COMMON-LISP:IN-PACKAGE ,package))

+
;; Contributed by Juergen Weiss from a suggestion by Arthur Norman.
;; This is a Mantissa and Exponent function.
#-:CCL

Index: interp/foam_l.lisp
===================================================================
--- interp/foam_l.lisp (revision 333)
+++ interp/foam_l.lisp (working copy)

#+:AKCL
(deftype |BInt| () t)
@@ -511,7 +511,7 @@
(defmacro |FunProg| (x) x)

(defstruct FoamProgInfoStruct
- (funcall nil :type function)
+ (funcall #'(lambda () (error "FoamProgInfoStruct: funcall not assigned"))
:type function)
(hashval 0 :type |SInt|))

(defun |ProgHashCode| (x)
@@ -617,8 +617,15 @@
;; macros for defining things

(defmacro declare-prog (name-result params)
- `(proclaim '(function ,(car name-result) ,params ,@(cdr name-result))))
+ `(proclaim '(ftype (function
+ ,(mapcar #'cadr params)
+ ,(or (cadr name-result) 't))
+ ,(car name-result))))

+;(defmacro declare-prog (name-result params)
+; `(proclaim '(function ,(car name-result) ,params ,@(cdr name-result))))
+
+
(defmacro declare-type (name type)
`(proclaim '(type ,name ,type)))

Index: aldor/Makefile.in
===================================================================
--- aldor/Makefile.in (revision 333)
+++ aldor/Makefile.in (working copy)

Ralf Hemmecke

unread,

Aug 4, 2008, 3:48:16 AM8/4/08

to fricas...@googlegroups.com

Hello Martin,

I don't like seeing "src/aldor" in the patch. You should rather replace
$(abs_top_build_dir)/src/aldor by $(builddir) or $(abs_builddir). The
first one is equal to . the second gives the full path. (Just look into
src/aldor/Makefile which lives in your build directory.)

The $(FASLEXT) instead of just taking o seems like an appropriate
change. Waldek?

Unfortunately, I don't understand any other of the SBCL related changes.
But as long as you don't break the GCL build, committing is OK for me.
Waldek, Martin, please coordinate with each other what should go into
the repository.

Ralf

Ralf Hemmecke

unread,

Aug 4, 2008, 3:57:36 AM8/4/08

to fricas...@googlegroups.com

> Of course I still require the hashcode patch for anything to work on my system.

The only significant patches I have compared to revision 23 of the aldor
compiler is...

I did this after a suggestion of Laurentiu.
http://www.nabble.com/Compilation-problem-td14295218.html
Unfortunately, there is not more explanation like in the above posts and
I don't really know whether that has something to do with the hash problem.

And no, I didn't patch fricas. I use exactly aldor-interface as it is in
revision 333 in the repository.

Ralf

=== aldor/contrib/gmp/editlevels.h
==================================================================
--- aldor/contrib/gmp/editlevels.h (revision 1448)
+++ aldor/contrib/gmp/editlevels.h (local)
@@ -185,7 +185,7 @@

*/

-#define AXL_EDIT_1_1_13_18 1 /* changed type hash code algorithm */
+#define AXL_EDIT_1_1_13_18 0 /* changed type hash code algorithm */
/* Breaks Basicmath DUP etc */

#if 0
=== aldor/src/editlevels.h
==================================================================
--- aldor/src/editlevels.h (revision 1448)
+++ aldor/src/editlevels.h (local)
@@ -185,7 +185,7 @@

*/

-#define AXL_EDIT_1_1_13_18 1 /* changed type hash code algorithm */
+#define AXL_EDIT_1_1_13_18 0 /* changed type hash code algorithm */
/* Breaks Basicmath DUP etc */

#if 0

Waldek Hebisch

unread,

Aug 4, 2008, 10:08:27 PM8/4/08

to fricas...@googlegroups.com

Ralf Hemmecke wrote:
> Hello Martin,
>
> I don't like seeing "src/aldor" in the patch. You should rather replace
> $(abs_top_build_dir)/src/aldor by $(builddir) or $(abs_builddir). The
> first one is equal to . the second gives the full path. (Just look into
> src/aldor/Makefile which lives in your build directory.)
>

One can avoid using absolute paths in Makefile using 'fricas-compile-file'
instead -- I wrote this function so that Makefiles can just pass
relative paths and get expected result. Note: this functions
probably is not good when using ECL (see below), but if needed we can
create a new one.

> The $(FASLEXT) instead of just taking o seems like an appropriate
> change. Waldek?

We have two extensions for compiled Lisp. They are the same for
most Lisps, only ECL needs both. FASLEXT is the correct one for
files which we want to load. LISPOBJEXT is for files which
are intended to be linked into the AXIOMsys executable.
Since Aldor interface is optional and we need AXIOMsys to
build it, linking interface files looks tricky, loading should
be easier. Assuming that we will load interface files
FASLEXT is the correct extension.

'fricas-compile-file' produces files intended for linking. So
for ECL we would need separate function to compile to
loadable file.

>
> Unfortunately, I don't understand any other of the SBCL related changes.
> But as long as you don't break the GCL build, committing is OK for me.
> Waldek, Martin, please coordinate with each other what should go into
> the repository.
>

I did not test SBCL changes but they look OK.

More generally, I consider Aldor interface as experimental code,
there is substantial work to be done before it will be mature. But
given that the interface is optional the main requirement
is that it does not break build without Aldor and that it
has reasonable chance of working (btw. gcl based build worked
for me and I was able to execute simple example).

--
Waldek Hebisch
heb...@math.uni.wroc.pl

Waldek Hebisch

unread,

Aug 4, 2008, 10:19:26 PM8/4/08

to fricas...@googlegroups.com

Martin Rubey wrote:
> Unfortunately, there are still problems:
>
> * it seems that the IN-PACKAGE statement is not shadowed in the right package:
> loading runtime.fasl still fails. For the moment, I simply removed the
> offending arguments in runtime.lsp etc.
>

You probably need to shadow IN-PACKAGE in the FRICAS-LISP package
(in the fricas-package.lisp). Also if you use depsys to compile
note that depsys starts in the "COMMON-LISP-USER" while
interpsys and AXIOMsys start in "BOOT" package.

> * it still doesn't run:
>
> (1) -> )re ../lib/test
> )se me au off
>
> l: SetSpecies ACINT := set [i::ACINT for i in 1..4]
>
>
> >> System error:
> AxiomXL file "KOERCE" is missing!
>

This looks like a stale file: the recent change to initializers
only takes effect once you recompile your files using new
libaxiom.al.

--
Waldek Hebisch
heb...@math.uni.wroc.pl

Ralf Hemmecke

unread,

Aug 5, 2008, 5:52:30 AM8/5/08

to fricas...@googlegroups.com

On 08/05/2008 04:08 AM, Waldek Hebisch wrote:
> Ralf Hemmecke wrote:
>> Hello Martin,
>>
>> I don't like seeing "src/aldor" in the patch. You should rather replace
>> $(abs_top_build_dir)/src/aldor by $(builddir) or $(abs_builddir). The
>> first one is equal to . the second gives the full path. (Just look into
>> src/aldor/Makefile which lives in your build directory.)

> One can avoid using absolute paths in Makefile using 'fricas-compile-file'
> instead -- I wrote this function so that Makefiles can just pass
> relative paths and get expected result. Note: this functions
> probably is not good when using ECL (see below), but if needed we can
> create a new one.

Waldek, since the Makefile can use $(abs_builddir) that is not really
specifying anything absolute, since the value of that variable changes
appropriately at configure time. So I am more in favour of producing
something that can also live as an OpenAxiom patch.

It is so sad that OpenAxiom and FriCAS seem to diverge slowly.

>> The $(FASLEXT) instead of just taking o seems like an appropriate
>> change. Waldek?

> We have two extensions for compiled Lisp. They are the same for
> most Lisps, only ECL needs both. FASLEXT is the correct one for
> files which we want to load.

OK. Then FASLEXT.

> LISPOBJEXT is for files which
> are intended to be linked into the AXIOMsys executable.

The aldor-interface build does not modify AXIOMsys in any way. In fact,
it is completely orthogonal. Basically, first build FriCAS and then add
some more files.

>> Unfortunately, I don't understand any other of the SBCL related changes.
>> But as long as you don't break the GCL build, committing is OK for me.
>> Waldek, Martin, please coordinate with each other what should go into
>> the repository.

> I did not test SBCL changes but they look OK.

I still would be more happy, Martin, if these changes were documented in
such a way that I understand them. ;-)

> More generally, I consider Aldor interface as experimental code,
> there is substantial work to be done before it will be mature.

What do you mean here?

> But given that the interface is optional the main requirement
> is that it does not break build without Aldor and that it
> has reasonable chance of working (btw. gcl based build worked
> for me and I was able to execute simple example).

So let me clarify (I'll also add something like that in the interface
documentation).

1) The interface is done *after* the complete build of FriCAS. It will
never modify anything that was produced before 'make' inside src/aldor
started.

2) In an installed FriCAS there are only

$AXIOM/algebra/axiom.as
$AXIOM/algebra/libaxiom.al
$Axiom/aldor/lib/*.o

as additional files. So that cannot break FriCAS at all, since these
files are unknown to FriCAS.

3) Otherwise, there is only

configure.ac
Makefile.in
src/Makefile.in

changed, but in such a way that this doesn't interfere with the initial
build of FriCAS.

4) I guess, I should follow Gaby's suggestion and add a '--enable-aldor'
option to the configure command line. Actually, I think I would rather
like '--disable-aldor'. But Waldek, you have the last word. So tell me
what you prefer.
Currently at configure time it is checked whether there is an aldor
compiler, whether $ALDORROOT/include/aldor.conf and
$ALDORROOT/lib/libfoam.al exist. If one of these tests fail, the
interface is not built.

Ralf

Ralf Hemmecke

unread,

Aug 5, 2008, 5:56:01 AM8/5/08

to fricas...@googlegroups.com

On 08/05/2008 04:19 AM, Waldek Hebisch wrote:
> Martin Rubey wrote:
>> Unfortunately, there are still problems:
>>
>> * it seems that the IN-PACKAGE statement is not shadowed in the right package:
>> loading runtime.fasl still fails. For the moment, I simply removed the
>> offending arguments in runtime.lsp etc.
>>
>
> You probably need to shadow IN-PACKAGE in the FRICAS-LISP package
> (in the fricas-package.lisp). Also if you use depsys to compile
> note that depsys starts in the "COMMON-LISP-USER" while
> interpsys and AXIOMsys start in "BOOT" package.

I don't really know why Martin has put this boot line into his
Makefile.in patch:

tmp/mko_%.lsp:
echo ')fin' > $@
---> echo '(in-package "BOOT")' >> $@

echo '(load "$(foam_l)")' >> $@

echo '(compile-file "$(abs_builddir)/lsp/$*.lsp" ' >> $@
echo ' :output-file "$(abs_builddir)/lib/$*.$(FASLEXT)")' >> $@
echo '(quit)' >> $@

Martin, is that really necessary. Note that my Makefile exclusively uses
AXIOMsys.

INTERPSYS = DAASE=$(axiom_targetdir) $(axiom_target_bindir)/AXIOMsys

Any comment?

Ralf

Martin Rubey

unread,

Aug 5, 2008, 6:04:49 AM8/5/08

to fricas...@googlegroups.com

Ralf Hemmecke <ra...@hemmecke.de> writes:

> > I did not test SBCL changes but they look OK.
>
> I still would be more happy, Martin, if these changes were documented in
> such a way that I understand them. ;-)

Well, I still couldn't get FriCAS/sbcl + Raldorf to work. But it's looking
better every day.

I do not more than what I sent in the emails and wrote into the files I
modified.

The main longterm issue is: can we modify aldor's hashing algorithm to produce
numbers that fit into a fixnum, i.e., 16 bit. Common Lisp fixnum is guaranteed
to have 16 bit. Assuming 32 bit is too much: sbcl only has 29, for example.

Hm, in fact, the problem is deeper than that. More precisely, foam provides a
SInt type with 32 bits. And it seems that it is mapped to FriCAS
SingleInteger, which is a fixnum, i.e., depends on the Common Lisp used, but is
guaranteed to have 16 bit.

We would have to check where foam SInts are actually used.

> 4) I guess, I should follow Gaby's suggestion and add a '--enable-aldor'
> option to the configure command line. Actually, I think I would rather
> like '--disable-aldor'. But Waldek, you have the last word. So tell me
> what you prefer.

I'd also prefer --disable-aldor.

Martin

Martin Rubey

unread,

Aug 5, 2008, 6:07:37 AM8/5/08

to fricas...@googlegroups.com

Ralf Hemmecke <ra...@hemmecke.de> writes:

> I don't really know why Martin has put this boot line into his
> Makefile.in patch:
>
> tmp/mko_%.lsp:
> echo ')fin' > $@
> ---> echo '(in-package "BOOT")' >> $@
> echo '(load "$(foam_l)")' >> $@
> echo '(compile-file "$(abs_builddir)/lsp/$*.lsp" ' >> $@
> echo ' :output-file "$(abs_builddir)/lib/$*.$(FASLEXT)")' >> $@
> echo '(quit)' >> $@

again: my set of patches does *not* work. I sent them to the list so that you
can see what I'm experimenting with.

As I said: I was puzzled that the stanza above (without my addition) did not
like the 3-argument form of IN-PACKAGE. Putting in the BOOT did not help,
actually. But it seems that Waldek gave the right hint already, we will know
in roughly one hour.

Martin

Ralf Hemmecke

unread,

Aug 5, 2008, 6:19:10 AM8/5/08

to fricas...@googlegroups.com, Pippijn van Steenhoven

> The main longterm issue is: can we modify aldor's hashing algorithm
> to produce numbers that fit into a fixnum, i.e., 16 bit.

Well I suggest we do that on an algebraist branch. At least I want to
have these little fixes and I don't care about APL2 for that. I want to
have it working.

The biggest problem is that there seems nobody around who really is able
to do the appropriate changes.

> Common Lisp fixnum is guaranteed to have 16 bit. Assuming 32 bit is
> too much: sbcl only has 29, for example.
>
> Hm, in fact, the problem is deeper than that. More precisely, foam
> provides a SInt type with 32 bits. And it seems that it is mapped to
> FriCAS SingleInteger, which is a fixnum, i.e., depends on the Common
> Lisp used, but is guaranteed to have 16 bit.
>
> We would have to check where foam SInts are actually used.

OK. Will you look into it?

Pipijn are you also interested to help us out here?

Ralf

Waldek Hebisch

unread,

Aug 5, 2008, 7:23:36 AM8/5/08

to fricas...@googlegroups.com

Martin Rubey wrote:
>
> Ralf Hemmecke <ra...@hemmecke.de> writes:
>
> > > I did not test SBCL changes but they look OK.
> >
> > I still would be more happy, Martin, if these changes were documented in
> > such a way that I understand them. ;-)
>
> Well, I still couldn't get FriCAS/sbcl + Raldorf to work. But it's looking
> better every day.
>
> I do not more than what I sent in the emails and wrote into the files I
> modified.
>
> The main longterm issue is: can we modify aldor's hashing algorithm to produce
> numbers that fit into a fixnum, i.e., 16 bit. Common Lisp fixnum is guaranteed
> to have 16 bit. Assuming 32 bit is too much: sbcl only has 29, for example.
>

I do not think that using 16 bits for hash is enough (simply, there
is substantial risk of getting many collisions). Depending how the hash
is used 29 may be enough (sometimes you want _no_ collosions at all,
then going up to 64 bit would be the correct way). And I do not
think we want to support any Lisp that offers less than 29 bit
fixnums.

Rather, we should have separate type for hash, not necessarily the
same as fixnum.

> Hm, in fact, the problem is deeper than that. More precisely, foam provides a
> SInt type with 32 bits. And it seems that it is mapped to FriCAS
> SingleInteger, which is a fixnum, i.e., depends on the Common Lisp used, but is
> guaranteed to have 16 bit.
>
> We would have to check where foam SInts are actually used.
>

Yes.

> > 4) I guess, I should follow Gaby's suggestion and add a '--enable-aldor'
> > option to the configure command line. Actually, I think I would rather
> > like '--disable-aldor'. But Waldek, you have the last word. So tell me
> > what you prefer.
>
> I'd also prefer --disable-aldor.
>

I think it is reasonable to build Aldor interface by default if user
has Aldor.

--
Waldek Hebisch
heb...@math.uni.wroc.pl

Martin Rubey

unread,

Aug 5, 2008, 7:22:23 AM8/5/08

to fricas...@googlegroups.com

Waldek Hebisch <heb...@math.uni.wroc.pl> writes:

> Martin Rubey wrote:
> >
> > Ralf Hemmecke <ra...@hemmecke.de> writes:
> >
> > > > I did not test SBCL changes but they look OK.
> > >
> > > I still would be more happy, Martin, if these changes were documented in
> > > such a way that I understand them. ;-)
> >
> > Well, I still couldn't get FriCAS/sbcl + Raldorf to work. But it's looking
> > better every day.
> >
> > I do not more than what I sent in the emails and wrote into the files I
> > modified.
> >
> > The main longterm issue is: can we modify aldor's hashing algorithm to produce
> > numbers that fit into a fixnum, i.e., 16 bit. Common Lisp fixnum is guaranteed
> > to have 16 bit. Assuming 32 bit is too much: sbcl only has 29, for example.
> >
>
> I do not think that using 16 bits for hash is enough (simply, there
> is substantial risk of getting many collisions). Depending how the hash
> is used 29 may be enough (sometimes you want _no_ collosions at all,
> then going up to 64 bit would be the correct way). And I do not
> think we want to support any Lisp that offers less than 29 bit
> fixnums.
>
> Rather, we should have separate type for hash, not necessarily the
> same as fixnum.

OK. Is this feasible?

> > Hm, in fact, the problem is deeper than that. More precisely, foam provides
> > a SInt type with 32 bits. And it seems that it is mapped to FriCAS
> > SingleInteger, which is a fixnum, i.e., depends on the Common Lisp used,
> > but is guaranteed to have 16 bit.
> >
> > We would have to check where foam SInts are actually used.
>
> Yes.

Unfortunately, I have only a vague idea how to do it. Maybe I should compile
two files, one using FriCAS SingleInteger, one without. But very likely, foam
SINTs are also used in loops, etc...

Martin

Martin Rubey

unread,

Aug 5, 2008, 7:41:48 AM8/5/08

to fricas...@googlegroups.com

Martin Rubey <martin...@univie.ac.at> writes:

> Ralf Hemmecke <ra...@hemmecke.de> writes:
>
> > > I did not test SBCL changes but they look OK.
> >
> > I still would be more happy, Martin, if these changes were documented in
> > such a way that I understand them. ;-)
>
> Well, I still couldn't get FriCAS/sbcl + Raldorf to work. But it's looking
> better every day.

Not there yet. make runs without complaining now, but fact.as does not work.
I have no idea how to go on. Below fact.as and beginning of the backtrace.

ANY ideas? Note that FOAM-USER::|Nil| doesn't even appear in the backtrace.

|Nil| appears in runtime.lsp and in foam_l.lisp. But I can't make any sense
|out of it.

Martin

-- fact.as ---------------------------------------------------------
#include "axiom"

fact(n: PositiveInteger): PositiveInteger == {
n <= 1 => 1;
res: PositiveInteger := 1;
while n > 1 repeat {
res := res * n;
n := n-1;
}
res
}

--------------------------------------------------------------------

martin@rubey-laptop:~/martin/Axiom$ $AXIOM/bin/AXIOMsys
Checking for foreign routines
AXIOM="/tmp/lib/fricas/target/i686-pc-linux"
spad-lib="/tmp/lib/fricas/target/i686-pc-linux/lib/libspad.so"
foreign routines found
openServer result -2
FriCAS (AXIOM fork) Computer Algebra System
Version: FriCAS 2008-05-28
Timestamp: Friday July 25, 2008 at 19:06:59
-----------------------------------------------------------------------------
Issue )copyright to view copyright notices.
Issue )summary for a summary of useful system commands.
Issue )quit to leave FriCAS and return to shell.
-----------------------------------------------------------------------------

(1) -> )co fact.as

Compiling FriCAS source code from file

/home/martin/martin/Axiom/fact.as using AXIOM-XL compiler and
options
-O -Fasy -Fao -Flsp -laxiom -Mno-ALDOR_W_WillObsolete -DAxiom -Y $AXIOM/algebra
-I $AXIOM/algebra

Use the system command )set compiler args to change these
options.

(1) -> )se br br

(1) -> fact 10

debugger invoked on a SIMPLE-ERROR in thread #<THREAD "initial thread"

{B8AC911}>:
unknown type specifier: FOAM-USER::|Nil|

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

(no restarts: If you didn't do this on purpose, please report it as a bug.)

(SB-KERNEL::%%TYPEP NIL #<SB-KERNEL:UNKNOWN-TYPE FOAM-USER::|Nil|>)
0] backtrace

0: (SB-KERNEL::%%TYPEP NIL #<SB-KERNEL:UNKNOWN-TYPE FOAM-USER::|Nil|>)
1: (FOAM-USER::|C12-runtime-get|
#((#
#S(FOAM-USER::|Struct-axextend-45|
:|Segment-0| (#
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) #
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) #
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) #
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) ...)
:|Matrix-1| (#
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) #
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) #
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) #
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) ...)
:|Vector-2| (#
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) #
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) #
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) #
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) ...)
:|List-3| (#
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) #
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) #
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) #
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) ...)
:|PositiveInteger-4| (#(0 # NIL # # #) 0 #
#S(FOAM-USER::|Struct-runtime-46|
:|fn-0| #
:|n-1| 6)
(# NIL))
:|NonNegativeInteger-5| (#(0 # NIL # # #) 0 #
#S(FOAM-USER::|Struct-runtime-46|
:|fn-0| #
:|n-1| 5)
(# NIL))
:|UniversalSegment-6| (#
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) #
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) #
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) #
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) ...)
:|Integer-7| (#(0 # NIL # # #) 0 #
#S(FOAM-USER::|Struct-runtime-46| :|fn-0| # :|n-1| 4)
(# NIL))
:|SingleInteger-8| (#(0 # NIL # # #) 0 #
#S(FOAM-USER::|Struct-runtime-46|
:|fn-0| #
:|n-1| 2)
(# NIL))
:|Symbol-9| (#(0 # NIL # # #) 0 #
#S(FOAM-USER::|Struct-runtime-46| :|fn-0| # :|n-1| 1)
(# NIL))
:|BuiltinArray-10| (#(0 # NIL # # #) 0 #
#S(FOAM-USER::|Struct-runtime-46|
:|fn-0| #
:|n-1| 8)
(# NIL))
:|error-11| (#
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) #
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) #
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) #
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) ...)
...)
NIL)
NIL 0 NIL
#(1 1
#((#(0 # NIL # # #) 0 #
#S(FOAM-USER::|Struct-runtime-46| :|fn-0| # :|n-1| 6) (# NIL))))
NIL NIL NIL NIL 0 9
#(0 #(15 15 #(NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL ...))
#(15 15 #(NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL ...)) 15)
...)
(#(0
(#
#S(FOAM-USER::|Struct-runtime-51|
:|rtAssertMessage-0| (# # NIL)
:|dbgPaused?-1| NIL
:|rtDebugPaused!-2| (# # NIL)
:|rtDebugPaused?-3| (# # NIL)
:|rtDebugStep-4| (# # NIL)
:|rtDebugCall-5| (# # NIL)
:|rtDebugCatch-6| (# # NIL)
:|rtDebugThrow-7| (# # NIL)
:|rtDebugAssign-8| (# # NIL)
:|rtDebugExit-9| (# # NIL)
:|rtDebugReturn-10| (# # NIL)
:|rtDebugInside-11| (# # NIL)
...)
NIL)
NIL
(#
#S(FOAM-USER::|Struct-runtime-51|
:|rtAssertMessage-0| (# # NIL)
:|dbgPaused?-1| NIL
:|rtDebugPaused!-2| (# # NIL)
:|rtDebugPaused?-3| (# # NIL)
:|rtDebugStep-4| (# # NIL)
:|rtDebugCall-5| (# # NIL)
:|rtDebugCatch-6| (# # NIL)
:|rtDebugThrow-7| (# # NIL)
:|rtDebugAssign-8| (# # NIL)
:|rtDebugExit-9| (# # NIL)
:|rtDebugReturn-10| (# # NIL)
:|rtDebugInside-11| (# # NIL)
...)
NIL)
(#
#S(FOAM-USER::|Struct-runtime-51|
:|rtAssertMessage-0| (# # NIL)
:|dbgPaused?-1| NIL
:|rtDebugPaused!-2| (# # NIL)
:|rtDebugPaused?-3| (# # NIL)
:|rtDebugStep-4| (# # NIL)
:|rtDebugCall-5| (# # NIL)
:|rtDebugCatch-6| (# # NIL)
:|rtDebugThrow-7| (# # NIL)
:|rtDebugAssign-8| (# # NIL)
:|rtDebugExit-9| (# # NIL)
:|rtDebugReturn-10| (# # NIL)
:|rtDebugInside-11| (# # NIL)
...)
NIL)
(#
#S(FOAM-USER::|Struct-runtime-51|
:|rtAssertMessage-0| (# # NIL)
:|dbgPaused?-1| NIL
:|rtDebugPaused!-2| (# # NIL)
:|rtDebugPaused?-3| (# # NIL)
:|rtDebugStep-4| (# # NIL)
:|rtDebugCall-5| (# # NIL)
:|rtDebugCatch-6| (# # NIL)
:|rtDebugThrow-7| (# # NIL)
:|rtDebugAssign-8| (# # NIL)
:|rtDebugExit-9| (# # NIL)
:|rtDebugReturn-10| (# # NIL)
:|rtDebugInside-11| (# # NIL)
...)
NIL))
1
#(0
(#
#S(FOAM-USER::|Struct-runtime-51|
:|rtAssertMessage-0| (# # NIL)
:|dbgPaused?-1| NIL
:|rtDebugPaused!-2| (# # NIL)
:|rtDebugPaused?-3| (# # NIL)
:|rtDebugStep-4| (# # NIL)
:|rtDebugCall-5| (# # NIL)
:|rtDebugCatch-6| (# # NIL)
:|rtDebugThrow-7| (# # NIL)
:|rtDebugAssign-8| (# # NIL)
:|rtDebugExit-9| (# # NIL)
:|rtDebugReturn-10| (# # NIL)
:|rtDebugInside-11| (# # NIL)
...)
NIL)
NIL
(#
#S(FOAM-USER::|Struct-runtime-51|
:|rtAssertMessage-0| (# # NIL)
:|dbgPaused?-1| NIL
:|rtDebugPaused!-2| (# # NIL)
:|rtDebugPaused?-3| (# # NIL)
:|rtDebugStep-4| (# # NIL)
:|rtDebugCall-5| (# # NIL)
:|rtDebugCatch-6| (# # NIL)
:|rtDebugThrow-7| (# # NIL)
:|rtDebugAssign-8| (# # NIL)
:|rtDebugExit-9| (# # NIL)
:|rtDebugReturn-10| (# # NIL)
:|rtDebugInside-11| (# # NIL)
...)
NIL)
(#
#S(FOAM-USER::|Struct-runtime-51|
:|rtAssertMessage-0| (# # NIL)
:|dbgPaused?-1| NIL
:|rtDebugPaused!-2| (# # NIL)
:|rtDebugPaused?-3| (# # NIL)
:|rtDebugStep-4| (# # NIL)
:|rtDebugCall-5| (# # NIL)
:|rtDebugCatch-6| (# # NIL)
:|rtDebugThrow-7| (# # NIL)
:|rtDebugAssign-8| (# # NIL)
:|rtDebugExit-9| (# # NIL)
:|rtDebugReturn-10| (# # NIL)
:|rtDebugInside-11| (# # NIL)
...)
NIL)
(#
#S(FOAM-USER::|Struct-runtime-51|
:|rtAssertMessage-0| (# # NIL)
:|dbgPaused?-1| NIL
:|rtDebugPaused!-2| (# # NIL)
:|rtDebugPaused?-3| (# # NIL)
:|rtDebugStep-4| (# # NIL)
:|rtDebugCall-5| (# # NIL)
:|rtDebugCatch-6| (# # NIL)
:|rtDebugThrow-7| (# # NIL)
:|rtDebugAssign-8| (# # NIL)
:|rtDebugExit-9| (# # NIL)
:|rtDebugReturn-10| (# # NIL)
:|rtDebugInside-11| (# # NIL)
...)
NIL))
. #((#
#S(FOAM-USER::|Struct-axextend-45|
:|Segment-0| (# # # # # # # # # # # # ...)
:|Matrix-1| (# # # # # # # # # # # # ...)
:|Vector-2| (# # # # # # # # # # # # ...)
:|List-3| (# # # # # # # # # # # # ...)
:|PositiveInteger-4| (# 0 # # #)
:|NonNegativeInteger-5| (# 0 # # #)
:|UniversalSegment-6| (# # # # # # # # # # # # ...)
:|Integer-7| (# 0 # # #)
:|SingleInteger-8| (# 0 # # #)
:|Symbol-9| (# 0 # # #)
:|BuiltinArray-10| (# 0 # # #)
:|error-11| (# # # # # # # # # # # # ...)
...)
NIL)
#((#
#S(FOAM-USER::|Struct-axextend-45|
:|Segment-0| #
:|Matrix-1| #
:|Vector-2| #
:|List-3| #
:|PositiveInteger-4| #
:|NonNegativeInteger-5| #
:|UniversalSegment-6| #
:|Integer-7| #
:|SingleInteger-8| #
:|Symbol-9| #
:|BuiltinArray-10| #
:|error-11| #
...)
NIL)
#((# # NIL) #(# # 0 # NIL NIL NIL NIL NIL 0 10 # ...) 0 #(2 2 #) NIL
NIL NIL NIL NIL 0 10 #(0 # # 15) ...)
0 #(2 2 #(# #)) NIL NIL NIL NIL NIL 0 10
#(0 #(15 15 #) #(15 15 #) 15) ...)
0 #(2 2 #((# . #) (# 0 # # #))) NIL NIL NIL NIL NIL 0 10
#(0 #(15 15 #(NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL ...))
#(15 15 #(NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL ...)) 15)
...))
200090
965468232
(NIL)
NIL
(#S(FOAM-USER::|Struct-runtime-51|
:|rtAssertMessage-0| (#
#S(FOAM-USER::|Struct-runtime-51|
:|rtAssertMessage-0| (# # NIL)
:|dbgPaused?-1| NIL
:|rtDebugPaused!-2| (# # NIL)
:|rtDebugPaused?-3| (# # NIL)
:|rtDebugStep-4| (# # NIL)
:|rtDebugCall-5| (# # NIL)
:|rtDebugCatch-6| (# # NIL)
:|rtDebugThrow-7| (# # NIL)
:|rtDebugAssign-8| (# # NIL)
:|rtDebugExit-9| (# # NIL)
:|rtDebugReturn-10| (# # NIL)
:|rtDebugInside-11| (# # NIL)
...)
NIL)
:|dbgPaused?-1| NIL
:|rtDebugPaused!-2| (#
#S(FOAM-USER::|Struct-runtime-51|
:|rtAssertMessage-0| (# # NIL)
:|dbgPaused?-1| NIL
:|rtDebugPaused!-2| (# # NIL)
:|rtDebugPaused?-3| (# # NIL)
:|rtDebugStep-4| (# # NIL)
:|rtDebugCall-5| (# # NIL)
:|rtDebugCatch-6| (# # NIL)
:|rtDebugThrow-7| (# # NIL)
:|rtDebugAssign-8| (# # NIL)
:|rtDebugExit-9| (# # NIL)
:|rtDebugReturn-10| (# # NIL)
:|rtDebugInside-11| (# # NIL)
...)
NIL)
:|rtDebugPaused?-3| (#
#S(FOAM-USER::|Struct-runtime-51|
:|rtAssertMessage-0| (# # NIL)
:|dbgPaused?-1| NIL
:|rtDebugPaused!-2| (# # NIL)
:|rtDebugPaused?-3| (# # NIL)
:|rtDebugStep-4| (# # NIL)
:|rtDebugCall-5| (# # NIL)
:|rtDebugCatch-6| (# # NIL)
:|rtDebugThrow-7| (# # NIL)
:|rtDebugAssign-8| (# # NIL)
:|rtDebugExit-9| (# # NIL)
:|rtDebugReturn-10| (# # NIL)
:|rtDebugInside-11| (# # NIL)
...)
NIL)
:|rtDebugStep-4| (#
#S(FOAM-USER::|Struct-runtime-51|
:|rtAssertMessage-0| (# # NIL)
:|dbgPaused?-1| NIL
:|rtDebugPaused!-2| (# # NIL)
:|rtDebugPaused?-3| (# # NIL)
:|rtDebugStep-4| (# # NIL)
:|rtDebugCall-5| (# # NIL)
:|rtDebugCatch-6| (# # NIL)
:|rtDebugThrow-7| (# # NIL)
:|rtDebugAssign-8| (# # NIL)
:|rtDebugExit-9| (# # NIL)
:|rtDebugReturn-10| (# # NIL)
:|rtDebugInside-11| (# # NIL)
...)
NIL)
:|rtDebugCall-5| (#
#S(FOAM-USER::|Struct-runtime-51|
:|rtAssertMessage-0| (# # NIL)
:|dbgPaused?-1| NIL
:|rtDebugPaused!-2| (# # NIL)
:|rtDebugPaused?-3| (# # NIL)
:|rtDebugStep-4| (# # NIL)
:|rtDebugCall-5| (# # NIL)
:|..)
NIL)
:|rtDebugCatch-6| (#
#S(FOAM-USER::|Struct-runtime-51|
:|rtAssertMessage-0| (# # NIL)
:|dbgPaused?-1| NIL
:|rtDebugPaused!-2| (# # NIL)
:|rtDebugPaused?-3| (# # NIL)
:|rtDebugStep-4| (# # NIL)
:|rtDebugCall-5| (# # NIL)
:|rtDebugCatch-6| (# # NIL)
:|rtDebugThrow-7| (# # NIL)
:|rtDebugAssign-8| (# # NIL)
:|rtDebugExit-9| (# # NIL)
:|rtDebugReturn-10| (# # NIL)
:|rtDebugInside-11| (# # NIL)
...)
NIL)
:|rtDebugThrow-7| (#
#S(FOAM-USER::|Struct-runtime-51|
:|rtAssertMessage-0| (# # NIL)
:|dbgPaused?-1| NIL
:|rtDebugPaused!-2| (# # NIL)
:|rtDebugPaused?-3| (# # NIL)
:|rtDebugStep-4| (# # NIL)
:|rtDebugCall-5| (# # NIL)
:|rtDebugCatch-6| (# # NIL)
:|rtDebugThrow-7| (# # NIL)
:|rtDebugAssign-8| (# # NIL)
:|rtDebugExit-9| (# # NIL)
:|rtDebugReturn-10| (# # NIL)
:|rtDebugInside-11| (# # NIL)
...)
NIL)
:|rtDebugAssign-8| (#
#S(FOAM-USER::|Struct-runtime-51|
:|rtAssertMessage-0| (# # NIL)
:|dbgPaused?-1| NIL
:|rtDebugPaused!-2| (# # NIL)
:|rtDebugPaused?-3| (# # NIL)
:|rtDebugStep-4| (# # NIL)
:|rtDebugCall-5| (# # NIL)
:|rtDebugCatch-6| (# # NIL)
:|rtDebugThrow-7| (# # NIL)
:|rtDebugAssign-8| (# # NIL)
:|rtDebugExit-9| (# # NIL)
:|rtDebugReturn-10| (# # NIL)
:|rtDebugInside-11| (# # NIL)
...)
NIL)
:|rtDebugExit-9| (#
#S(FOAM-USER::|Struct-runtime-51|
:|rtAssertMessage-0| (# # NIL)
:|dbgPaused?-1| NIL
:|rtDebugPaused!-2| (# # NIL)
:|rtDebugPaused?-3| (# # NIL)
:|rtDebugStep-4| (# # NIL)
:|rtDebugCall-5| (# # NIL)
:|rtDebugCatch-6| (# # NIL)
:|rtDebugExit-9| (# # NIL)
:|rtDebugReturn-10| (# # NIL)
:|rtDebugInside-11| (# # NIL)
...)
NIL)
:|rtDebugInside-11| (#
#S(FOAM-USER::|Struct-runtime-51|
:|rtAssertMessage-0| (# # NIL)
:|dbgPaused?-1| NIL
:|rtDebugPaused!-2| (# # NIL)
:|rtDebugPaused?-3| (# # NIL)
:|rtDebugStep-4| (# # NIL)
:|rtDebugCall-5| (# # NIL)
:|rtDebugCatch-6| (# # NIL)
:|rtDebugThrow-7| (# # NIL)
:|rtDebugAssign-8| (# # NIL)
:|rtDebugExit-9| (# # NIL)
:|rtDebugReturn-10| (# # NIL)
:|rtDebugInside-11| (# # NIL)
...)
NIL)
...)
NIL))
2: (FOAM-USER::|C17-runtime-getExtend|
#((#
#S(FOAM-USER::|Struct-axextend-45|
:|Segment-0| (#
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) #
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) #
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) #
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) ...)
:|Matrix-1| (#
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) #
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) #
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) #
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) ...)
:|Vector-2| (#
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) #
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) #
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) #
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) ...)
:|List-3| (#
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| #
:|flag-1| NIL
:|self-2| #)
(# NIL) #
#S(FOAM-USER::|Struct- # # # # # # # # # # ...)
:|PositiveInteger-4| (# 0 # # #)
:|NonNegativeInteger-5| (# 0 # # #)
:|UniversalSegment-6| (# # # #
(#S(FOAM-USER::|Struct-runtime-51|
:|rtAssertMessage-0| #
:|dbgPaused?-1| NIL
:|rtDebugPaused!-2| #
:|rtDebugPaused?-3| #
:|rtDebugStep-4| #
:|rtDebugCall-5| #
:|rtDebugCatch-6| #
:|rtDebugThrow-7| #
:|rtDebugAssign-8| #
:|rtDebugExit-9| #
:|rtDebugReturn-10| #
:|rtDebugInside-11| #
...)
NIL)
#
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| (# # #)
:|flag-1| NIL
:|self-2| (# # # # # # # # # # # # ...))
(#S(FOAM-USER::|Struct-runtime-51|
:|rtAssertMessage-0| #
:|dbgPaused?-1| NIL
:|rtDebugPaused!-2| #
:|rtDebugPaused?-3| #
:|rtDebugStep-4| #
:|rtDebugCall-5| #
:|rtDebugCatch-6| #
:|rtDebugThrow-7| #
:|rtDebugAssign-8| #
:|rtDebugExit-9| #
:|rtDebugReturn-10| #
:|rtDebugInside-11| #
...)
NIL)
...)
:<=-2 (#
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| (# # #)
:|flag-1| NIL
:|self-2| (# # # # # # # # # # # # ...))
(#S(FOAM-USER::|Struct-runtime-51|
:|rtAssertMessage-0| #
:|dbgPaused?-1| NIL
:|rtDebugPaused!-2| #
:|rtDebugPaused?-3| #
:|rtDebugStep-4| #
:|rtDebugCall-5| #
:|rtDebugCatch-6| #
:|rtDebugThrow-7| #
:|rtDebugAssign-8| #
:|rtDebugExit-9| #
:|rtDebugReturn-10| #
:|rtDebugInside-11| #
...)
NIL)
#
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| (# # #)
:|flag-1| NIL
:|self-2| (# # # # # # # # # # # # ...))
(#S(FOAM-USER::|Struct-runtime-51|
:|rtAssertMessage-0| #
:|dbgPaused?-1| NIL
:|rtDebugPaused!-2| #
:|rtDebugPaused?-3| #
:|rtDebugStep-4| #
:|rtDebugCall-5| #
:|rtDebugCatch-6| #
:|rtDebugThrow-7| #
:|rtDebugAssign-8| #
:|rtDebugExit-9| #
:|rtDebugReturn-10| #
:|rtDebugInside-11| #
...)
NIL)
#
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| (# # #)
:|flag-1| NIL
:|self-2| (# # # # # # # # # # # # ...))
(#S(FOAM-USER::|Struct-runtime-51|
:|rtAssertMessage-0| #
:|dbgPaused?-1| NIL
:|rtDebugPaused!-2| #
:|rtDebugPaused?-3| #
:|rtDebugStep-4| #
:|rtDebugCall-5| #
:|rtDebugCatch-6| #
:|rtDebugThrow-7| #
:|rtDebugAssign-8| #
:|rtDebugExit-9| #
:|rtDebugReturn-10| #
:|rtDebugInside-11| #
...)
NIL)
#
#S(FOAM-USER::|Struct-runtime-50|
:|getter-0| (# # #)
:|flag-1| NIL
:|self-2| (# # # # # # # # # # # # ...))
(#S(FOAM-USER::|Struct-runtime-51|
:|rtAssertMessage-0| #
:|dbgPaused?-1| NIL
:|rtDebugPaused!-2| #
:|rtDebugPaused?-3| #
:|rtDebugStep-4| #
:|rtDebugCall-5| #
:|rtDebugCatch-6|

Gregory Vanuxem

unread,

Aug 5, 2008, 9:17:41 AM8/5/08

to fricas...@googlegroups.com

Hello Martin,

Le mardi 05 août 2008 à 13:41 +0200, Martin Rubey a écrit :
>
> Martin Rubey <martin...@univie.ac.at> writes:
>
> > Ralf Hemmecke <ra...@hemmecke.de> writes:
> >
> > > > I did not test SBCL changes but they look OK.
> > >
> > > I still would be more happy, Martin, if these changes were documented in
> > > such a way that I understand them. ;-)
> >
> > Well, I still couldn't get FriCAS/sbcl + Raldorf to work. But it's looking
> > better every day.
>
> Not there yet. make runs without complaining now, but fact.as does not work.
> I have no idea how to go on. Below fact.as and beginning of the backtrace.
>
> ANY ideas? Note that FOAM-USER::|Nil| doesn't even appear in the backtrace.
>
> |Nil| appears in runtime.lsp and in foam_l.lisp. But I can't make any sense
> |out of it.

I think |Nil| have to be exported from the FOAM package (foam_l.lisp):

Greg

Martin Rubey

unread,

Aug 5, 2008, 9:34:47 AM8/5/08

to fricas...@googlegroups.com

Gregory Vanuxem <g.va...@orange.fr> writes:

WOW! That did it - nearly:

(1) -> )re ../lib/test
)se me au off

l: SetSpecies ACINT := set [i::ACINT for i in 1..4]

(1) [1,2,3,4]
Type: SetSpecies ACInteger

[structures(l)$Partition ACINT]$ACLIST(Partition ACINT)

(2)
[[[1, 2, 3, 4]], [[1, 2, 3], [4]], [[1, 2, 4], [3]], [[1, 2], [3, 4]],
[[1, 2], [3], [4]], [[1, 3, 4], [2]], [[1, 3], [2, 4]], [[1, 3], [2], [4]],
[[1, 4], [2, 3]], [[1], [2, 3, 4]], [[1], [2, 3], [4]], [[1, 4], [2], [3]],
[[1], [2, 4], [3]], [[1], [2], [3, 4]], [[1], [2], [3], [4]]]
Type: ACList Partition ACInteger

m: MultiSet ACINT := multiset([1$ACINT for i in 1..3]::ACList ACINT)

3
(3) [1 ]
Type: MultiSet ACInteger

[isomorphismTypes(m)$MultiSet(ACINT)]$ACList(MultiSet ACINT)

3
(4) [[1 ]]
Type: ACList MultiSet ACInteger

T := Interpret([parse "Plus(SingletonSpecies, Times(Self,Self))"], ACInteger);

Type: Domain

IsoT := ACIsomorphismType(ACINT, T)

(6)
ACIsomorphismType(ACInteger,Interpret([CONCATPlusPARENAGGLSTCONCATNOTHINGSing
letonSpeciesCONCATTimesPARENAGGLSTCONCATNOTHINGSelfCONCATNOTHINGSelf],ACInteg
er))
Type: Domain

[isomorphismTypes(m)$IsoT]$ACList(IsoT)

>> System error:
The value |Interpret| is not of type (SIMPLE-ARRAY T (*)).

-- comment --------------------------------------------------------------------

|Interpret| is the following aldor function (a domain, actually):

Interpret(p: List ExpressionTree, L: LabelType): CombinatorialSpecies L == {
import from InterpretingTools, LabelSpecies, List LabelSpecies;
l: LabelSpecies := first interpret p;
(coerce(l)$LabelSpecies)(L) add;
}

Of course, that's a hack to deal with the problem that Axiom treats functions
that return types specially.

Another idea?
-------------------------------------------------------------------------------

(7) -> )se br br
(7) -> [isomorphismTypes(m)$IsoT]$ACList(IsoT)

debugger invoked on a TYPE-ERROR in thread #<THREAD "initial thread"
{BC06B81}>:
The value |Interpret| is not of type (SIMPLE-ARRAY T (*)).

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

(no restarts: If you didn't do this on purpose, please report it as a bug.)

0: (FOAM-USER::|C63-runtime-domainHash!|
(|Interpret|
((1 (#(0 # NIL # # #) . #(# # 499013767 NIL NIL # # # # 0 367 # ...))
(0 1 . "SingletonSpecies") (1 (# . #) (0 1 . "Self") (0 1 . "Self"))))
(|ACInteger|))
#<unavailable argument>)
1: (SB-EVAL::EVAL-ARGS
((THE FOAM:|SInt|
(FOAM:|CCall| FOAM-USER::|G-domainHash!|
(FOAM:|Lex| FOAM-USER::|Struct-csspecies-14-F-1| 1
FOAM-USER::|l1|)))
(THE FOAM:|SInt|
(FOAM:|SIntShiftUp|
(FOAM:|SIntAnd| (FOAM:|SIntPlusMod| # # #)
(THE FOAM:|SInt| 16777215))
(THE FOAM:|SInt| 6))))
#<SB-EVAL::ENV {C687411}>)
2: (SB-EVAL::%EVAL
(+
(THE FOAM:|SInt|
(FOAM:|CCall| FOAM-USER::|G-domainHash!|
(FOAM:|Lex| FOAM-USER::|Struct-csspecies-14-F-1| 1
FOAM-USER::|l1|)))
(THE FOAM:|SInt|
(FOAM:|SIntShiftUp|
(FOAM:|SIntAnd| (FOAM:|SIntPlusMod| # # #)
(THE FOAM:|SInt| 16777215))
(THE FOAM:|SInt| 6))))
#<SB-EVAL::ENV {C687411}>)
3: (SB-EVAL::EVAL-ARGS
((+
(THE FOAM:|SInt|
(FOAM:|CCall| FOAM-USER::|G-domainHash!|
(FOAM:|Lex| FOAM-USER::|Struct-csspecies-14-F-1| 1
FOAM-USER::|l1|)))
(THE FOAM:|SInt|
(FOAM:|SIntShiftUp| (FOAM:|SIntAnd| # #) (THE FOAM:|SInt| 6))))
(THE FOAM:|SInt| (THE FOAM:|SInt| 1073741789)))
#<SB-EVAL::ENV {C687411}>)
4: (SB-EVAL::%EVAL
(MOD
(+
(THE FOAM:|SInt|
(FOAM:|CCall| FOAM-USER::|G-domainHash!|
(FOAM:|Lex| FOAM-USER::|Struct-csspecies-14-F-1| 1
FOAM-USER::|l1|)))
(THE FOAM:|SInt|
(FOAM:|SIntShiftUp| (FOAM:|SIntAnd| # #) (THE FOAM:|SInt| 6))))
(THE FOAM:|SInt| (THE FOAM:|SInt| 1073741789)))
#<SB-EVAL::ENV {C687411}>)
5: (SB-EVAL::EVAL-ARGS
(FOAM::FUN FOAM-USER::|P0-domain|
(FOAM:|SIntPlusMod|
(FOAM:|CCall| FOAM-USER::|G-domainHash!|
(FOAM:|Lex| FOAM-USER::|Struct-csspecies-14-F-1| 1
FOAM-USER::|l1|))
(FOAM:|SIntShiftUp|
(FOAM:|SIntAnd| (FOAM:|SIntPlusMod| # # #) (THE FOAM:|SInt| 16777215))
(THE FOAM:|SInt| 6))
(THE FOAM:|SInt| 1073741789))
FOAM::ENV)
#<SB-EVAL::ENV {C687411}>)
6: (SB-EVAL::%EVAL
(FUNCALL FOAM::FUN FOAM-USER::|P0-domain|
(FOAM:|SIntPlusMod|
(FOAM:|CCall| FOAM-USER::|G-domainHash!|
(FOAM:|Lex| FOAM-USER::|Struct-csspecies-14-F-1| 1
FOAM-USER::|l1|))
(FOAM:|SIntShiftUp|
(FOAM:|SIntAnd| (FOAM:|SIntPlusMod| # # #)
(THE FOAM:|SInt| 16777215))
(THE FOAM:|SInt| 6))
(THE FOAM:|SInt| 1073741789))
FOAM::ENV)
#<SB-EVAL::ENV {C687411}>)
7: (SB-EVAL::EVAL-PROGN
((SETQ FOAM-USER::|l0| NIL)
(SETQ FOAM-USER::|e0| (FOAM:|MakeEnv| FOAM-USER::|e1| FOAM-USER::|l0|))
(SETQ FOAM-USER::|l1| (FOAM:|EnvLevel| FOAM-USER::|e1|))
(FOAM:|CCall| FOAM-USER::|G-domainAddNameFn!| FOAM-USER::|P0-domain|
(FOAM:|Clos| FOAM-USER::|e0|
FOAM-USER::|C16-csspecies-addNameFn|))
(FOAM:|CCall| FOAM-USER::|G-domainAddHash!| FOAM-USER::|P0-domain|
(FOAM:|SIntPlusMod|
(FOAM:|CCall| FOAM-USER::|G-domainHash!|
(FOAM:|Lex|
FOAM-USER::|Struct-csspecies-14-F-1| 1
FOAM-USER::|l1|))
(FOAM:|SIntShiftUp| (FOAM:|SIntAnd| # #)
(THE FOAM:|SInt| 6))
(THE FOAM:|SInt| 1073741789)))
(FOAM:BLOCK-RETURN FOAM-USER::|C15-csspecies-addLevel0|
(FOAM:|Clos| FOAM-USER::|e0|
FOAM-USER::|C17-csspecies-addLevel1|)))
#<SB-EVAL::ENV {C686A29}>)
8: (SB-EVAL::EVAL-BLOCK
(FOAM-USER::|C15-csspecies-addLevel0|
(FOAM:TYPED-LET
((FOAM-USER::|l0| FOAM:|Level|) (FOAM-USER::|e0| FOAM:|Env|)
(FOAM-USER::|l1| FOAM:|Level|))
(SETQ FOAM-USER::|l0| NIL)
(SETQ FOAM-USER::|e0| (FOAM:|MakeEnv| FOAM-USER::|e1| FOAM-USER::|l0|))
(SETQ FOAM-USER::|l1| (FOAM:|EnvLevel| FOAM-USER::|e1|))
(FOAM:|CCall| FOAM-USER::|G-domainAddNameFn!| FOAM-USER::|P0-domain|
(FOAM:|Clos| FOAM-USER::|e0|
FOAM-USER::|C16-csspecies-addNameFn|))
(FOAM:|CCall| FOAM-USER::|G-domainAddHash!| FOAM-USER::|P0-domain|
(FOAM:|SIntPlusMod|
(FOAM:|CCall| FOAM-USER::|G-domainHash!| #)
(FOAM:|SIntShiftUp| # #) (THE FOAM:|SInt| 1073741789)))
(FOAM:BLOCK-RETURN FOAM-USER::|C15-csspecies-addLevel0|
(FOAM:|Clos| FOAM-USER::|e0|
FOAM-USER::|C17-csspecies-addLevel1|))))
#<SB-EVAL::ENV {C6866A1}>)
9: (FOAM-USER::|C13-runtime-hash|
#((#<INTERPRETED-FUNCTION C15-csspecies-addLevel0>
#S(FOAM-USER::|Struct-csspecies-14|
01

#(0 #(15 15 #(NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL ...))
#(15 15 #(NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL ...)) 15)
...))

(#(0
(#

Ralf Hemmecke

unread,

Aug 5, 2008, 9:49:46 AM8/5/08

to fricas...@googlegroups.com, aldor-combinat-devel

Hi Martin,

Nice to see that you work hard on this.

> (6)
> ACIsomorphismType(ACInteger,Interpret([CONCATPlusPARENAGGLSTCONCATNOTHINGSing
> letonSpeciesCONCATTimesPARENAGGLSTCONCATNOTHINGSelfCONCATNOTHINGSelf],ACInteg
> er))
> Type: Domain
>
> [isomorphismTypes(m)$IsoT]$ACList(IsoT)
>
>
> >> System error:
> The value |Interpret| is not of type (SIMPLE-ARRAY T (*)).
>
> -- comment --------------------------------------------------------------------
>
> |Interpret| is the following aldor function (a domain, actually):
>
> Interpret(p: List ExpressionTree, L: LabelType): CombinatorialSpecies L == {
> import from InterpretingTools, LabelSpecies, List LabelSpecies;
> l: LabelSpecies := first interpret p;
> (coerce(l)$LabelSpecies)(L) add;
> }
>
> Of course, that's a hack to deal with the problem that Axiom treats functions
> that return types specially.

But here you are going really really far. We have already discussed it
on the aldor-combinat mailing list.

What you want is that Aldor hopefully produces something reasonable out
of that. Actually, you should have raised this problem during the Aldor
& Axiom Workshop when Stephen was present. It's a pity that we forgot
that. But it seems the Aldor compiler is underspecified in dealing
recursive definitions of domains at runtime.

But wait, your are actually not doing that... well, you have to show the
'interpret' function (lower case).

Ralf

Martin Rubey

unread,

Aug 5, 2008, 10:19:46 AM8/5/08

to fricas...@googlegroups.com, aldor-combinat-devel

Ralf Hemmecke <ra...@hemmecke.de> writes:

> > |Interpret| is the following aldor function (a domain, actually):
> >
> > Interpret(p: List ExpressionTree, L: LabelType): CombinatorialSpecies L == {
> > import from InterpretingTools, LabelSpecies, List LabelSpecies;
> > l: LabelSpecies := first interpret p;
> > (coerce(l)$LabelSpecies)(L) add;
> > }
> >
> > Of course, that's a hack to deal with the problem that Axiom treats functions
> > that return types specially.
>
> But here you are going really really far. We have already discussed it on the
> aldor-combinat mailing list.

Well, GCL based FriCAS likes it. Actually, since it's "only" a type error, I
think it should be fixable. And I want the aldor interface to be as robust as
possible. Waldek, Greg, would it help if I recompile the interp directory with
high debug setting?

> But wait, your are actually not doing that... well, you have to show the
> 'interpret' function (lower case).

(only for Ralf, the rest can skip it safely...)

-------------------------------------------------------------------------------
interpret(p: List ExpressionTree): List LabelSpecies == {
import from MachineInteger, LabelSpecies, List LabelSpecies;
A: LabelSpecies == coerce EmptySetSpecies;
res: List LabelSpecies := [A for x in p];
E(i: MachineInteger)(L: LabelType): CombinatorialSpecies(L) ==
(coerce evaluate(p.i, res))(L) add;
for i in 1..#p repeat res.i := coerce E(i);
res;
}
-------------------------------------------------------------------------------

I don't think that this function has much to do with it. Curiously however,

[structures(l)$T]$ACLIST(T)

works. Got it - the problem is elsewhere:

(9) -> S := ACIsomorphismType(ACINT, SetSpecies ACINT)

(9) ACIsomorphismType(ACInteger,SetSpecies ACInteger)
Type: Domain
(10) -> [isomorphismTypes(m)$S]$ACLIST(S)

>> System error:
The value |SetSpecies| is not of type (SIMPLE-ARRAY T (*)).

Here is the definition of ACIsomorphismType (another hack, trying to deal with
functions that return a type...):

ACIsomorphismType(L: LabelType, F: CombinatorialSpecies L):
IsomorphismTypeCategory L == (IsomorphismType$F) add;

(every species F exports an IsomorphismType, which is actually a constant.
FriCAS turns it into a nullary function) Since ordinary fricas functions are
not allowed to return types, I have to provide an accessor type, as above.

Calling

IsoS := IsomorphismType()$SetSpecies(ACINT)

crashes FriCAS.

Martin

NB: Another datapoint: sbcl based aldor interface seems to be *really really*
slow. :-(

Ralf Hemmecke

unread,

Aug 5, 2008, 11:11:49 AM8/5/08

to fricas...@googlegroups.com, aldor-combinat-devel

> (only for Ralf, the rest can skip it safely...)

Only for Martin, the rest can safely skip the following ;-)

> Here is the definition of ACIsomorphismType (another hack, trying to deal with
> functions that return a type...):
>
> ACIsomorphismType(L: LabelType, F: CombinatorialSpecies L):
> IsomorphismTypeCategory L == (IsomorphismType$F) add;
>
> (every species F exports an IsomorphismType, which is actually a constant.
> FriCAS turns it into a nullary function) Since ordinary fricas functions are
> not allowed to return types, I have to provide an accessor type, as above.
>
> Calling
>
> IsoS := IsomorphismType()$SetSpecies(ACINT)
>
> crashes FriCAS.

Well, I don't know whether any Axiom flavour can deal with it, but you
remember that I don't like that kind of treatment of isomorphism types
in aldor-combinat, anyway. Not yet, at least.

I will try to deal with removing ACList, ACINT, etc. first and then I
might have time to deal with isomorphism types or multisort species.
Hopefully, my computerless vacation time will not come earlier. ;-)

Ralf

Martin Rubey

unread,

Aug 5, 2008, 11:21:40 AM8/5/08

to Ralf Hemmecke, fricas...@googlegroups.com

Ralf Hemmecke <ra...@hemmecke.de> writes:

> > (only for Ralf, the rest can skip it safely...)
>
> Only for Martin, the rest can safely skip the following ;-)
>
> > Here is the definition of ACIsomorphismType (another hack, trying to deal with
> > functions that return a type...):
> >
> > ACIsomorphismType(L: LabelType, F: CombinatorialSpecies L):
> > IsomorphismTypeCategory L == (IsomorphismType$F) add;
> >
> > (every species F exports an IsomorphismType, which is actually a constant.
> > FriCAS turns it into a nullary function) Since ordinary fricas functions are
> > not allowed to return types, I have to provide an accessor type, as above.
> >
> > Calling
> >
> > IsoS := IsomorphismType()$SetSpecies(ACINT)
> >
> > crashes FriCAS.
>
> Well, I don't know whether any Axiom flavour can deal with it, but you
> remember that I don't like that kind of treatment of isomorphism types
> in aldor-combinat, anyway. Not yet, at least.

My point is not that much that this way of introducing isomorphism types does
not work, but rather that the aldor interface is not fully functional when we
use sbcl. I guess it would be worthwhile to check whether something like

F(T: MyType): MyCat == (foo$T) add;

works at all.

Martin

Ralf Hemmecke

unread,

Aug 5, 2008, 11:33:38 AM8/5/08

to Martin Rubey, fricas...@googlegroups.com, aldor-l

> My point is not that much that this way of introducing isomorphism types does
> not work, but rather that the aldor interface is not fully functional when we
> use sbcl. I guess it would be worthwhile to check whether something like
>
> F(T: MyType): MyCat == (foo$T) add;
>
> works at all.

You mean that looks like an Aldor problem? I don't think that the Aldor
specification forbids such construction. In fact, if

MyType: Category == with {
foo: MyCat;
...
}

then I would guess that the only problem is the Aldor compiler but not
the language. Have you checked a simple example like that?

Ralf

Martin Rubey

unread,

Aug 5, 2008, 12:21:35 PM8/5/08

to fricas...@googlegroups.com, Martin Rubey, aldor-l

Ralf Hemmecke <ra...@hemmecke.de> writes:

> > My point is not that much that this way of introducing isomorphism types
> > does not work, but rather that the aldor interface is not fully functional
> > when we use sbcl. I guess it would be worthwhile to check whether
> > something like
> >
> > F(T: MyType): MyCat == (foo$T) add;
> >
> > works at all.
>
> You mean that looks like an Aldor problem?

NO! I should have said:

works at all in FriCAS-sbcl + Ralfdor

Martin

Martin Rubey

unread,

Aug 5, 2008, 12:44:38 PM8/5/08

to Martin Rubey, fricas...@googlegroups.com

I just checked a very simple example, but that one works.

I wonder what the difference to the other one is. If nobody has any ideas, I
guess I'll have to do some tedious narrowing...

Martin

-- test.as --------------------------------------------------------------------
#include "axiom"

define ExportARingCat: Category == with {
MyRing: Ring
}

ExportARingDom: ExportARingCat == add {
MyRing: Ring == Integer
}

GetRing(F: ExportARingCat): Ring == (MyRing$F) add;
-------------------------------------------------------------------------------

(1) -> )sh ExportARingDom
ExportARingDom is a domain constructor
Abbreviation for ExportARingDom is EXPORTA
This constructor is exposed in this frame.
------------------------------- Operations --------------------------------
MyRing : () -> Ring

(1) -> R := GetRing(ExportARingDom)

(1) GetRing ExportARingDom
Type: Domain
(2) -> )sh R
GetRing ExportARingDom is a domain constructor.
Abbreviation for GetRing is GETRING
This constructor is exposed in this frame.
------------------------------- Operations --------------------------------

?*? : (Integer,%) -> %

?*? : (PositiveInteger,%) -> %

?*? : (%,%) -> %

?**? : (%,PositiveInteger) -> %

?+? : (%,%) -> %

?-? : (%,%) -> %

-? : % -> %

0 : () -> %

1 : () -> %

?=? : (%,%) -> Boolean

?^? : (%,PositiveInteger) -> %

coerce : % -> OutputForm

coerce : Integer -> %

hash : % -> SingleInteger

latex : % -> String

one? : % -> Boolean

sample : () -> %

zero? : % -> Boolean

?~=? : (%,%) -> Boolean

?*? : (NonNegativeInteger,%) -> %
?**? : (%,NonNegativeInteger) -> %
?^? : (%,NonNegativeInteger) -> %
characteristic : () -> NonNegativeInteger
recip : % -> Union(value1: %,failed: Enumeration failed)
subtractIfCan : (%,%) -> Union(value1: %,failed: Enumeration failed)

(2) -> 1$R

(2) 1
Type: GetRing ExportARingDom
(3) -> 1$R + 1$R

(3) 2
Type: GetRing ExportARingDom

-------------------------------------------------------------------------------

Gregory Vanuxem

unread,

Aug 5, 2008, 3:09:51 PM8/5/08

to fricas...@googlegroups.com, Ralf Hemmecke

Hello Martin, *

Le mardi 05 août 2008 à 16:19 +0200, Martin Rubey a écrit :
>
> Ralf Hemmecke <ra...@hemmecke.de> writes:
>
> > > |Interpret| is the following aldor function (a domain, actually):
> > >
> > > Interpret(p: List ExpressionTree, L: LabelType): CombinatorialSpecies L == {
> > > import from InterpretingTools, LabelSpecies, List LabelSpecies;
> > > l: LabelSpecies := first interpret p;
> > > (coerce(l)$LabelSpecies)(L) add;
> > > }
> > >
> > > Of course, that's a hack to deal with the problem that Axiom treats functions
> > > that return types specially.
> >
> > But here you are going really really far. We have already discussed it on the
> > aldor-combinat mailing list.
>
> Well, GCL based FriCAS likes it. Actually, since it's "only" a type error, I
> think it should be fixable. And I want the aldor interface to be as robust as
> possible. Waldek, Greg, would it help if I recompile the interp directory with
> high debug setting?

Yes, I think so, but I would not be surprised if this involved deep
internals. In fact I don't know. I have tried to build the
aldor-interface branch this afternoon, the build process stopped because
of the problem of file extension (I use SBCL). I removed several file in
src/aldor/tmp and broke the build process... Hmmm... It's a pity,
building the aldor-interface take a lot of time.

I was not able to follow closely the discussion on this file extension
problem, Ralf, do you plan to fixe this issue in the near future?

Many thanks to all of you for your work and sorry for not being able to
help, maybe later.

Greg

Ralf Hemmecke

unread,

Aug 5, 2008, 3:37:31 PM8/5/08

to Gregory Vanuxem, fricas...@googlegroups.com

> I have tried to build the aldor-interface branch this afternoon, the
> build process stopped because of the problem of file extension (I use
> SBCL).

Update. I've added Martin's suggestion of having $(FASLEXT) instead of .o.

Should that be enough for your build with SBCL?

> I removed several file in src/aldor/tmp and broke the build
> process...

Hmm, strange. What did you remove and what is the error?

> Hmmm... It's a pity, building the aldor-interface take a
> lot of time.

Greg, just apply the patch I gave at

http://groups.google.com/group/fricas-devel/browse_thread/thread/e193f5b9fa30a639/f99fe0a78ed3154f?lnk=st&q=#f99fe0a78ed3154f

and the build will be a lot faster. It avoids building intermediate
libraries. (I will certainly apply that patch in the future, but for now
I'd like to have some successful reports of the current version of the
build machinery.

> I was not able to follow closely the discussion on this file
> extension problem, Ralf, do you plan to fixe this issue in the near
> future?

If you tell me exactly what the problem is then I could perhaps fix it.
But I have only moderate knowledge of lisp so I need help with different
versions of LISP and how they behave.

Hope that helps

Ralf

Martin Rubey

unread,

Aug 5, 2008, 4:01:47 PM8/5/08

to fricas...@googlegroups.com, Gregory Vanuxem

Ralf Hemmecke <ra...@hemmecke.de> writes:

> > I have tried to build the aldor-interface branch this afternoon, the
> > build process stopped because of the problem of file extension (I use
> > SBCL).
>
> Update. I've added Martin's suggestion of having $(FASLEXT) instead of .o.
>
> Should that be enough for your build with SBCL?

No. You also need to patch some things in fricas itself. Below is the list of
patches. I don't know when I'll have time to recompile with high debug
settings. But I'll try to find a minimal example, too.

Martin

Index: src/aldor/Makefile.in
===================================================================
--- src/aldor/Makefile.in (revision 336)
+++ src/aldor/Makefile.in (working copy)

@@ -275,8 +275,8 @@
###################################################################
# Runtime - things required to run aldor files
# It is not clear whether actually all files in $(aldor_srcs) are needed.
-runtime_files := $(patsubst %,lib/%.o, runtime $(aldor_srcs))
-$(runtime_files): lib/%.o: lsp/%.lsp
+runtime_files := $(patsubst %,lib/%.$(FASLEXT), runtime $(aldor_srcs))
+$(runtime_files): lib/%.$(FASLEXT): lsp/%.lsp
aldor_lsp_files := $(patsubst %,lsp/%.lsp, $(aldor_srcs))
lsp/runtime.lsp: runtime.ao lsp/.dir
$(ALDOR) -flsp=$@ $<

@@ -289,15 +289,15 @@

$(ALDOR) -flsp=$@ $*.ao
rm $*.ao

-foam_l=$(abs_top_builddir)/src/interp/foam_l.o
-$(runtime_files): lib/%.o: tmp/mko_%.lsp lsp/%.lsp lib/.dir
+foam_l=$(abs_top_builddir)/src/interp/foam_l.$(FASLEXT)
+$(runtime_files): lib/%.$(FASLEXT): tmp/mko_%.lsp lsp/%.lsp lib/.dir
$(INTERPSYS) < $< > tmp/mko_$*.log
test -f $@

tmp/mko_%.lsp:

echo ')fin' > $@

echo '(load "$(foam_l)")' >> $@

- echo '(compile-file "lsp/$*.lsp" :output-file "lib/$*.o")' >> $@
+ echo '(compile-file "$(abs_top_builddir)/src/aldor/lsp/$*.lsp"

:output-file "$(abs_top_builddir)/src/aldor/lib/$*.$(FASLEXT)")' >> $@
echo '(quit)' >> $@

runtimefiles: $(runtime_files)
Index: src/interp/patches.lisp
===================================================================
--- src/interp/patches.lisp (revision 336)
+++ src/interp/patches.lisp (working copy)

@@ -171,12 +171,12 @@
(browseopen)
(|makeConstructorsAutoLoad|)
(let ((asharprootlib (strconc (|getEnv| "AXIOM") "/aldor/lib/")))
- (set-file-getter (strconc asharprootlib "runtime.o"))
- (set-file-getter (strconc asharprootlib "lang.o"))
- (set-file-getter (strconc asharprootlib "attrib.o"))
- (set-file-getter (strconc asharprootlib "axlit.o"))
- (set-file-getter (strconc asharprootlib "minimach.o"))
- (set-file-getter (strconc asharprootlib "axextend.o")))
+ (set-file-getter (strconc asharprootlib "runtime"))
+ (set-file-getter (strconc asharprootlib "lang"))
+ (set-file-getter (strconc asharprootlib "attrib"))
+ (set-file-getter (strconc asharprootlib "axlit"))
+ (set-file-getter (strconc asharprootlib "minimach"))
+ (set-file-getter (strconc asharprootlib "axextend")))
)

(defun whocalled (n) nil) ;; no way to look n frames up the stack

Index: src/interp/foam_l.lisp
===================================================================
--- src/interp/foam_l.lisp (revision 336)
+++ src/interp/foam_l.lisp (working copy)

Index: src/lisp/fricas-package.lisp
===================================================================
--- src/lisp/fricas-package.lisp (revision 336)
+++ src/lisp/fricas-package.lisp (working copy)
@@ -1,14 +1,25 @@
;;; We put this in separate file to avoid problems with compilation.
(eval-when (:execute :compile-toplevel :load-toplevel)
-(if (not (find-package "FRICAS-LISP"))
- (make-package "FRICAS-LISP"
- :use (list (or (find-package "COMMON-LISP")
- "LISP")))))
+ (if (not (find-package "FRICAS-LISP"))
+ (make-package "FRICAS-LISP"
+ :use (list (or (find-package "COMMON-LISP")
+ "LISP")))))
#+:sbcl
(eval-when (:execute :compile-toplevel :load-toplevel)
- (setf SB-IMPL::*DEFAULT-EXTERNAL-FORMAT* :LATIN-1))
+ (setf SB-IMPL::*DEFAULT-EXTERNAL-FORMAT* :LATIN-1))

(in-package "FRICAS-LISP")
+

+;;; Aldor 1.1.0 produces in-package statements with :use options. These can
be
+;;; ignored, so we do not use
+;;; (defpackage package options)
+;;; (in-package package)
+#+sbcl

+(shadow "IN-PACKAGE" "FRICAS-LISP")

+#+sbcl
+(defmacro IN-PACKAGE (package &rest options)
+ `(COMMON-LISP:IN-PACKAGE ,package))
+

(do-symbols (x "FRICAS-LISP") (export (list x)))

(export '(quit chdir |getEnv| |load_quietly| get-current-directory

Martin Rubey

unread,

Aug 5, 2008, 4:50:40 PM8/5/08

to Martin Rubey, fricas...@googlegroups.com, Gregory Vanuxem

Martin Rubey <martin...@univie.ac.at> writes:

> But I'll try to find a minimal example, too.

Here is selfcontained code that breaks the interface in sbcl based
FriCAS. Maybe somebody else can go further...

Martin

martin@rubey-laptop:~/martin/Axiom$ $AXIOM/bin/AXIOMsys
Checking for foreign routines

AXIOM="/tmp/lib/fricas/target/i686-pc-linux/"
spad-lib="/tmp/lib/fricas/target/i686-pc-linux//lib/libspad.so"

foreign routines found
openServer result -2
FriCAS (AXIOM fork) Computer Algebra System
Version: FriCAS 2008-05-28
Timestamp: Friday July 25, 2008 at 19:06:59
-----------------------------------------------------------------------------
Issue )copyright to view copyright notices.
Issue )summary for a summary of useful system commands.
Issue )quit to leave FriCAS and return to shell.
-----------------------------------------------------------------------------

(1) -> )co testa.as

Compiling FriCAS source code from file

/home/martin/martin/Axiom/testa.as using AXIOM-XL compiler and

options
-O -Fasy -Fao -Flsp -laxiom -Mno-ALDOR_W_WillObsolete -DAxiom -Y $AXIOM/algebra
-I $AXIOM/algebra
Use the system command )set compiler args to change these
options.

Compiling Lisp source code from file ./testa.lsp
Issuing )library command for testa
Reading /home/martin/martin/Axiom/testa.asy
Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/bc-matrix.

STYLE-WARNING: redefining |bcMatrix| in DEFUN

Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/bc-misc.

Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/bc-solve.

STYLE-WARNING: redefining |bcSolve| in DEFUN

Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/bc-util.
Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/ht-util.

STYLE-WARNING: redefining |unescapeStringsInForm| in DEFUN

Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/htsetvar.

STYLE-WARNING: redefining |htsv| in DEFUN

Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/ht-root.

Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/br-con.

STYLE-WARNING: redefining |conPage| in DEFUN

Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/br-data.

Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/showimp.
Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/br-op1.

STYLE-WARNING: redefining |dbGetOrigin| in DEFUN

Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/br-op2.
Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/br-search.

Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/br-util.

Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/topics.
Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/br-prof.
Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/br-saturn.
Multiple is now explicitly exposed in frame initial
Multiple will be automatically loaded when needed from
/home/martin/martin/Axiom/testa
IsomorphismTypeCategory is now explicitly exposed in frame initial
IsomorphismTypeCategory will be automatically loaded when needed
from /home/martin/martin/Axiom/testa
ACIsomorphismType is now explicitly exposed in frame initial
ACIsomorphismType will be automatically loaded when needed from
/home/martin/martin/Axiom/testa
CombinatorialSpecies is now explicitly exposed in frame initial
CombinatorialSpecies will be automatically loaded when needed from
/home/martin/martin/Axiom/testa
MultiSet is now explicitly exposed in frame initial
MultiSet will be automatically loaded when needed from
/home/martin/martin/Axiom/testa
SetSpecies is now explicitly exposed in frame initial
SetSpecies will be automatically loaded when needed from
/home/martin/martin/Axiom/testa
(1) -> S := ACIsomorphismType(Integer, SetSpecies Integer)

(1) ACIsomorphismType(Integer,SetSpecies Integer)
Type: Domain
(2) -> m := [bracket(1,3)$Multiple(INT)]::MultiSet INT

LISP output:
((1 . 3))
Type: MultiSet Integer
(3) -> isomorphismTypes(m)$S

>> System error:
The value |SetSpecies| is not of type (SIMPLE-ARRAY T (*)).

(3) ->

--testa.as-----------------------------------------------------------
#include "axiom"

macro LabelType == SetCategory;
macro MachineInteger == SingleInteger;

Multiple(L: LabelType): LabelType with {
bracket: (L, MachineInteger) -> %;
} == add {
Rep == Record(element: L, multiplicity: MachineInteger);
import from Rep, MachineInteger;

bracket(e: L, m: MachineInteger): % == {
per [e, m];
}
multiplicity(x: %): MachineInteger == (rep x).multiplicity;
element(x: %): L == (rep x).element;
(x: %) = (y: %): Boolean == {
element(x) = element(y) and multiplicity(x) = multiplicity(y);
}
coerce(x: %): OutputForm == {
if multiplicity x = 1
then coerce(element x);
else coerce(element x)**coerce(multiplicity x);
}
}

define IsomorphismTypeCategory(L: LabelType): Category == with {
isomorphismTypes: MultiSet L -> List %;
}

ACIsomorphismType(L: LabelType, F: CombinatorialSpecies L):
IsomorphismTypeCategory L == (IsomorphismType$F) add;

define CombinatorialSpecies(L: LabelType): Category == with {
IsomorphismType: IsomorphismTypeCategory L;
}

MultiSet(L: LabelType): IsomorphismTypeCategory(L) with {
coerce: List Multiple L -> %;
} == List Multiple L add {
Rep == List Multiple L; import from Rep;
isomorphismTypes(s: MultiSet L): List % == [s];
coerce(s: List Multiple L): % == per s;
}
SetSpecies(L: LabelType): with {
CombinatorialSpecies L;
} == List L add {
Rep == List L;
import from Rep;
IsomorphismType: IsomorphismTypeCategory(L) == MultiSet L;
}

Ralf Hemmecke

unread,

Aug 5, 2008, 5:00:09 PM8/5/08

to fricas...@googlegroups.com

>> Should that be enough for your build with SBCL?
>
> No. You also need to patch some things in fricas itself. Below is the list of
> patches. I don't know when I'll have time to recompile with high debug
> settings. But I'll try to find a minimal example, too.

Martin, if you post such things, then please post patches against the
latest version (337 now).

I don't include any of the other patches until for each modification you
give not only a reason in your mail but also in the patch itself.

For example, the patch to /src/interp/patches.lisp does not explain why
suddenly one can forget about the .o extension.

In fact, I would rather like to see a patch that factors out
into an extra function that is called from daase.lisp and patches.lisp.

(let ((asharprootlib (strconc (|getEnv| "AXIOM") "/aldor/lib/")))

(set-file-getter (strconc asharprootlib "runtime"))

(set-file-getter (strconc asharprootlib "lang"))

(set-file-getter (strconc asharprootlib "attrib"))

(set-file-getter (strconc asharprootlib "axlit"))

(set-file-getter (strconc asharprootlib "minimach"))

(set-file-getter (strconc asharprootlib "axextend")))

I just don't know where such code would have to live so that it is
callable from daase.lisp and patches.lisp.

> Index: src/interp/patches.lisp
> ===================================================================
> --- src/interp/patches.lisp (revision 336)
> +++ src/interp/patches.lisp (working copy)
> @@ -171,12 +171,12 @@
> (browseopen)
> (|makeConstructorsAutoLoad|)
> (let ((asharprootlib (strconc (|getEnv| "AXIOM") "/aldor/lib/")))
> - (set-file-getter (strconc asharprootlib "runtime.o"))
> - (set-file-getter (strconc asharprootlib "lang.o"))
> - (set-file-getter (strconc asharprootlib "attrib.o"))
> - (set-file-getter (strconc asharprootlib "axlit.o"))
> - (set-file-getter (strconc asharprootlib "minimach.o"))
> - (set-file-getter (strconc asharprootlib "axextend.o")))
> + (set-file-getter (strconc asharprootlib "runtime"))
> + (set-file-getter (strconc asharprootlib "lang"))
> + (set-file-getter (strconc asharprootlib "attrib"))
> + (set-file-getter (strconc asharprootlib "axlit"))
> + (set-file-getter (strconc asharprootlib "minimach"))
> + (set-file-getter (strconc asharprootlib "axextend")))
> )

That patch (at least exporting |Nil| should be applied by Waldek in
trunk. I've seen such a patch in open-axiom today.

This rest is not justified whether it doesn't break anything else.

Documentation for this one???

> (defmacro declare-prog (name-result params)
> - `(proclaim '(function ,(car name-result) ,params ,@(cdr name-result))))
> + `(proclaim '(ftype (function
> + ,(mapcar #'cadr params)
> + ,(or (cadr name-result) 't))
> + ,(car name-result))))
>
> +;(defmacro declare-prog (name-result params)
> +; `(proclaim '(function ,(car name-result) ,params ,@(cdr name-result))))
> +
> +
> (defmacro declare-type (name type)
> `(proclaim '(type ,name ,type)))

I also don't understand the patch for

> Index: src/lisp/fricas-package.lisp

Ralf

Martin Rubey

unread,

Aug 6, 2008, 1:17:47 AM8/6/08

to fricas...@googlegroups.com

Ralf Hemmecke <ra...@hemmecke.de> writes:

> >> Should that be enough for your build with SBCL?
> >
> > No. You also need to patch some things in fricas itself. Below is the list of
> > patches. I don't know when I'll have time to recompile with high debug
> > settings. But I'll try to find a minimal example, too.
>
> Martin, if you post such things, then please post patches against the
> latest version (337 now).
>
> I don't include any of the other patches until for each modification you
> give not only a reason in your mail but also in the patch itself.
>
> For example, the patch to /src/interp/patches.lisp does not explain why
> suddenly one can forget about the .o extension.

> (let ((asharprootlib (strconc (|getEnv| "AXIOM") "/aldor/lib/")))

> (set-file-getter (strconc asharprootlib "runtime"))
> (set-file-getter (strconc asharprootlib "lang"))
> (set-file-getter (strconc asharprootlib "attrib"))
> (set-file-getter (strconc asharprootlib "axlit"))
> (set-file-getter (strconc asharprootlib "minimach"))
> (set-file-getter (strconc asharprootlib "axextend")))

All Common Lisp implementations I know of do not care about the extension when
instructed to load a file: if the file with $FASLEXT is present, they load that
one, otherwise they try to load the lsp or lisp file, if all fails they fail.

From the Common Lisp HyperSpec:

namestring n. a string that represents a filename using either the standardized
notation for naming logical pathnames described in Section 19.3.1 (Syntax of
Logical Pathname Namestrings), or some implementation-defined notation for
naming a physical pathname.

As far as I know, this behaviour is "implementation-defined", but it's very
useful for us...

> In fact, I would rather like to see a patch that factors out into an extra
> function that is called from daase.lisp and patches.lisp.

Me too.

> I just don't know where such code would have to live so that it is
> callable from daase.lisp and patches.lisp.

Me too.

This one is to account for the fact that sbcl fixnums are only 29 bits, but
Aldor SInt's use 32 bit. Of course that may buy us trouble elsewhere, but
otherwise the aldor interface will not work at all.

> > (defstruct FoamProgInfoStruct
> > - (funcall nil :type function)
> > + (funcall #'(lambda () (error "FoamProgInfoStruct: funcall not assigned"))
> > :type function)

Common Lisp expects a valid initialisation value. funcall takes a function as
argument, and nil isn't one. I supplied something that appeared sensible to
me.

> > (defmacro declare-prog (name-result params)
> > - `(proclaim '(function ,(car name-result) ,params ,@(cdr name-result))))
> > + `(proclaim '(ftype (function
> > + ,(mapcar #'cadr params)
> > + ,(or (cadr name-result) 't))
> > + ,(car name-result))))
> >
> > +;(defmacro declare-prog (name-result params)
> > +; `(proclaim '(function ,(car name-result) ,params ,@(cdr name-result))))
> > +
> > +

Supplied by Waldek. The old form produces not valid common lisp code, but I
don't know the details.

> I also don't understand the patch for
>
> > Index: src/lisp/fricas-package.lisp

Common Lisp IN-PACKAGE takes only one argument, aldor produces three. We can
safely ignore all but the first, and that's what the patch does.

Martin

Ralf Hemmecke

unread,

Aug 6, 2008, 5:29:01 AM8/6/08

to fricas...@googlegroups.com

Hi Martin,

>> I also don't understand the patch for
>>
>>> Index: src/lisp/fricas-package.lisp
>
> Common Lisp IN-PACKAGE takes only one argument, aldor produces three. We can
> safely ignore all but the first, and that's what the patch does.

Well, then commit that patch with exactly that log message to
aldor-interface. Maybe you specify the version of the aldor compiler. It
is not the aldor language we are talking about here.

If it helps for other LISPs than GCL and does not break the GCL build,
that is fine with me.

Ralf

Martin Rubey

unread,

Aug 7, 2008, 10:39:45 AM8/7/08

to fricas...@googlegroups.com, Ralf Hemmecke, Gregory Vanuxem

Dear Greg, Ralf, Waldek *

Gregory Vanuxem <g.va...@orange.fr> writes:

> Hello Martin, *
>
> Le mardi 05 août 2008 à 16:19 +0200, Martin Rubey a écrit :
> >
> > Ralf Hemmecke <ra...@hemmecke.de> writes:
> >
> > > > |Interpret| is the following aldor function (a domain, actually):
> > > >
> > > > Interpret(p: List ExpressionTree, L: LabelType): CombinatorialSpecies L == {
> > > > import from InterpretingTools, LabelSpecies, List LabelSpecies;
> > > > l: LabelSpecies := first interpret p;
> > > > (coerce(l)$LabelSpecies)(L) add;
> > > > }

I just found out that loading the library twice cures the problem. Very
strange. I'd really like to have this fixed. Here is a very small example:

-- testa.as -------------------------------------------------------------------
#include "axiom"

define IsomorphismTypeCategory: Category == with {
isomorphismTypes: () -> List %;
}

ACIsomorphismType(F: CombinatorialSpecies): IsomorphismTypeCategory ==
(IsomorphismType$F) add;

define CombinatorialSpecies: Category == with {
IsomorphismType: IsomorphismTypeCategory;
}

MultiSet: IsomorphismTypeCategory == Integer add {
Rep == Integer;
import from Rep;
isomorphismTypes(): List % == [per(1$Integer)];
}

SetSpecies: CombinatorialSpecies == Integer add {
Rep == Integer;
import from Rep;
IsomorphismType: IsomorphismTypeCategory == MultiSet;
}
-------------------------------------------------------------------------------
martin@rubey-laptop:~/martin/Axiom$ export AXIOM=/tmp/lib/fricas/target/i686-pc-linux/

martin@rubey-laptop:~/martin/Axiom$ $AXIOM/bin/AXIOMsys
Checking for foreign routines

AXIOM="/tmp/lib/fricas/target/i686-pc-linux/"
spad-lib="/tmp/lib/fricas/target/i686-pc-linux//lib/libspad.so"

foreign routines found
openServer result -2
FriCAS (AXIOM fork) Computer Algebra System
Version: FriCAS 2008-05-28
Timestamp: Friday July 25, 2008 at 19:06:59
-----------------------------------------------------------------------------
Issue )copyright to view copyright notices.
Issue )summary for a summary of useful system commands.
Issue )quit to leave FriCAS and return to shell.
-----------------------------------------------------------------------------

(1) -> )co testa.as

Compiling FriCAS source code from file

/home/martin/martin/Axiom/testa.as using AXIOM-XL compiler and

options
-O -Fasy -Fao -Flsp -laxiom -Mno-ALDOR_W_WillObsolete -DAxiom -Y $AXIOM/algebra
-I $AXIOM/algebra
Use the system command )set compiler args to change these
options.

Compiling Lisp source code from file ./testa.lsp
Issuing )library command for testa
Reading /home/martin/martin/Axiom/testa.asy
Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/bc-matrix.

STYLE-WARNING: redefining |bcMatrix| in DEFUN

Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/bc-misc.

Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/bc-solve.

STYLE-WARNING: redefining |bcSolve| in DEFUN

Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/bc-util.
Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/ht-util.

STYLE-WARNING: redefining |unescapeStringsInForm| in DEFUN

Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/htsetvar.

STYLE-WARNING: redefining |htsv| in DEFUN

Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/ht-root.

Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/br-con.

STYLE-WARNING: redefining |conPage| in DEFUN

Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/br-data.

Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/showimp.
Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/br-op1.

STYLE-WARNING: redefining |dbGetOrigin| in DEFUN

Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/br-op2.
Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/br-search.

Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/br-util.

Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/topics.
Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/br-prof.
Loading /tmp/lib/fricas/target/i686-pc-linux//autoload/br-saturn.

IsomorphismTypeCategory is now explicitly exposed in frame initial
IsomorphismTypeCategory will be automatically loaded when needed
from /home/martin/martin/Axiom/testa
ACIsomorphismType is now explicitly exposed in frame initial
ACIsomorphismType will be automatically loaded when needed from
/home/martin/martin/Axiom/testa
CombinatorialSpecies is now explicitly exposed in frame initial
CombinatorialSpecies will be automatically loaded when needed from
/home/martin/martin/Axiom/testa
MultiSet is now explicitly exposed in frame initial
MultiSet will be automatically loaded when needed from
/home/martin/martin/Axiom/testa
SetSpecies is now explicitly exposed in frame initial
SetSpecies will be automatically loaded when needed from
/home/martin/martin/Axiom/testa

(1) -> S := ACIsomorphismType(SetSpecies)

(1) ACIsomorphismType SetSpecies
Type: Domain
(2) -> isomorphismTypes()$S

>> System error:
The value |SetSpecies| is not of type (SIMPLE-ARRAY T (*)).

(2) -> )lib testa
Reading /home/martin/martin/Axiom/testa.asy
IsomorphismTypeCategory is already explicitly exposed in frame

initial
IsomorphismTypeCategory will be automatically loaded when needed
from /home/martin/martin/Axiom/testa

ACIsomorphismType is already explicitly exposed in frame initial

ACIsomorphismType will be automatically loaded when needed from
/home/martin/martin/Axiom/testa

CombinatorialSpecies is already explicitly exposed in frame initial

CombinatorialSpecies will be automatically loaded when needed from
/home/martin/martin/Axiom/testa

MultiSet is already explicitly exposed in frame initial

MultiSet will be automatically loaded when needed from
/home/martin/martin/Axiom/testa

SetSpecies is already explicitly exposed in frame initial

SetSpecies will be automatically loaded when needed from
/home/martin/martin/Axiom/testa

LISP output:
(1)
Type: List ACIsomorphismType SetSpecies

Gregory Vanuxem

unread,

Aug 7, 2008, 7:22:26 PM8/7/08

to Ralf Hemmecke, Martin Rubey, fricas...@googlegroups.com

Le mardi 05 août 2008 à 21:37 +0200, Ralf Hemmecke a écrit :
> > I have tried to build the aldor-interface branch this afternoon, the
> > build process stopped because of the problem of file extension (I use
> > SBCL).
>
> Update. I've added Martin's suggestion of having $(FASLEXT) instead of .o.
>
> Should that be enough for your build with SBCL?

I applied the other patches sent by Martin and the one of Peter about
hash [1] and built it without problem, many thanks!

> > I removed several file in src/aldor/tmp and broke the build
> > process...
>
> Hmm, strange. What did you remove and what is the error?

I'm no longer able to reproduce this, I suspect the bug come from me: I
also modified the Makefile (.o->.fasl).

>
> > Hmmm... It's a pity, building the aldor-interface take a
> > lot of time.
>
> Greg, just apply the patch I gave at
>
> http://groups.google.com/group/fricas-devel/browse_thread/thread/e193f5b9fa30a639/f99fe0a78ed3154f?lnk=st&q=#f99fe0a78ed3154f

Applied, thanks.

The bad thing is that I encounter the issue pointed out by Martin:

(3) -> isomorphismTypes(m)$S

>> System error:
The value |SetSpecies| is not of type (SIMPLE-ARRAY T (*)).

But as Martin said, after reloading I can no longer reproduce this. Good
thing to know, thanks Martin.

And sorry for being so late I'm totally buzy (house changement and a lot
of thing to do in the new one).

Regards,

Greg

[1] :
http://groups.google.com/group/fricas-devel/msg/9f769758163c6973?dmode=source

Ralf Hemmecke

unread,

Aug 8, 2008, 7:30:39 AM8/8/08

to fricas...@googlegroups.com, aldor-l

OK. But I simply guess that "Aldor SInt's use 32 bit" is not true.
Show me
1) the specification of SInt for Aldor that says this.
2) the place in the compiler code that implements this specification.

Anyone with knowledge should help Martin out here.

Next question, how would fixnum (except being just 29bits) behave
differently? Would it faster (for example in SBCL) than

(deftype |SInt| () '(integer #.(- (expt 2 29)) #.(1- (expt 2 29))))
^^ ^^
i.e. 29bit integer definitions?

I must say, if in Axiom appears anything that blindly assumes that SInt
is 32 or at least 31 bits, must be considered as a bug. I doubt that
there is a clear specification for Axiom's SInt. Or is there?

Another thing is, if I grep the fricas sources, I only find |SInt| in

src/interp/axext_l.lisp
src/interp/sys-pkg.lisp
src/interp/foam_l.lisp
src/interp/interp-proclaims.lisp

So I believe the modification you suggest above should work at least for
32 bit machines. Simply since Axiom does not know SInt, only foam knows.

I guess that for 64 bit machines you should have something else. My
understanding always was that SingleInteger (or MachineInteger in
libaldor) should hold a machine word.

So I would be much more happy if the patch is somehow coordinated with
the foam definitions in the Aldor compiler and thus perhaps be
conditional depending on the bit size of the machine.

Ralf

Martin Rubey

unread,

Aug 8, 2008, 7:54:54 AM8/8/08

to fricas...@googlegroups.com, aldor-l

Ralf Hemmecke <ra...@hemmecke.de> writes:

> >>> -(deftype |SInt| () 'fixnum)
> >>> +(deftype |SInt| () '(integer #.(- (expt 2 31)) #.(1- (expt 2 31))))
> >
> > This one is to account for the fact that sbcl fixnums are only 29 bits, but
> > Aldor SInt's use 32 bit. Of course that may buy us trouble elsewhere, but
> > otherwise the aldor interface will not work at all.
>
> OK. But I simply guess that "Aldor SInt's use 32 bit" is not true.
> Show me
> 1) the specification of SInt for Aldor that says this.

I don't have the specification, BUT: hashes produced by the Aldor compiler are
typed as SInt's and do not fit into 29 bit. They do fit into 32, however.

> Next question, how would fixnum (except being just 29bits) behave
> differently? Would it faster (for example in SBCL) than
>
> (deftype |SInt| () '(integer #.(- (expt 2 29)) #.(1- (expt 2 29))))
> ^^ ^^
> i.e. 29bit integer definitions?

Maybe, I don't know. The main difference, though, is that a fixnum in sbcl
cannot hold an integer greater than 2^29-1.

> I must say, if in Axiom appears anything that blindly assumes that SInt is 32
> or at least 31 bits, must be considered as a bug. I doubt that there is a
> clear specification for Axiom's SInt. Or is there?

No, it's aldor that assumes 32 bits for SInts, I believe.

> Another thing is, if I grep the fricas sources, I only find |SInt| in
>
> src/interp/axext_l.lisp
> src/interp/sys-pkg.lisp
> src/interp/foam_l.lisp
> src/interp/interp-proclaims.lisp
>
> So I believe the modification you suggest above should work at least for 32
> bit machines. Simply since Axiom does not know SInt, only foam knows.

Oh, this is very good news! So, it's actually sufficient to check that Aldor
does not convert axiom's "SingleInteger"s into "SInt"s, which is unlikely, I
guess.

Great!

> So I would be much more happy if the patch is somehow coordinated with the
> foam definitions in the Aldor compiler and thus perhaps be conditional
> depending on the bit size of the machine.

I'm guessing that the Aldor compiler currently just uses 32 bits. I have no
idea at all where foam SInts are actually used in Foam.

Martin

Ralf Hemmecke

unread,

Aug 8, 2008, 9:45:25 AM8/8/08

to Martin Rubey, fricas...@googlegroups.com, aldor-l

>> I must say, if in Axiom appears anything that blindly assumes that SInt is 32
>> or at least 31 bits, must be considered as a bug. I doubt that there is a
>> clear specification for Axiom's SInt. Or is there?
>
> No, it's aldor that assumes 32 bits for SInts, I believe.

No, not "assumes", but (nearly) specifies. It doesn't say anything about
the bitsize, though. But in the AUG page 149, you find:

=====
XByte, HInt, SInt, BInt: Type
These are integer types of various sizes. The types XByte, HInt,
SInt are unsigned byte, half-precision and single-precision
integer types, capable of representing values in at least the
ranges 0 to 255, -32767 to 32767 and -2147483647 to 2147483647,
respectively. The type BInt provides a "big" integer type, which,
in principle, may be of any size. In practice, the size will be
limited by considerations such as the amount of memory available
to a program.
=====

So Aldor's SInt must have >= 32 bit. But it doesn't say =32bit. Not even
does it specify that it must be a binary representation. So in order to
work correctly, you must look up the Aldor compiler code for SInt.

In trunk/aldor/aldor/lib/libfoam/foam_s.scm,
There is

(deftype |SInt| () 'fixnum)

and some other things related to SInt.
Similar in aldor/lib/libfoam/foam_l.lsp.

Then there is

typedef long FiSInt;

in aldor/lib/libfoam/links/foam_c.

I see actually no problem with your change to 32 bits, since it sees
that foam alone makes the connection to the actual bitsize.

But you patch is incomplete.

There are also the places:

where fixnum seems to be involved.

I must say, I would actually rather like to keep the definitions that
way. SBCL should rather provide fixnum with >=32 bits to be able to work
together with Aldor.

So I think, your patch is a hack. Is there somehow explained what
bitsize 'fixnum' has?

>> Another thing is, if I grep the fricas sources, I only find |SInt| in
>>
>> src/interp/axext_l.lisp
>> src/interp/sys-pkg.lisp
>> src/interp/foam_l.lisp
>> src/interp/interp-proclaims.lisp
>>
>> So I believe the modification you suggest above should work at least for 32
>> bit machines. Simply since Axiom does not know SInt, only foam knows.
>
> Oh, this is very good news! So, it's actually sufficient to check that Aldor
> does not convert axiom's "SingleInteger"s into "SInt"s, which is unlikely, I
> guess.

Uff. I have no idea, what the compiler does. But I think the
representation of SInt coming from Aldor should be identical with the
representation of SingleInteger in Axiom. So what is the representation
of SingleInteger in Axiom? Don't say 'fixnum'... ;-)

>> So I would be much more happy if the patch is somehow coordinated with the
>> foam definitions in the Aldor compiler and thus perhaps be conditional
>> depending on the bit size of the machine.
>
> I'm guessing that the Aldor compiler currently just uses 32 bits. I have no
> idea at all where foam SInts are actually used in Foam.

The only written document I know is

http://axiom-portal.newsynthesis.org/refs/articles/foam.pdf

and there the size of SInt is not specified.

Ralf

Ralf Hemmecke

unread,

Aug 8, 2008, 9:50:49 AM8/8/08

to Martin Rubey, fricas...@googlegroups.com

Hi Martin,

what is the result of

min()$SingleInteger
max()$SingleInteger

with SBCL-FriCAS?

Ralf

Martin Rubey

unread,

Aug 8, 2008, 10:07:17 AM8/8/08

to Ralf Hemmecke, fricas...@googlegroups.com, aldor-l

Ralf Hemmecke <ra...@hemmecke.de> writes:

> I must say, I would actually rather like to keep the definitions that way. SBCL
> should rather provide fixnum with >=32 bits to be able to work together with
> Aldor.

This is impossible. sbcl fixnums are built that way - 29 bits on 32 systems
and probably 61 bits on 64 systems.

> So I think, your patch is a hack. Is there somehow explained what bitsize
> 'fixnum' has?

Yes, it is specified in the Common Lisp Standard: at least 16 bit.

> >> Another thing is, if I grep the fricas sources, I only find |SInt| in
> >>
> >> src/interp/axext_l.lisp
> >> src/interp/sys-pkg.lisp
> >> src/interp/foam_l.lisp
> >> src/interp/interp-proclaims.lisp
> >>
> >> So I believe the modification you suggest above should work at least for 32
> >> bit machines. Simply since Axiom does not know SInt, only foam knows.
> > Oh, this is very good news! So, it's actually sufficient to check that Aldor
> > does not convert axiom's "SingleInteger"s into "SInt"s, which is unlikely, I
> > guess.
>
> Uff. I have no idea, what the compiler does. But I think the representation of
> SInt coming from Aldor should be identical with the representation of
> SingleInteger in Axiom. So what is the representation of SingleInteger in
> Axiom? Don't say 'fixnum'... ;-)

Yes, it is. It's just as with MachineInteger: fast but limited.

Martin

Martin Rubey

unread,

Aug 8, 2008, 10:13:32 AM8/8/08

to Ralf Hemmecke, fricas...@googlegroups.com

Ralf Hemmecke <ra...@hemmecke.de> writes:

64 bit:

(4) -> numeric log(max()$SINT+1)/log 2

(4) 60.0

32 bit I do not have right available right now... But I'm quite sure it's 2^29-1

Martin

Ralf Hemmecke

unread,

Aug 8, 2008, 11:10:06 AM8/8/08

to Martin Rubey, fricas...@googlegroups.com

> (4) -> numeric log(max()$SINT+1)/log 2
>
> (4) 60.0

That is an amazing result. If that were Aldor, I would have guessed that
you compute log(min()$SINT)/log(2) with the above command.

If

m: SINT := max()

then what magic does FriCAS do get something reasonable for m+1?
There are some hidden type coercions here since otherwise m+1 must overflow.

Oh, I see. That only works on 64 bit systems. See...

http://axiom-wiki.newsynthesis.org/SandBoxMaxSingleInteger

Ralf

Ralf Hemmecke

unread,

Aug 8, 2008, 11:34:02 AM8/8/08

to fricas...@googlegroups.com

>> I must say, I would actually rather like to keep the definitions that way. SBCL
>> should rather provide fixnum with >=32 bits to be able to work together with
>> Aldor.
>
> This is impossible. sbcl fixnums are built that way - 29 bits on 32 systems
> and probably 61 bits on 64 systems.

I know it is impossible, but according to the specification of SInt in
the Aldor User Guide, SBCL (on 32 bit platforms) is simply not able to
interpret Aldor programs compiled to Lisp.

So yes, it is wrong to use SBCL on 32 bit platforms together with Aldor.

>> So I think, your patch is a hack. Is there somehow explained what bitsize
>> 'fixnum' has?

> Yes, it is specified in the Common Lisp Standard: at least 16 bit.

Oh, even better. Than it is wrong to use any CL, at least with the
fixnum definitions in foam_l.lisp. Is there something like C's "long" in
Lisp?

Ralf

Ralf Hemmecke

unread,

Aug 8, 2008, 12:10:58 PM8/8/08

to fricas...@googlegroups.com

> I do not think that using 16 bits for hash is enough (simply, there
> is substantial risk of getting many collisions). Depending how the hash
> is used 29 may be enough (sometimes you want _no_ collosions at all,
> then going up to 64 bit would be the correct way). And I do not
> think we want to support any Lisp that offers less than 29 bit
> fixnums.
>
> Rather, we should have separate type for hash, not necessarily the
> same as fixnum.

Hmmm, does that mean that for the Aldor interface, I must test whether
SInt has at least 32 bits? And reject at configure time to build the
inferface if the underlying Lisp is not using fixnums that are big enough?

Or rather change the definition for |SInt| in foam_l.lisp as Martin
suggested?

Ralf

Ralf Hemmecke

unread,

Aug 8, 2008, 6:46:33 PM8/8/08

to fricas...@googlegroups.com, aldor-l

>> Uff. I have no idea, what the compiler does. But I think the representation of
>> SInt coming from Aldor should be identical with the representation of
>> SingleInteger in Axiom. So what is the representation of SingleInteger in
>> Axiom? Don't say 'fixnum'... ;-)
>
> Yes, it is. It's just as with MachineInteger: fast but limited.

OK, but then why should Aldor SInt be something different if you want
that SInt generated by Aldor from a .as file can also be used in FriCAS.

I agree with Waldek that hashes should get a separate type. But wouldn't
that also mean to change Aldor sources? Maybe in the aldor compiler
sources they have already a special type which is only later mapped to
SInt. I haven't checked and I certainly are unable to tell for sure.

Ralf

Martin Rubey

unread,

Aug 10, 2008, 2:51:18 PM8/10/08

to Ralf Hemmecke, fricas-devel

I'm switching to English and the mailing list. I hope you don't mind.

Ralf Hemmecke <ra...@hemmecke.de> writes:

> > Ich dachte, foam SInt und SingleInteger haben nix miteinander zu tun?
>
> Naja, dann müssen wir mal einen Check machen. (Vielmehr Du, ich habe kein
> SBCL.) Bitte auf einer Machine mit 29bit fixnum.
>
> Überleg Dir mal ein Aldor-Programm zu schreiben, etwa so...

-------------------------------------------------------------------------------
)abbrev package FOO Foo
Foo(): with
testSPAD: PositiveInteger -> SingleInteger
== add
testSPAD n == (2@SingleInteger)**n

-------------------------------------------------------------------------------
#include "axiom"

testAS(n: PositiveInteger): SingleInteger == (2@SingleInteger)**n
-------------------------------------------------------------------------------

> Wenn da Mist rauskommt, gibt es eine Verbindung zwischen Foam und FriCAS
> SingleInteger.

No, actually, we should except garbage. However, the error messages are a bit
strange:

(1) -> testINT(n: PositiveInteger): SingleInteger == (2@SingleInteger)**n
Function declaration testINT : PositiveInteger -> SingleInteger has
been added to workspace.
Type: Void
(2) -> testINT 29
Compiling function testINT with type PositiveInteger ->
SingleInteger

>> System error:
The value 536870912 is not of type FIXNUM.

(2) -> testSPAD 29

>> Error detected within library code:
integer too large to represent in a machine word

(2) -> testAS 29

>> System error:
The value 536870912 is not of type FIXNUM.

I would have expected that the error messages of SPAD and Aldor agree. Not
sure what I should think of that.

Note that I cannot run an aldor program without the patch to the size of SInt
in foam_l.lisp, since the hashcodes will be too large then.

I also tested

-------------------------------------------------------------------------------
#include "axiom"

test(n: Integer): Integer == {
a: Integer := n;
for i in 536870911..536870912 repeat a := a + 1;
a;
}
-------------------------------------------------------------------------------

which works as expected, too.

Martin

Ralf Hemmecke

unread,

Aug 10, 2008, 3:29:33 PM8/10/08

to Martin Rubey, Ralf Hemmecke, fricas-devel

On 08/10/2008 08:51 PM, Martin Rubey wrote:
> I'm switching to English and the mailing list. I hope you don't mind.

Not at all.

But your mail is useless without proper specification of your system.
What computer, what version of fricas, which underlying lisp, which
patches, how did you compile the aldor interface, did you make any more
patches.

Ralf

Martin Rubey

unread,

Aug 10, 2008, 3:56:02 PM8/10/08

to Ralf Hemmecke, fricas-devel

Ralf Hemmecke <ra...@hemmecke.de> writes:

> On 08/10/2008 08:51 PM, Martin Rubey wrote:
> > I'm switching to English and the mailing list. I hope you don't mind.
>
> Not at all.
>
> But your mail is useless without proper specification of your system. What
> computer, what version of fricas, which underlying lisp, which patches, how did
> you compile the aldor interface, did you make any more patches.

Sorry about that:

32 bit
fricas aldor interface branch
patches as below (the last one is slightly edited)
compiled with sbcl

Index: src/interp/patches.lisp
===================================================================
--- src/interp/patches.lisp (revision 338)

+++ src/interp/patches.lisp (working copy)
@@ -171,12 +171,12 @@
(browseopen)
(|makeConstructorsAutoLoad|)
(let ((asharprootlib (strconc (|getEnv| "AXIOM") "/aldor/lib/")))
- (set-file-getter (strconc asharprootlib "runtime.o"))
- (set-file-getter (strconc asharprootlib "lang.o"))
- (set-file-getter (strconc asharprootlib "attrib.o"))
- (set-file-getter (strconc asharprootlib "axlit.o"))
- (set-file-getter (strconc asharprootlib "minimach.o"))
- (set-file-getter (strconc asharprootlib "axextend.o")))
+ (set-file-getter (strconc asharprootlib "runtime"))
+ (set-file-getter (strconc asharprootlib "lang"))
+ (set-file-getter (strconc asharprootlib "attrib"))
+ (set-file-getter (strconc asharprootlib "axlit"))
+ (set-file-getter (strconc asharprootlib "minimach"))
+ (set-file-getter (strconc asharprootlib "axextend")))
)

(defun whocalled (n) nil) ;; no way to look n frames up the stack
Index: src/interp/foam_l.lisp
===================================================================

--- src/interp/foam_l.lisp (revision 338)

--- src/lisp/fricas-package.lisp (revision 338)

+++ src/lisp/fricas-package.lisp (working copy)
@@ -1,14 +1,25 @@

Ralf Hemmecke

unread,

Aug 11, 2008, 3:36:06 PM8/11/08

to Martin Rubey, fricas-devel

Anybody else seeing the log below for the following programs?

I use debian etch gcl + fricas/branches/aldor-interface -r 338.
By the way there is no problem if I *don't* execute

testAS 30

before compiling sss.spad.

Looks like that invoking testAS confuses the spad compiler.

Ralf

---BEGIN sss.spad

)abbrev package FOO Foo
Foo(): with
testSPAD: PositiveInteger -> SingleInteger
== add
testSPAD n == (2@SingleInteger)**n

---END sss.spad
---BEGIN aaa.as

#include "axiom"
testAS(n: PositiveInteger): SingleInteger == (2@SingleInteger)**n

---END aaa.as

(1) -> )co aaa.as
Compiling FriCAS source code from file /home/hemmecke/aaa.as using

AXIOM-XL compiler and options
-O -Fasy -Fao -Flsp -laxiom -Mno-ALDOR_W_WillObsolete -DAxiom -Y
$AXIOM/algebra -I $AXIOM/algebra
Use the system command )set compiler args to change these
options.

Compiling Lisp source code from file ./aaa.lsp
Issuing )library command for aaa
Reading /home/hemmecke/aaa.asy
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/bc-matrix.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/bc-misc.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/bc-solve.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/bc-util.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/ht-util.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/htsetvar.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/ht-root.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/br-con.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/br-data.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/showimp.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/br-op1.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/br-op2.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/br-search.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/br-util.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/topics.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/br-prof.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/br-saturn.
(1) -> testAS 30
Loading

/home/hemmecke/software/lib/fricas/target/i686-pc-linux/algebra/INS-.o
for domain IntegerNumberSystem&
Loading

/home/hemmecke/software/lib/fricas/target/i686-pc-linux/algebra/EUCDOM-.o
for domain EuclideanDomain&
Loading

/home/hemmecke/software/lib/fricas/target/i686-pc-linux/algebra/UFD-.o
for domain UniqueFactorizationDomain&
Loading

/home/hemmecke/software/lib/fricas/target/i686-pc-linux/algebra/GCDDOM-.o
for domain GcdDomain&
Loading

/home/hemmecke/software/lib/fricas/target/i686-pc-linux/algebra/INTDOM-.o
for domain IntegralDomain&
Loading

/home/hemmecke/software/lib/fricas/target/i686-pc-linux/algebra/ALGEBRA-.o
for domain Algebra&
Loading

/home/hemmecke/software/lib/fricas/target/i686-pc-linux/algebra/DIFRING-.o
for domain DifferentialRing&
Loading

/home/hemmecke/software/lib/fricas/target/i686-pc-linux/algebra/ORDRING-.o
for domain OrderedRing&
Loading

/home/hemmecke/software/lib/fricas/target/i686-pc-linux/algebra/MODULE-.o
for domain Module&
Loading

/home/hemmecke/software/lib/fricas/target/i686-pc-linux/algebra/RING-.o
for domain Ring&
Loading

/home/hemmecke/software/lib/fricas/target/i686-pc-linux/algebra/ABELGRP-.o
for domain AbelianGroup&
Loading

/home/hemmecke/software/lib/fricas/target/i686-pc-linux/algebra/ABELMON-.o
for domain AbelianMonoid&
Loading

/home/hemmecke/software/lib/fricas/target/i686-pc-linux/algebra/MONOID-.o
for domain Monoid&
Loading

/home/hemmecke/software/lib/fricas/target/i686-pc-linux/algebra/ORDSET-.o
for domain OrderedSet&
Loading

/home/hemmecke/software/lib/fricas/target/i686-pc-linux/algebra/ABELSG-.o
for domain AbelianSemiGroup&
Loading

/home/hemmecke/software/lib/fricas/target/i686-pc-linux/algebra/SGROUP-.o
for domain SemiGroup&

(1) 1073741824
Type:
SingleInteger
(2) -> testAS 31

(2) - 2147483648
Type:
SingleInteger
(3) -> )co sss.spad
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/apply.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/c-doc.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/c-util.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/profile.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/category.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/compiler.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/define.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/functor.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/info.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/iterator.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/modemap.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/nruncomp.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/package.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/htcheck.
Compiling FriCAS source code from file /home/hemmecke/sss.spad using
old system compiler.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/parsing.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/bootlex.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/def.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/fnewmeta.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/metalex.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/metameta.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/parse.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/postpar.
Loading
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/autoload/preparse.
FOO abbreviates package Foo
------------------------------------------------------------------------
initializing NRLIB FOO for Foo
compiling into NRLIB FOO
compiling exported testSPAD : PositiveInteger -> SingleInteger
****** comp fails at level 3 with expression: ******
error in function testSPAD

(** (@ | << 2 >> | (|SingleInteger|)) |n|)
****** level 3 ******
$x:= 2
$m:= (SingleInteger)
$f:=
((((|n| # #) (|$Information| #) (|testSPAD| # #)
(|$DomainsInScope| # # #) ...)))

>> Apparent user error:
Cannot coerce 2
of mode (PositiveInteger)
to mode (SingleInteger)

Ralf Hemmecke

unread,

Aug 11, 2008, 3:45:18 PM8/11/08

to Martin Rubey, fricas-devel

Oh, it has nothing to do with ALDOR. I can trigger that problem just by
multiplying a PositiveInteger with a SingleInteger before compiling

---BEGIN sss.spad

)abbrev package FOO Foo
Foo(): with
testSPAD: PositiveInteger -> SingleInteger
== add
testSPAD n == (2@SingleInteger)**n

---END sss.spad

That is really disappointing. :-( The SPAD compiler doesn't just
take the .spad file as input, but also the current session environment.

Ralf

>fricas
GCL (GNU Common Lisp) 2.6.7 CLtL1 Oct 29 2006 02:32:45
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/hemmecke/
openServer result 0

FriCAS (AXIOM fork) Computer Algebra System
Version: FriCAS 2008-05-28

Timestamp: Sunday August 3, 2008 at 12:47:11

-----------------------------------------------------------------------------
Issue )copyright to view copyright notices.
Issue )summary for a summary of useful system commands.
Issue )quit to leave FriCAS and return to shell.
-----------------------------------------------------------------------------

(1) ->
(1) -> s: SingleInteger :=2

(1) 2
Type:
SingleInteger
(2) -> p: PositiveInteger :=3

(2) 3
Type:
PositiveInteger
(3) -> s*p

(3) 6
Type:
PositiveInteger
(4) -> p*s

(4) 6
Type:
SingleInteger
(5) -> )co sss.spad

Martin Rubey

unread,

Aug 11, 2008, 3:49:21 PM8/11/08

to Ralf Hemmecke, fricas-devel

I get exactly the same behaviour, using gcl and current rev. of
aldor-interface.

I'll look at what sbcl does in roughly half an hour.

Apart from that, I noticed weird problems with sbcl, when the filename (!) of
the aldor file had upper case letters. But I didn't have the energy to write a
bug report yet...

From my memory, I vaguely remember that invoking the spad compiler and the
aldor compiler in one session is always a bad idea...

Martin

leh...@bayou.uni-linz.ac.at

unread,

Aug 14, 2008, 8:38:04 AM8/14/08

to fricas...@googlegroups.com

Hello,

On Sat, Aug 02, 2008 at 05:43:31PM +0200, Ralf Hemmecke wrote:
> Anyway, if there aren't many people who complain then the interface is
> pretty much finished. Try it out!
I did so on 32bit debian lenny (will be debian stable in a few month)
and 64bit debian etch.

Debian lenny apparently has a broken gcl (probably the same problem as
on ubuntu), see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=487435
The proposed patch does not work for me.

So I switched to sbcl (even on debian etch):
../fricasaldor-338/configure --with-lisp=/usr/bin/sbcl --enable-aldor

using Ralf's branch rev 338 + a few patches from Martin.
The build goes through, including aldor.

I tried the notorious sieve.as and
also external compilation with two aldor packages
lib/coxeter.as which depends on lib/aux.as.

64bit
=====

)co sieve.as from within fricas does not work:
(1) -> )co sieve.as
Compiling FriCAS source code from file /home/lehner/sieve.as using

AXIOM-XL compiler and options
-O -Fasy -Fao -Flsp -laxiom -Mno-ALDOR_W_WillObsolete -DAxiom
-Y $AXIOM/algebra -I $AXIOM/algebra
Use the system command )set compiler args to change these
options.

"/home/lehner/usr/local/lib/fricas/target/x86_64-unknown-linux/algebra/axiom.as",
line 4:
import from AxiomLib;
^
[L4 C1] #1 (Error) Syntax error.

The )library system command was not called after compilation.

External compilation goes fine on 64bit,
loading into fricas shows
(1) -> Cox3:=CoxeterGroup3('x)

(1) CoxeterGroup3 x
Type: Domain
(2) -> x1:=generator(1)$Cox3

>> System error:
error opening #P"/home/lehner/ax/lib/coxeter":
File not found.

ln -s coxeter.lsp coxeter
and ln -s aux.lsp aux
cures this problem and it works:
(1) -> Cox3:=CoxeterGroup3('x)

(1) CoxeterGroup3 x
Type: Domain
(2) -> x1:=generator(1)$Cox3

(2) x
1
Type: CoxeterGroup3 x

32bit
=====

First nothing worked, but this was because
$AXIOM/algebra/axiom.as was an _empty_ file.
After filling it internal compilation
)co sieve.as
works, however calling
(1) -> sieve 5

>> System error:
The value 1073741789 is not of type FIXNUM.

External compilation against libaxiom.al succeeds as well,
again symlinking coxeter->coxeter.lsp is necessary,
but still I get:

(1) -> Cox3:=CoxeterGroup3('x)

(1) CoxeterGroup3 x
Type: Domain
(2) -> x1:=generator(1)$Cox3

>> System error:
The value 1073741789 is not of type FIXNUM.

what number is this?

best regards,
Franz

Ralf Hemmecke

unread,

Aug 14, 2008, 9:44:36 AM8/14/08

to fricas...@googlegroups.com

> Debian lenny apparently has a broken gcl (probably the same problem as
> on ubuntu), see
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=487435
> The proposed patch does not work for me.

In the FriCAS INSTALL file you also find ...
2) Fetch nonstandard prerequisities:
cd fricas
svn co
https://axiom.svn.sourceforge.net/svnroot/axiom/branches/build-improvements/gcl
gcl

Would that help with your gcl problem?

> So I switched to sbcl (even on debian etch):
> ../fricasaldor-338/configure --with-lisp=/usr/bin/sbcl --enable-aldor

> using Ralf's branch rev 338 + a few patches from Martin.
> The build goes through, including aldor.

Well, I a really still unsure whether Martin's patch moving away from
fixnum (29bit) to (integer ... ...) (32bit) is really the way to go with
SBCL. I'd like to wait for Waldek's comments on my posts that I sent
related to this topic.

> I tried the notorious sieve.as and
> also external compilation with two aldor packages
> lib/coxeter.as which depends on lib/aux.as.

> 64bit
> =====
>
> )co sieve.as from within fricas does not work:
> (1) -> )co sieve.as
> Compiling FriCAS source code from file /home/lehner/sieve.as using
> AXIOM-XL compiler and options
> -O -Fasy -Fao -Flsp -laxiom -Mno-ALDOR_W_WillObsolete -DAxiom
> -Y $AXIOM/algebra -I $AXIOM/algebra
> Use the system command )set compiler args to change these
> options.
>
> "/home/lehner/usr/local/lib/fricas/target/x86_64-unknown-linux/algebra/axiom.as",
> line 4:
> import from AxiomLib;
> ^
> [L4 C1] #1 (Error) Syntax error.
>
> The )library system command was not called after compilation.

VERY STRANGE. In fact, you later say that axiom.as was empty. That is
even stranger. Can you look into your build-directory. There should be a
axiom.as. It should have been "svn cat" from the algebraist server. Why
should that have been empty???

> External compilation goes fine on 64bit,
> loading into fricas shows

You probably have an axiom.as somewhere in your $ALDORROOT/include
directory. No?

> (1) -> Cox3:=CoxeterGroup3('x)
>
> (1) CoxeterGroup3 x
> Type: Domain
> (2) -> x1:=generator(1)$Cox3
>
> >> System error:
> error opening #P"/home/lehner/ax/lib/coxeter":
> File not found.
>
> ln -s coxeter.lsp coxeter
> and ln -s aux.lsp aux
> cures this problem and it works:
> (1) -> Cox3:=CoxeterGroup3('x)
>
> (1) CoxeterGroup3 x
> Type: Domain
> (2) -> x1:=generator(1)$Cox3
>
> (2) x
> 1
> Type: CoxeterGroup3 x

Nice to hear. Do you use fixnum here instead of Martin's patch?
How big is fixnum actually for SBCL on a 64 bit machine? As I have
demonstrated on

http://axiom-wiki.newsynthesis.org/SandBoxMaxSingleInteger

max and min might return something else than the actual size.
Is it somewhere documented in SBCL what the size they use for fixnum on
64bit.

> 32bit
> =====
>
> First nothing worked, but this was because
> $AXIOM/algebra/axiom.as was an _empty_ file.
> After filling it internal compilation
> )co sieve.as
> works, however calling
> (1) -> sieve 5
>
> >> System error:
> The value 1073741789 is not of type FIXNUM.
>
> External compilation against libaxiom.al succeeds as well,
> again symlinking coxeter->coxeter.lsp is necessary,
> but still I get:
>
> (1) -> Cox3:=CoxeterGroup3('x)
>
> (1) CoxeterGroup3 x
> Type: Domain
> (2) -> x1:=generator(1)$Cox3
>
> >> System error:
> The value 1073741789 is not of type FIXNUM.
>
>
> what number is this?

A big one. And I have no idea where it comes from. It's even the same in
both cases, so that sounds as if it has something to do with hashes.
But, actually, I really have no clue.

Ralf

leh...@bayou.uni-linz.ac.at

unread,

Aug 14, 2008, 10:10:08 AM8/14/08

to fricas...@googlegroups.com

On Thu, Aug 14, 2008 at 03:44:36PM +0200, Ralf Hemmecke wrote:

> In the FriCAS INSTALL file you also find ...
> 2) Fetch nonstandard prerequisities:
> cd fricas
> svn co
> https://axiom.svn.sourceforge.net/svnroot/axiom/branches/build-improvements/gcl
> gcl
>
> Would that help with your gcl problem?

no, building gcl fails with the sbrk error indicated in the
debian bug system, even after applying the proposed patch.
There is a precompiled version of gcl included in lenny,
but that one just crashes.

> VERY STRANGE. In fact, you later say that axiom.as was empty.

it was only empty in the 32bit build, not in the 64bit build.

> That is
> even stranger. Can you look into your build-directory. There should be a
> axiom.as. It should have been "svn cat" from the algebraist server.

that explains everything. When building on the 32bit laptop, I had
to manuallyl accept a lot of signatures and missed axiom.as due to a timeout.
I was not asked on the 64bit machine.

> Nice to hear. Do you use fixnum here instead of Martin's patch?

Martin sent me a few patches yesterday which are appended to this
message.

> How big is fixnum actually for SBCL on a 64 bit machine? As I have
> demonstrated on
>
> http://axiom-wiki.newsynthesis.org/SandBoxMaxSingleInteger
>
> max and min might return something else than the actual size.
> Is it somewhere documented in SBCL what the size they use for fixnum on
> 64bit.

here I get

(22) -> log(max()$SingleInteger)/log(2.0)

(22) 59.9999999999 99999999
Type: Expression Float

Franz

sbclpatch.txt

Bill Page

unread,

Aug 14, 2008, 10:15:09 AM8/14/08

to fricas...@googlegroups.com

On Thu, Aug 14, 2008 at 8:38 AM, Franz Lehner wrote:

> ...

> So I switched to sbcl (even on debian etch):
> ../fricasaldor-338/configure --with-lisp=/usr/bin/sbcl --enable-aldor
>
> using Ralf's branch rev 338 + a few patches from Martin.
> The build goes through, including aldor.

I am not sure what you mean by "including aldor". Perhaps it is not
clear that this builds only the interface and not Aldor itself. In
order to know more about what is going on in your system, it is
important to know what version of Aldor you are using.

> ...
>> 32bit
>> =====
>> ...

>> (2) -> x1:=generator(1)$Cox3
>>
>> >> System error:
>> The value 1073741789 is not of type FIXNUM.
>>
>>
>> what number is this?
>

On Thu, Aug 14, 2008 at 9:44 AM, Ralf Hemmecke wrote:

> A big one. And I have no idea where it comes from. It's even the same
> in both cases, so that sounds as if it has something to do with hashes.
> But, actually, I really have no clue.
>

I think "something to do with hashes" is a good guess. This message
looks like the same one I get when I compile the interface on a 64 bit
system with Aldor version 1.1.0 compiled from sources. With this
combination, in order to avoid the above error a patch to the file
'hashcode.boot' in FriCAS is required make Aldor and FriCAS hashing
algorithms compatible. Perhaps the same thing can happen in reverse on
a 32 bit system (or maybe only when SBCL is involved) if the patch is
applied unnecessarily? I guess what we need is a lot more testing of
the possible combinations.

Regards,
Bill Page.

Ralf Hemmecke

unread,

Aug 14, 2008, 10:24:49 AM8/14/08

to fricas...@googlegroups.com

>> How big is fixnum actually for SBCL on a 64 bit machine? As I have
>> demonstrated on
>>
>> http://axiom-wiki.newsynthesis.org/SandBoxMaxSingleInteger
>>
>> max and min might return something else than the actual size.
>> Is it somewhere documented in SBCL what the size they use for fixnum on
>> 64bit.
> here I get
>
> (22) -> log(max()$SingleInteger)/log(2.0)
>
> (22) 59.9999999999 99999999
> Type: Expression Float

Well, and what is the answer for

b: SingleInteger := 2^63-1

? If you have only 60bits than that should be -1, right? Or even give a
coercion error. Actually, I am more interested in an SBCL
*specification* for fixnum size on 64bit machines.

Ralf

leh...@bayou.uni-linz.ac.at

unread,

Aug 14, 2008, 10:56:05 AM8/14/08

to fricas...@googlegroups.com

On Thu, Aug 14, 2008 at 10:15:09AM -0400, Bill Page wrote:
> I am not sure what you mean by "including aldor".

You are right, I forgot to mention.
In both cases it is the corresponding aldor 1.1.0 binary.
I meant the aldor interface.
I guess I will have to rebuild the 32bit version taking care of
svn timeouts.

> I think "something to do with hashes" is a good guess. This message
> looks like the same one I get when I compile the interface on a 64 bit
> system with Aldor version 1.1.0 compiled from sources. With this
> combination, in order to avoid the above error a patch to the file
> 'hashcode.boot' in FriCAS is required make Aldor and FriCAS hashing
> algorithms compatible. Perhaps the same thing can happen in reverse on
> a 32 bit system (or maybe only when SBCL is involved) if the patch is
> applied unnecessarily?

I'll try that.

regards
Franz

leh...@bayou.uni-linz.ac.at

unread,

Aug 14, 2008, 10:57:38 AM8/14/08

to fricas...@googlegroups.com

> Well, and what is the answer for
>
> b: SingleInteger := 2^63-1
>
> ? If you have only 60bits than that should be -1, right?

no it isn't:
(1) -> b:SingleInteger:=2^60-1

>> System error:
The value 1152921504606846976 is not of type FIXNUM.

Franz

Ralf Hemmecke

unread,

Aug 14, 2008, 11:23:01 AM8/14/08

to fricas...@googlegroups.com

What?

That has nothing to do with Aldor, right?
But you've got.

(22) -> log(max()$SingleInteger)/log(2.0)

(22) 59.9999999999 99999999
Type: Expression Float

So you should be able to coerce 2^60-1 into a SingleInteger.
Can you try

z: Integer := 2^60-1
b: SingleInteger := z

Interestingly with your line (1) fricas computes 2^60 as a
(Positive)Integer and before subtracting 1 tries to convert it to a
SingleInteger.

Ralf

Bill Page

unread,

Aug 14, 2008, 11:43:10 AM8/14/08

to fricas...@googlegroups.com

Apparently this behaviour is highly lisp dependent. Just to add a
little to the confusion ;-) here is the result using FriCAS built on
16 bit clisp on Windows (no I haven't tried to build the Aldor
interface on this platform yet :-):

(13) -> b:SingleInteger:=2^60-1

(13) 1152921504606846975
Type: SingleInteger

What? No error!

(14) -> z: Integer := 2^60-1

(14) 1152921504606846975
Type: Integer
(15) -> b:SingleInteger:=z

Cannot convert right-hand side of assignment
1152921504606846975

to an object of the type SingleInteger of the left-hand side.

That sort of makes sense.

(15) -> log(max()$SingleInteger)/log(2.0)

(15) 23.9999999140 08672006
Type: Expression Float
(16) -> b:SingleInteger:=2^24-1

(16) 16777215
Type: SingleInteger
(17) -> z: Integer := 2^24-1

(17) 16777215
Type: Integer
(18) -> b:SingleInteger:=z

(18) 16777215
Type: SingleInteger

Ok.

Regards,
Bill Page.

Ralf Hemmecke

unread,

Aug 14, 2008, 11:54:30 AM8/14/08

to fricas...@googlegroups.com

> Apparently this behaviour is highly lisp dependent. Just to add a
> little to the confusion ;-) here is the result using FriCAS built on
> 16 bit clisp on Windows (no I haven't tried to build the Aldor
> interface on this platform yet :-):

16bit?

> (13) -> b:SingleInteger:=2^60-1
>
> (13) 1152921504606846975
> Type: SingleInteger

That is an interesting big number for a 16bit machine word. Maybe clisp
creates hidden bits? *smile*

> (14) -> z: Integer := 2^60-1
>
> (14) 1152921504606846975
> Type: Integer
> (15) -> b:SingleInteger:=z
>
> Cannot convert right-hand side of assignment
> 1152921504606846975
>
> to an object of the type SingleInteger of the left-hand side.
>
> That sort of makes sense.

But the error message is different from what Franz Lehner got.

> (15) -> log(max()$SingleInteger)/log(2.0)
>
> (15) 23.9999999140 08672006
> Type: Expression Float
> (16) -> b:SingleInteger:=2^24-1
>
> (16) 16777215
> Type: SingleInteger
> (17) -> z: Integer := 2^24-1
>
> (17) 16777215
> Type: Integer
> (18) -> b:SingleInteger:=z
>
> (18) 16777215
> Type: SingleInteger

Again. For a 16bit machine it is still interesting that the fixnum size
is 24. Anyway, you must have a really really old computer with 16bit
word size. Are they still sold nowadays? (I wonder, how many days it
took to compile fricas.)

Ralf

leh...@bayou.uni-linz.ac.at

unread,

Aug 14, 2008, 12:01:47 PM8/14/08

to fricas...@googlegroups.com

On Thu, Aug 14, 2008 at 05:23:01PM +0200, Ralf Hemmecke wrote:
> What?
>
> That has nothing to do with Aldor, right?

indeed.

> Can you try
>
> z: Integer := 2^60-1
> b: SingleInteger := z

(1) -> z: Integer := 2^60-1

(1) 1152921504606846975

Type: Integer
(2) -> b: SingleInteger := z

(2) 1152921504606846975
Type: SingleInteger

> Interestingly with your line (1) fricas computes 2^60 as a
> (Positive)Integer and before subtracting 1 tries to convert it to a
> SingleInteger.

because there is no "-" in PositiveInteger:

(1) -> )set mess bott on
(1) -> x:PositiveInteger:=5

(1) 5
Type: PositiveInteger
(2) -> y:PositiveInteger:=1

(2) 1
Type: PositiveInteger
(3) -> x-y

Function Selection for -
Arguments: (PI,PI)
-> no appropriate - found in PositiveInteger

[1] signature: (INT,INT) -> INT
implemented: slot $$$ from INT

(3) 4
Type: PositiveInteger

(4) -> b:SingleInteger:=2^60-1

Function Selection for ^
Arguments: (SINT,PI)
Target type: SINT
-> no appropriate ** found in PositiveInteger
-> no appropriate ** found in Integer
-> no appropriate ^ found in PositiveInteger
-> no appropriate ^ found in Integer

[1] signature: (SINT,PI) -> SINT
implemented: slot $$(PositiveInteger) from SINT
[2] signature: (SINT,PI) -> SINT
implemented: slot $$(PositiveInteger) from SINT

>> System error:
The value 1152921504606846976 is not of type FIXNUM.

Franz

Bill Page

unread,

Aug 14, 2008, 12:02:49 PM8/14/08

to fricas...@googlegroups.com

On Thu, Aug 14, 2008 at 11:54 AM, Ralf Hemmecke wrote:

>
> Bill Page wrote:
>> Apparently this behaviour is highly lisp dependent. Just to add a
>> little to the confusion ;-) here is the result using FriCAS built on
>> 16 bit clisp on Windows (no I haven't tried to build the Aldor
>> interface on this platform yet :-):
>
> 16bit?

Sorry, I am wrong by a factor of 2. Obviously I'm still living in the
last century :-).

I meant 32 bit clisp, of course.

> ...

> Again. For a 16bit machine it is still interesting that the fixnum
> size is 24. Anyway, you must have a really really old computer
> with 16bit word size. Are they still sold nowadays? (I wonder,
> how many days it took to compile fricas.)
>

:-)

Regards,
Bill Page.

Ralf Hemmecke

unread,

Aug 14, 2008, 12:26:50 PM8/14/08

to fricas...@googlegroups.com

>> 16bit?

> Sorry, I am wrong by a factor of 2. Obviously I'm still living in the
> last century :-).

Yes. That were the good old days with 17bit machines. ;-)

Ralf

Alfredo Portes

unread,

Aug 14, 2008, 1:27:10 PM8/14/08

to fricas...@googlegroups.com

On Thu, Aug 14, 2008 at 10:10 AM, <leh...@bayou.uni-linz.ac.at> wrote:

>> Would that help with your gcl problem?
> no, building gcl fails with the sbrk error indicated in the
> debian bug system, even after applying the proposed patch.
> There is a precompiled version of gcl included in lenny,
> but that one just crashes.

echo 0 >/proc/sys/kernel/exec-shield
echo 0 >/proc/sys/kernel/randomize_va_space

leh...@bayou.uni-linz.ac.at

unread,

Aug 15, 2008, 7:31:53 AM8/15/08

to fricas...@googlegroups.comy

On Thu, Aug 14, 2008 at 04:56:05PM +0200, leh...@bayou.uni-linz.ac.at wrote:
> I'll try that.
no variant of the hashcode.boot patch helps around the fixnum
problem in 32bit. So far I tried
-- hashCombine(retCode,hash)
hashCombine(retCode,hash)
hashCombine(retCode, hashCombine(32236, hash))

Where does the number
1073741789 = 2^30-35
come from? The debugger says

(1) -> )set break break
(1) -> sieve 5

debugger invoked on a TYPE-ERROR in thread #<THREAD "initial thread" RUNNING {B83D7E9}>:

The value 1073741789 is not of type FIXNUM.

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

(no restarts: If you didn't do this on purpose, please report it as a bug.)

(SB-C::%COMPILE-TIME-TYPE-ERROR (1073741789) FIXNUM #<unavailable argument>)

but I don't know what to investigate further.

By the way, make axiom.as in src/aldor asks the following:
svn cat https://svn.origo.ethz.ch/algebraist/trunk/aldor/lib/libax0/axiom.as > axiom.as
Fehler bei der Validierung des Serverzertifikats für
»https://svn.origo.ethz.ch:443«:
- Das Zertifikat ist nicht von einer vertrauenswürdigen Instanzausgestellt
Ãberprüfen Sie den Fingerabdruck, um das Zertifikat zu validieren!
Zertifikats-Informationen:
- Hostname: svn.origo.ethz.ch
- Gültig: von Wed, 21 May 2008 11:36:02 GMT bis Sat, 21 May 201111:36:02 GMT
- Aussteller: Educational CA, Cybertrust, BE
- Fingerabdruck: 43:34:38:eb:bb:74:54:96:ca:65:ef:6e:78:4f:c6:d9:ca:ca:41:0e
Ve(r)werfen oder (t)emporär akzeptieren?

and after a timeout an empty axiom.as is left.
Perhaps svn should just ignore the warning?

best regards
Franz

Ralf Hemmecke

unread,

Aug 15, 2008, 9:03:25 AM8/15/08

to fricas...@googlegroups.com

> svn cat https://svn.origo.ethz.ch/algebraist/trunk/aldor/lib/libax0/axiom.as > axiom.as

> Fehler bei der Validierung des Serverzertifikats fÃ¼r
> Â»https://svn.origo.ethz.ch:443Â«:
> - Das Zertifikat ist nicht von einer vertrauenswÃ¼rdigen Instanzausgestellt
> ÃberprÃ¼fen Sie den Fingerabdruck, um das Zertifikat zu validieren!
> Zertifikats-Informationen:
> - Hostname: svn.origo.ethz.ch
> - GÃ¼ltig: von Wed, 21 May 2008 11:36:02 GMT bis Sat, 21 May 201111:36:02 GMT

> - Aussteller: Educational CA, Cybertrust, BE
> - Fingerabdruck: 43:34:38:eb:bb:74:54:96:ca:65:ef:6e:78:4f:c6:d9:ca:ca:41:0e

> Ve(r)werfen oder (t)emporÃ¤r akzeptieren?

Interesting. My svn doesn't show me that. I might have accepted that
once, but I don't know where svn stores that if not under ~/.subversion
(where I don't find anything connected to origo).

Ralf

Martin Rubey

unread,

Aug 15, 2008, 9:34:14 AM8/15/08

to fricas...@googlegroups.com

leh...@bayou.uni-linz.ac.at writes:

> On Thu, Aug 14, 2008 at 04:56:05PM +0200, leh...@bayou.uni-linz.ac.at wrote:
> > I'll try that.
> no variant of the hashcode.boot patch helps around the fixnum
> problem in 32bit. So far I tried
> -- hashCombine(retCode,hash)
> hashCombine(retCode,hash)
> hashCombine(retCode, hashCombine(32236, hash))

Dear Franz,

could you do an

svn diff

in the fricas branch you build from and send me the result, please.
Furthermore, could you remind me of your

aldor version

linux version

architecture

> (1) -> )set break break
> (1) -> sieve 5
>
> debugger invoked on a TYPE-ERROR in thread #<THREAD "initial thread" RUNNING {B83D7E9}>:
> The value 1073741789 is not of type FIXNUM.
>
> Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
>
> (no restarts: If you didn't do this on purpose, please report it as a bug.)
>
> (SB-C::%COMPILE-TIME-TYPE-ERROR (1073741789) FIXNUM #<unavailable argument>)
>
> but I don't know what to investigate further.

type

backtrace

at the debug prompt.

Martin

Martin Rubey

unread,

Aug 15, 2008, 9:37:50 AM8/15/08

to fricas...@googlegroups.com

Martin Rubey <martin...@univie.ac.at> writes:

> Dear Franz,
>
> could you do an
>
> svn diff
>
> in the fricas branch you build from and send me the result, please.
> Furthermore, could you remind me of your
>
> aldor version
>
> linux version
>
> architecture

sbcl version

Martin

leh...@bayou.uni-linz.ac.at

unread,

Aug 15, 2008, 9:41:49 AM8/15/08

to fricas...@googlegroups.com

On Fri, Aug 15, 2008 at 03:03:25PM +0200, Ralf Hemmecke wrote:
> Interesting. My svn doesn't show me that. I might have accepted that
> once, but I don't know where svn stores that if not under ~/.subversion
> (where I don't find anything connected to origo).

It only asks on my 32bit machine (debian lenny) and only offers
"decline" or "accept temporarily".
On my 64bit machine (debian etch) it never asked.

Franz

leh...@bayou.uni-linz.ac.at

unread,

Aug 15, 2008, 9:54:17 AM8/15/08

to fricas...@googlegroups.com

On Fri, Aug 15, 2008 at 03:34:14PM +0200, Martin Rubey wrote:
> svn diff
attached.
> aldor version
1.1.0 binary from aldor site
>
> linux version
debian lenny with sbcl presenting itself as
This is SBCL 1.0.18.debian, an implementation of ANSI Common Lisp.

> architecture
32bit

> type
>
> backtrace
>
> at the debug prompt.

I did that before but got no clue.
Result is attached.

Franz

backtrace.txt

sbcldiff.txt

Martin Rubey

unread,

Aug 15, 2008, 10:35:47 AM8/15/08

to fricas...@googlegroups.com

leh...@bayou.uni-linz.ac.at writes:

> On Fri, Aug 15, 2008 at 03:34:14PM +0200, Martin Rubey wrote:
> > svn diff
> attached.

Your patch to foam_l is flawed:

should be (most important is the deftype |SInt|)

Index: foam_l.lisp
===================================================================
--- foam_l.lisp (revision 338)
+++ foam_l.lisp (working copy)

Martin

leh...@bayou.uni-linz.ac.at

unread,

Aug 15, 2008, 10:40:00 AM8/15/08

to fricas...@googlegroups.com

On Fri, Aug 15, 2008 at 03:41:49PM +0200, leh...@bayou.uni-linz.ac.at wrote:
> It only asks on my 32bit machine (debian lenny) and only offers
> "decline" or "accept temporarily".

in order to be offered "accept permanently"
one has to add the option --config-dir ~/.subversion
at least with svn, Version 1.5.1 (r32289).
After that it works (even without --config-dir).

Franz

Ralf Hemmecke

unread,

Aug 15, 2008, 11:26:21 AM8/15/08

to fricas...@googlegroups.com

On 08/15/2008 04:35 PM, Martin Rubey wrote:
> leh...@bayou.uni-linz.ac.at writes:
>
>> On Fri, Aug 15, 2008 at 03:34:14PM +0200, Martin Rubey wrote:
>>> svn diff
>> attached.
>
> Your patch to foam_l is flawed:
>
> -(deftype |HInt| () '(integer #.(- (expt 2 15)) #.(1- (expt 2 15))))
> +(deftype |HInt| () '(integer #.(- (expt 2 15)) #.(1- (expt 2 31))))
> (deftype |SInt| () 'fixnum)
>
> should be (most important is the deftype |SInt|)

But yours is not better. You changed |HInt|. And -2^15 .. 2^31 also
looks a bit fishy to me.

Ralf

Martin Rubey

unread,

Aug 15, 2008, 12:05:19 PM8/15/08

to fricas...@googlegroups.com

Ralf Hemmecke <ra...@hemmecke.de> writes:

But that's not my patch! My patch was (at least should have been)

(deftype |HInt| () '(integer #.(- (expt 2 15)) #.(1- (expt 2 15))))

(deftype |SInt| () '(integer #.(- (expt 2 31)) #.(1- (expt 2 31))))

Martin

leh...@bayou.uni-linz.ac.at

unread,

Aug 16, 2008, 10:46:35 AM8/16/08

to fricas...@googlegroups.com

On Fri, Aug 15, 2008 at 04:35:47PM +0200, Martin Rubey wrote:
> Your patch to foam_l is flawed:

indeed, being unfamiliar with svn I did the patch manually.
With the correct patch sieve.as fails with

(1) -> sieve 5
Looking in OneDimensionalArray(Boolean()) for new with code 1055433730

>> System error:
The function FOAM-USER::|fiRaiseException| is undefined.

which after
)lisp (defun FOAM-USER::|fiRaiseException| (s) (error s)) ;
translates to

>> System error:
Export not found

another example (attached sum.as) leads to

(1) sum [1,2,3]

>> System error:
The value NIL is not of type (SIGNED-BYTE 32).

the backtrace is attached.

Franz

sum.as

sumdebug.txt

Ralf Hemmecke

unread,

Aug 16, 2008, 10:59:11 AM8/16/08

to fricas...@googlegroups.com

On 08/16/2008 04:46 PM, leh...@bayou.uni-linz.ac.at wrote:
> On Fri, Aug 15, 2008 at 04:35:47PM +0200, Martin Rubey wrote:
>> Your patch to foam_l is flawed:
> indeed, being unfamiliar with svn I did the patch manually.
> With the correct patch sieve.as fails with

> (1) -> sieve 5
> Looking in OneDimensionalArray(Boolean()) for new with code 1055433730
>
> >> System error:
> The function FOAM-USER::|fiRaiseException| is undefined.

That looks like an error we had earlier. Please search the fricas
archive. That should actually no longer happen with the latest revision.

Note that I actually committed a change to aldor-interface where you
won't find foam_l anymore. The reason is that foam_l is in AXIOMsys
already, so if you change it you must recompile fricas.

Ralf

Martin Rubey

unread,

Aug 16, 2008, 5:29:33 PM8/16/08

to fricas...@googlegroups.com

Dear Franz,

I revisited the diff you sent me and noticed that you commented out a line in
hashcode.boot. Maybe this is a leftover, but for what it's worth, in my
version, hashcode.boot is unmodified (for aldor 1.0.3, that is).

Martin

Index: src/interp/hashcode.boot
===================================================================
--- src/interp/hashcode.boot (Revision 338)
+++ src/interp/hashcode.boot (Arbeitskopie)
@@ -55,7 +55,7 @@
hash := hashCombine(hashType(arg, percentHash), hash)
retCode := hashType(retType, percentHash)
EQL(retCode, $VoidHash) => hash
- hashCombine(retCode, hash)
+-- hashCombine(retCode,hash)
op = 'Enumeration =>
for arg in args repeat
hash := hashCombine(hashString(STRING arg), hash)

leh...@bayou.uni-linz.ac.at

unread,

Aug 18, 2008, 8:07:33 AM8/18/08

to fricas...@googlegroups.com

Dear Martin,

> I revisited the diff you sent me and noticed that you commented out a line in
> hashcode.boot. Maybe this is a leftover, but for what it's worth, in my
> version, hashcode.boot is unmodified (for aldor 1.0.3, that is).

It was commented out in the patch you sent me and I suspected that
something is missing. I can now confirm that
Ralf's rev 338 with your patches
sbcl
aldor 1.1.0 binary

-with the hashcode patch, i.e., with the line
hashCombine(retCode, hashCombine(32236,hash))
works on 64bit, but not on 32bit debian lenny,
-without hashcode patch, i.e., with the line
hashCombine(retCode,hash)
works on 32bit debian etch

The only glitch is that when compiling externally,
fricas expects <file> instead of <file>.lsp

great work, thanks!
Franz

Ralf Hemmecke

unread,

Aug 18, 2008, 12:07:25 PM8/18/08

to fricas...@googlegroups.com

> I can now confirm that Ralf's rev 338 with your patches
> sbcl
> aldor 1.1.0 binary

Cool... where did you spot a 1.1.0 binary?
Perhaps you mean the release candidate?
http://www.aldor.org/distrib/aldor-linux-i386-glibc2.3-1.1.0-rc.bin

> The only glitch is that when compiling externally,
> fricas expects <file> instead of <file>.lsp

Could you be more verbose? I don't get your point here.

Ralf

leh...@bayou.uni-linz.ac.at

unread,

Aug 18, 2008, 3:34:55 PM8/18/08

to fricas...@googlegroups.com

On Mon, Aug 18, 2008 at 06:07:25PM +0200, Ralf Hemmecke wrote:
> > I can now confirm that Ralf's rev 338 with your patches
> > sbcl
> > aldor 1.1.0 binary
>
> Cool... where did you spot a 1.1.0 binary?
> Perhaps you mean the release candidate?
> http://www.aldor.org/distrib/aldor-linux-i386-glibc2.3-1.1.0-rc.bin

yes. But apparently I built the 64bit one myself.

> > The only glitch is that when compiling externally,
> > fricas expects <file> instead of <file>.lsp
>
> Could you be more verbose? I don't get your point here.

when I do from inside fricas
)co sieve.as
Compiling FriCAS source code from file /home/lehner/atest/sieve.as
using AXIOM-XL compiler and options
-O -Fasy -Fao -Flsp -laxiom -Mno-ALDOR_W_WillObsolete -DAxiom -Y $AXIOM/algebra -I $AXIOM/algebra

the files
sieve.ao sieve.asy sieve.fasl sieve.lsp
are generated. When I do externally
aldor -O -Fasy -Fao -Flsp -Mno-ALDOR_W_WillObsolete -laxiom -DAxiom
-Y$AXIOM/algebra -I$AXIOM/algebra sieve.as
I only get
sieve.ao sieve.asy sieve.lsp
an subsequent
)lib sieve
(1) -> sieve 5

>> System error:
Couldn't load "/home/lehner/atest/1/sieve": file does not exist.

a symbolic link sieve.lsp -> sieve gets around this.
This problem does not appear when sieve.fasl is present.
How do I instruct aldor to generate it?

Franz

Ralf Hemmecke

unread,

Aug 18, 2008, 4:05:27 PM8/18/08

to fricas...@googlegroups.com

>>> The only glitch is that when compiling externally,
>>> fricas expects <file> instead of <file>.lsp
>> Could you be more verbose? I don't get your point here.
> when I do from inside fricas
> )co sieve.as
> Compiling FriCAS source code from file /home/lehner/atest/sieve.as
> using AXIOM-XL compiler and options
> -O -Fasy -Fao -Flsp -laxiom -Mno-ALDOR_W_WillObsolete -DAxiom -Y $AXIOM/algebra -I $AXIOM/algebra
>
> the files
> sieve.ao sieve.asy sieve.fasl sieve.lsp
> are generated. When I do externally
> aldor -O -Fasy -Fao -Flsp -Mno-ALDOR_W_WillObsolete -laxiom -DAxiom
> -Y$AXIOM/algebra -I$AXIOM/algebra sieve.as
> I only get
> sieve.ao sieve.asy sieve.lsp
> an subsequent
> )lib sieve
> (1) -> sieve 5
>
> >> System error:
> Couldn't load "/home/lehner/atest/1/sieve": file does not exist.
>
> a symbolic link sieve.lsp -> sieve gets around this.
> This problem does not appear when sieve.fasl is present.
> How do I instruct aldor to generate it?

No way. Aldor cannot generate .fasl. I think you must lookup the fricas
sources to find out what ")compile" actually does. Waldek once told me
that the .lsp file should be enough, but I maybe wrong.

The only thing that comes now to my mind is the lines

tmp/mko_%.lsp:
echo ')fin' > $@
echo '(compile-file "$(abs_builddir)/lsp/$*.lsp" ' >> $@
echo ' :output-file "$(abs_builddir)/lib/$*.$(FASLEXT)")' >> $@
echo '(quit)' >> $@

(starting at line 296 at
http://fricas.svn.sourceforge.net/viewvc/fricas/branches/aldor-interface/src/aldor/Makefile.in?view=markup)

Maybe this could help you to generate the .fasl file.

Ralf

leh...@bayou.uni-linz.ac.at

unread,

Aug 18, 2008, 4:21:14 PM8/18/08

to fricas...@googlegroups.com

On Mon, Aug 18, 2008 at 10:05:27PM +0200, Ralf Hemmecke wrote:
> No way. Aldor cannot generate .fasl. I think you must lookup the fricas
> sources to find out what ")compile" actually does. Waldek once told me
> that the .lsp file should be enough, but I maybe wrong.

yes, it is enough if it is renamed or linked to <file> without
extension. That's actually no big deal in a Makefile, but perhaps
fricas can be taught to read <file>.lsp directly?

Franz

Bill Page

unread,

Aug 18, 2008, 4:46:12 PM8/18/08

to fricas...@googlegroups.com

On Mon, Aug 18, 2008 at 3:34 PM, <leh...@bayou.uni-linz.ac.at> wrote:
>
> when I do from inside fricas
> )co sieve.as
> Compiling FriCAS source code from file /home/lehner/atest/sieve.as
> using AXIOM-XL compiler and options
> -O -Fasy -Fao -Flsp -laxiom -Mno-ALDOR_W_WillObsolete -DAxiom -Y $AXIOM/algebra -I $AXIOM/algebra
>
> the files
> sieve.ao sieve.asy sieve.fasl sieve.lsp
> are generated. When I do externally
> aldor -O -Fasy -Fao -Flsp -Mno-ALDOR_W_WillObsolete -laxiom -DAxiom
> -Y$AXIOM/algebra -I$AXIOM/algebra sieve.as
> I only get
> sieve.ao sieve.asy sieve.lsp
> an subsequent
> )lib sieve
> (1) -> sieve 5
>
> >> System error:
> Couldn't load "/home/lehner/atest/1/sieve": file does not exist.
>
> a symbolic link sieve.lsp -> sieve gets around this.
> This problem does not appear when sieve.fasl is present.
> How do I instruct aldor to generate it?
>

Since Aldor only generates lisp wouldn't you normally want to compile
the lisp in FriCAS first before using it, or are you specifically
intending to execute it in interpreted mode?

(1) -> )co sieve.lsp
...
(1) -> sieve 10

(1) 4
Type: PositiveInteger

Regards,
Bill Page.

leh...@bayou.uni-linz.ac.at

unread,

Aug 19, 2008, 2:25:12 AM8/19/08

to fricas...@googlegroups.com

On Mon, Aug 18, 2008 at 04:46:12PM -0400, Bill Page wrote:
> Since Aldor only generates lisp wouldn't you normally want to compile
> the lisp in FriCAS first before using it, or are you specifically
> intending to execute it in interpreted mode?

I somehow thought that .ao contains the compiled code, but that's actually
not imported into fricas. Time to learn more about the internals ...

Franz

Ralf Hemmecke

unread,

Aug 19, 2008, 2:42:30 AM8/19/08

to fricas...@googlegroups.com

Right, panAxiom has no idea what .ao means. As far as I understand .ao
is the compiled form of .fm (foam -- First Order Abstract Machine). The
.ao format is somewhat comparable to JAVA .class files, since it is
platform independent. But the only byte code interpreter currently is
the aldor compiler itself (aldor -gloop).

BTW, the aldor compiler can translate .ao into .fm and vice versa.

Ralf

Waldek Hebisch

unread,

Aug 26, 2008, 11:28:56 PM8/26/08

to fricas...@googlegroups.com

Ralf Hemmecke wrote:
> > using Ralf's branch rev 338 + a few patches from Martin.
> > The build goes through, including aldor.
>
> Well, I a really still unsure whether Martin's patch moving away from
> fixnum (29bit) to (integer ... ...) (32bit) is really the way to go with
> SBCL. I'd like to wait for Waldek's comments on my posts that I sent
> related to this topic.
>

I belive that problem we have is theoretically unsolvable:

- Aldor assumes that Sint has at least 32 bit
- Aldor assumes that Sint is the same as SingleInteger
- FriCAS assumes that SingleInter is Lisp fixnum
- sbcl on 32-bit machines has 30 bit fixnums (29 for positive values + sign)

However now I think that Martin way is correct from practial point
of view. Namely, Lisp declaration just specifies maximal size,
but we can safely use just part of that range. So we may get
errors when we 32-bit numbers get passed to code expecting
fixnum, but otherwise we should be fine.

Now, Aldor uses 31 bit range for hashes and Boot code must handle
them. This should pose no problems because relevant Boot code
is mostly untyped. foam_l has several macros which contain Sint,
we really need 32 bits there. FriCAS algebra makes little use
of SingleInteger and is careful to avoid crating large numbers
when using SingleInteger.

So I belive that we should not expect many problems from this
mismatch. In longer run I would like to see such problems fixed,
but in short term the only alternative I see is to say that
the only 32-bit lisp supported by Aldor interface is gcl. Given
that gcl has many known problems, I think that it is better
to support other Lisps, even if support is not perfect.

To say this differently: due to size mismatch we can not depend
on compiler to guarantee type correctness of code using
Sint and SingleInteger. However, the problem is to avoid
overflow and type correctness helps only a little here
-- we can only hope that original authors wrote code
carefully, to avoid creating large numbers (well, at default
safty settings sbcl checks that numbers stay in range,
so we will know if something goes wrong).

--
Waldek Hebisch
heb...@math.uni.wroc.pl

Martin Rubey

unread,

Aug 27, 2008, 2:57:02 AM8/27/08

to fricas...@googlegroups.com

Waldek Hebisch <heb...@math.uni.wroc.pl> writes:

> I believe that problem we have is theoretically unsolvable:

>
> - Aldor assumes that Sint has at least 32 bit

> - Aldor assumes that Sint is the same as SingleInteger

I think that this is incorrect. At least, I do not know of a proof.

> - FriCAS assumes that SingleInter is Lisp fixnum
> - sbcl on 32-bit machines has 30 bit fixnums (29 for positive values + sign)

Martin

Waldek Hebisch

unread,

Aug 27, 2008, 7:14:20 AM8/27/08

to fricas...@googlegroups.com

Martin Rubey wrote:
>
> Waldek Hebisch <heb...@math.uni.wroc.pl> writes:
>
> > I believe that problem we have is theoretically unsolvable:
> >
> > - Aldor assumes that Sint has at least 32 bit
>
> > - Aldor assumes that Sint is the same as SingleInteger
>
> I think that this is incorrect. At least, I do not know of a proof.
>

Well, all I have now is an impression -- people more familar with Aldor
than I am should give definite answer. If this impression is incorrect
and Sint and SingleInteger are really kept separate, then of course
giving them different size will cause no problems.

> > - FriCAS assumes that SingleInter is Lisp fixnum
> > - sbcl on 32-bit machines has 30 bit fixnums (29 for positive values + sign)
>

--
Waldek Hebisch
heb...@math.uni.wroc.pl

Martin Rubey

unread,

Aug 27, 2008, 8:58:45 AM8/27/08

to fricas...@googlegroups.com, Pippijn van Steenhoven, aldor-l

Waldek Hebisch <heb...@math.uni.wroc.pl> writes:

I just was with Franz Lehner, who run into

>> System error:
The value 1152921504606846975 is not of type (SIGNED-BYTE 32).

when trying to use aldor-combinat with 64 bit sbcl. Modifying

- (deftype |SInt| () '(integer #.(- (expt 2 31)) #.(1- (expt 2 31))))
+ (deftype |SInt| () '(integer #.(- (expt 2 63)) #.(1- (expt 2 63))))

made the problem go away. I think this suggests that aldor's hash algorithm
uses different hash sizes depending on the number of bits available.

It would be nice, if aldor would accept an option --hash-size= that sets the
number of bits the hashing algorithm should use.

Of course, this makes little sense if it's too much work. In this case, we
should simply use

+ (deftype |SInt| () 'integer)

in foam_l.lisp.

BTW, there was another bug in declare-prog. It really should read

+;; name-result is a list, the car is the name of the function to be declared,
+;; the cdr is the list of return values
+;; params is a list of pairs, the car of each is the name of the argument, the
+;; cdr is its type.
+
+;; in the ANSI Common Lisp ftype function declaration, the names of the
+;; arguments do not appear, actually. In GCL, they did.
+
+;; Example:
+;; (declare-prog
+;; (|C25-csspecies-generBaseFn| |Clos| |Clos| |Clos| |Clos|)
+;; ((|e1| |Env|)))

(defmacro declare-prog (name-result params)
- `(proclaim '(function ,(car name-result) ,params ,@(cdr name-result))))
+ `(proclaim '(ftype (function
+ ,(mapcar #'cadr params)

+ (values ,@(cdr name-result)))
+ ,(car name-result))))

Doesn't seem to have much effect, though.

Martin

Waldek Hebisch

unread,

Aug 27, 2008, 2:37:00 PM8/27/08

to fricas...@googlegroups.com

Martin Rubey wrote:
> I just was with Franz Lehner, who run into
>
> >> System error:
> The value 1152921504606846975 is not of type (SIGNED-BYTE 32).
>
> when trying to use aldor-combinat with 64 bit sbcl. Modifying
>
> - (deftype |SInt| () '(integer #.(- (expt 2 31)) #.(1- (expt 2 31))))
> + (deftype |SInt| () '(integer #.(- (expt 2 63)) #.(1- (expt 2 63))))
>
> made the problem go away. I think this suggests that aldor's hash algorithm
> uses different hash sizes depending on the number of bits available.
>

1152921504606846975 is exactly MOST-POSITIVE-FIXNUM. I do not think
it came from hash, rather somewhere there is explicit MOST-POSITIVE-FIXNUM.
In fact, in trunk we have:

(defmacro |SIntMax| () `(the |SInt| most-positive-fixnum))

in foam_l.lisp -- it seems that your patch does not include change
to this line.

> BTW, there was another bug in declare-prog. It really should read
>
> +;; name-result is a list, the car is the name of the function to be declared,
> +;; the cdr is the list of return values
> +;; params is a list of pairs, the car of each is the name of the argument, the
> +;; cdr is its type.
> +
> +;; in the ANSI Common Lisp ftype function declaration, the names of the
> +;; arguments do not appear, actually. In GCL, they did.
> +
> +;; Example:
> +;; (declare-prog
> +;; (|C25-csspecies-generBaseFn| |Clos| |Clos| |Clos| |Clos|)
> +;; ((|e1| |Env|)))
> (defmacro declare-prog (name-result params)
> - `(proclaim '(function ,(car name-result) ,params ,@(cdr name-result))))
> + `(proclaim '(ftype (function
> + ,(mapcar #'cadr params)
> + (values ,@(cdr name-result)))
> + ,(car name-result))))
>
>
>
> Doesn't seem to have much effect, though.
>

IIRC GCL allows ommiting the type of function, while Commom Lisp
spec reqires it. The line

,(or (cadr name-result) 't))

was intended to archive the same effect as in GCL -- if there is
no type than (cdr name-result) is NIL, (car NIL) is again NIL,
so or picks T -- in other words missing type should default to T.

--
Waldek Hebisch
heb...@math.uni.wroc.pl

Martin Rubey

unread,

Aug 28, 2008, 7:32:55 AM8/28/08

to fricas...@googlegroups.com

Waldek Hebisch <heb...@math.uni.wroc.pl> writes:

> Martin Rubey wrote:
> > I just was with Franz Lehner, who run into
> >
> > >> System error:
> > The value 1152921504606846975 is not of type (SIGNED-BYTE 32).
> >
> > when trying to use aldor-combinat with 64 bit sbcl. Modifying
> >
> > - (deftype |SInt| () '(integer #.(- (expt 2 31)) #.(1- (expt 2 31))))
> > + (deftype |SInt| () '(integer #.(- (expt 2 63)) #.(1- (expt 2 63))))
> >
> > made the problem go away. I think this suggests that aldor's hash algorithm
> > uses different hash sizes depending on the number of bits available.
> >
>
> 1152921504606846975 is exactly MOST-POSITIVE-FIXNUM. I do not think
> it came from hash, rather somewhere there is explicit MOST-POSITIVE-FIXNUM.
> In fact, in trunk we have:
>
> (defmacro |SIntMax| () `(the |SInt| most-positive-fixnum))
>
> in foam_l.lisp -- it seems that your patch does not include change
> to this line.

Oh, good catch!

Franz, could you try?

Yes, but there are examples of code generated by aldor, eg.

where we actually have multiple values! I believe that

(values ,@(cdr name-result))

is "more" correct, don't you think?

Martin

leh...@bayou.uni-linz.ac.at

unread,

Aug 28, 2008, 10:09:01 AM8/28/08

to fricas...@googlegroups.com

On Wed, Aug 27, 2008 at 08:37:00PM +0200, Waldek Hebisch wrote:

> (defmacro |SIntMax| () `(the |SInt| most-positive-fixnum))
>
> in foam_l.lisp -- it seems that your patch does not include change
> to this line.

which would be
(defmacro |SIntMin| () #.(-(expt 2 63)))
(defmacro |SIntMax| () #.(1- (expt 2 63)))
?
sorry, I don't speak lisp.

Franz

Waldek Hebisch

unread,

Aug 28, 2008, 10:37:53 AM8/28/08

to fricas...@googlegroups.com

(defmacro |SIntMax| () '(the |SInt| (1- (expt 2 31))))

This, together with the definition of SInt that Martin gave:

(deftype |SInt| () '(integer #.(- (expt 2 31)) #.(1- (expt 2 31))))

--
Waldek Hebisch
heb...@math.uni.wroc.pl

Martin Rubey

unread,

Aug 28, 2008, 10:47:40 AM8/28/08

to fricas...@googlegroups.com

Waldek Hebisch <heb...@math.uni.wroc.pl> writes:

Ah, now I understand... The error did not occur because Aldor adapts the hash
according to number of available bits, but rather because SIntMax became
2^63-1, which is bigger than what SInt can hold...

Franz, could you revert to

(deftype |SInt| () '(integer #.(- (expt 2 31)) #.(1- (expt 2 31)))):

(defmacro |SIntMax| () '(the |SInt| (1- (expt 2 31))))

and try again?

Martin