aldor fricas interoperability... call for testers

7 views
Skip to first unread message

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.

> ===================================================================
> --- 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.


--
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)


@@ -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: 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.

Compiling Lisp source code from file ./fact.lsp
Issuing )library command for fact
Reading /home/martin/martin/Axiom/fact.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.
STYLE-WARNING: redefining |bcIndefiniteIntegrate| in DEFUN
STYLE-WARNING: redefining |bcDefiniteIntegrate| in DEFUN
STYLE-WARNING: redefining |bcSum| in DEFUN
STYLE-WARNING: redefining |bcProduct| in DEFUN
STYLE-WARNING: redefining |bcDifferentiate| in DEFUN
STYLE-WARNING: redefining |bcDraw| in DEFUN
STYLE-WARNING: redefining |bcSeries| in DEFUN
STYLE-WARNING: redefining |bcLimit| in DEFUN
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.
STYLE-WARNING: redefining |htSystemVariables| in DEFUN
STYLE-WARNING: redefining |htGloss| in DEFUN
STYLE-WARNING: redefining |htGreekSearch| in DEFUN
STYLE-WARNING: redefining |htTextSearch| in DEFUN
STYLE-WARNING: redefining |htTutorialSearch| in DEFUN
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.
STYLE-WARNING: redefining |buildLibdb| in DEFUN
STYLE-WARNING: redefining |getParentsFor| in DEFUN
STYLE-WARNING: redefining |parentsOf| in DEFUN
STYLE-WARNING: redefining |folks| in DEFUN
STYLE-WARNING: redefining |ancestorsOf| in DEFUN
STYLE-WARNING: redefining |extendLocalLibdb| in DEFUN
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.
STYLE-WARNING: redefining |grepConstruct| in DEFUN
STYLE-WARNING: redefining |oPage| in DEFUN
STYLE-WARNING: redefining |oPageFrom| in DEFUN
STYLE-WARNING: redefining |aPage| in DEFUN
STYLE-WARNING: redefining |spadType| in DEFUN
STYLE-WARNING: redefining |spadSys| in DEFUN
STYLE-WARNING: redefining |aokSearch| in DEFUN
STYLE-WARNING: redefining |genSearch| in DEFUN
STYLE-WARNING: redefining |docSearch| in DEFUN
STYLE-WARNING: redefining |aSearch| in DEFUN
STYLE-WARNING: redefining |oSearch| in DEFUN
STYLE-WARNING: redefining |cSearch| in DEFUN
STYLE-WARNING: redefining |kSearch| in DEFUN
STYLE-WARNING: redefining |detailedSearch| in DEFUN
Loading /tmp/lib/fricas/target/i686-pc-linux/autoload/br-util.
STYLE-WARNING: redefining |browserAutoloadOnceTrigger| in DEFUN
STYLE-WARNING: redefining |form2HtString| in DEFUN
STYLE-WARNING: redefining |dbName| in DEFUN
STYLE-WARNING: redefining |dbPart| in DEFUN
STYLE-WARNING: redefining |dbComments| in DEFUN
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.


(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):

@@ -50,7 +50,7 @@
compile-as-file cases

|Clos| |Char| |Bool| |Byte| |HInt| |SInt| |BInt| |SFlo| |DFlo| |Ptr|
- |Word| |Arb| |Env| |Level| |Arr| |Record|
+ |Word| |Arb| |Env| |Level| |Arr| |Record| |Nil|

Greg


Martin Rubey

unread,
Aug 5, 2008, 9:34:47 AM8/5/08
to fricas...@googlegroups.com
Gregory Vanuxem <g.va...@orange.fr> writes:

> > 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):
>
> @@ -50,7 +50,7 @@
> compile-as-file cases
>
> |Clos| |Char| |Bool| |Byte| |HInt| |SInt| |BInt| |SFlo| |DFlo| |Ptr|
> - |Word| |Arb| |Env| |Level| |Arr| |Record|
> + |Word| |Arb| |Env| |Level| |Arr| |Record| |Nil|

WOW! That did it - nearly:

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

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

STYLE-WARNING: redefining |oldCompilerAutoloadOnceTrigger| in DEFUN
STYLE-WARNING: redefining |sublisV| in DEFUN
STYLE-WARNING: redefining |Category| in DEFUN
STYLE-WARNING: redefining |mkCategory| in DEFUN
STYLE-WARNING: redefining |compileSpad2Cmd| in DEFUN
STYLE-WARNING: redefining |convertSpadToAsFile| in DEFUN
STYLE-WARNING: redefining |compilerDoit| in DEFUN
STYLE-WARNING: redefining |compilerDoitWithScreenedLisplib| in DEFUN
STYLE-WARNING: redefining |cons5| in DEFUN

(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.)

(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>)
0] backtrace

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)


@@ -50,7 +50,7 @@
compile-as-file cases

|Clos| |Char| |Bool| |Byte| |HInt| |SInt| |BInt| |SFlo| |DFlo| |Ptr|
- |Word| |Arb| |Env| |Level| |Arr| |Record|
+ |Word| |Arb| |Env| |Level| |Arr| |Record| |Nil|

|ClosInit| |CharInit| |BoolInit| |ByteInit| |HIntInit| |SIntInit|
|BIntInit| |SFloInit| |DFloInit| |PtrInit| |WordInit| |ArbInit| |EnvInit|

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.


STYLE-WARNING: redefining |bcIndefiniteIntegrate| in DEFUN
STYLE-WARNING: redefining |bcDefiniteIntegrate| in DEFUN
STYLE-WARNING: redefining |bcSum| in DEFUN
STYLE-WARNING: redefining |bcProduct| in DEFUN
STYLE-WARNING: redefining |bcDifferentiate| in DEFUN
STYLE-WARNING: redefining |bcDraw| in DEFUN
STYLE-WARNING: redefining |bcSeries| in DEFUN
STYLE-WARNING: redefining |bcLimit| in DEFUN

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.


STYLE-WARNING: redefining |htSystemVariables| in DEFUN
STYLE-WARNING: redefining |htGloss| in DEFUN
STYLE-WARNING: redefining |htGreekSearch| in DEFUN
STYLE-WARNING: redefining |htTextSearch| in DEFUN
STYLE-WARNING: redefining |htTutorialSearch| in DEFUN

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.


STYLE-WARNING: redefining |buildLibdb| in DEFUN
STYLE-WARNING: redefining |getParentsFor| in DEFUN
STYLE-WARNING: redefining |parentsOf| in DEFUN
STYLE-WARNING: redefining |folks| in DEFUN
STYLE-WARNING: redefining |ancestorsOf| in DEFUN
STYLE-WARNING: redefining |extendLocalLibdb| in DEFUN

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.


STYLE-WARNING: redefining |grepConstruct| in DEFUN
STYLE-WARNING: redefining |oPage| in DEFUN
STYLE-WARNING: redefining |oPageFrom| in DEFUN
STYLE-WARNING: redefining |aPage| in DEFUN
STYLE-WARNING: redefining |spadType| in DEFUN
STYLE-WARNING: redefining |spadSys| in DEFUN
STYLE-WARNING: redefining |aokSearch| in DEFUN
STYLE-WARNING: redefining |genSearch| in DEFUN
STYLE-WARNING: redefining |docSearch| in DEFUN
STYLE-WARNING: redefining |aSearch| in DEFUN
STYLE-WARNING: redefining |oSearch| in DEFUN
STYLE-WARNING: redefining |cSearch| in DEFUN
STYLE-WARNING: redefining |kSearch| in DEFUN
STYLE-WARNING: redefining |detailedSearch| in DEFUN

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


STYLE-WARNING: redefining |browserAutoloadOnceTrigger| in DEFUN
STYLE-WARNING: redefining |form2HtString| in DEFUN
STYLE-WARNING: redefining |dbName| in DEFUN
STYLE-WARNING: redefining |dbPart| in DEFUN
STYLE-WARNING: redefining |dbComments| in DEFUN

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.

> Index: src/interp/foam_l.lisp
> ===================================================================
> --- src/interp/foam_l.lisp (revision 336)
> +++ src/interp/foam_l.lisp (working copy)
> @@ -50,7 +50,7 @@
> compile-as-file cases
>
> |Clos| |Char| |Bool| |Byte| |HInt| |SInt| |BInt| |SFlo| |DFlo| |Ptr|
> - |Word| |Arb| |Env| |Level| |Arr| |Record|
> + |Word| |Arb| |Env| |Level| |Arr| |Record| |Nil|
>
> |ClosInit| |CharInit| |BoolInit| |ByteInit| |HIntInit| |SIntInit|
> |BIntInit| |SFloInit| |DFloInit| |PtrInit| |WordInit| |ArbInit| |EnvInit|

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

> @@ -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

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.

> That patch (at least exporting |Nil| should be applied by Waldek in
> trunk. I've seen such a patch in open-axiom today.
>
> > Index: src/interp/foam_l.lisp
> > ===================================================================
> > --- src/interp/foam_l.lisp (revision 336)
> > +++ src/interp/foam_l.lisp (working copy)
> > @@ -50,7 +50,7 @@
> > compile-as-file cases
> >
> > |Clos| |Char| |Bool| |Byte| |HInt| |SInt| |BInt| |SFlo| |DFlo| |Ptr|
> > - |Word| |Arb| |Env| |Level| |Arr| |Record|
> > + |Word| |Arb| |Env| |Level| |Arr| |Record| |Nil|
> >
> > |ClosInit| |CharInit| |BoolInit| |ByteInit| |HIntInit| |SIntInit|
> > |BIntInit| |SFloInit| |DFloInit| |PtrInit| |WordInit| |ArbInit| |EnvInit|
>
> This rest is not justified whether it doesn't break anything else.
>
> > @@ -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))))

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.


STYLE-WARNING: redefining |bcIndefiniteIntegrate| in DEFUN
STYLE-WARNING: redefining |bcDefiniteIntegrate| in DEFUN
STYLE-WARNING: redefining |bcSum| in DEFUN
STYLE-WARNING: redefining |bcProduct| in DEFUN
STYLE-WARNING: redefining |bcDifferentiate| in DEFUN
STYLE-WARNING: redefining |bcDraw| in DEFUN
STYLE-WARNING: redefining |bcSeries| in DEFUN
STYLE-WARNING: redefining |bcLimit| in DEFUN

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.


STYLE-WARNING: redefining |htSystemVariables| in DEFUN
STYLE-WARNING: redefining |htGloss| in DEFUN
STYLE-WARNING: redefining |htGreekSearch| in DEFUN
STYLE-WARNING: redefining |htTextSearch| in DEFUN
STYLE-WARNING: redefining |htTutorialSearch| in DEFUN

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.


STYLE-WARNING: redefining |buildLibdb| in DEFUN
STYLE-WARNING: redefining |getParentsFor| in DEFUN
STYLE-WARNING: redefining |parentsOf| in DEFUN
STYLE-WARNING: redefining |folks| in DEFUN
STYLE-WARNING: redefining |ancestorsOf| in DEFUN
STYLE-WARNING: redefining |extendLocalLibdb| in DEFUN

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.


STYLE-WARNING: redefining |grepConstruct| in DEFUN
STYLE-WARNING: redefining |oPage| in DEFUN
STYLE-WARNING: redefining |oPageFrom| in DEFUN
STYLE-WARNING: redefining |aPage| in DEFUN
STYLE-WARNING: redefining |spadType| in DEFUN
STYLE-WARNING: redefining |spadSys| in DEFUN
STYLE-WARNING: redefining |aokSearch| in DEFUN
STYLE-WARNING: redefining |genSearch| in DEFUN
STYLE-WARNING: redefining |docSearch| in DEFUN
STYLE-WARNING: redefining |aSearch| in DEFUN
STYLE-WARNING: redefining |oSearch| in DEFUN
STYLE-WARNING: redefining |cSearch| in DEFUN
STYLE-WARNING: redefining |kSearch| in DEFUN
STYLE-WARNING: redefining |detailedSearch| in DEFUN

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


STYLE-WARNING: redefining |browserAutoloadOnceTrigger| in DEFUN
STYLE-WARNING: redefining |form2HtString| in DEFUN
STYLE-WARNING: redefining |dbName| in DEFUN
STYLE-WARNING: redefining |dbPart| in DEFUN
STYLE-WARNING: redefining |dbComments| in DEFUN

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

(2) -> isomorphismTypes()$S
STYLE-WARNING: redefining |MAKE-Struct-testa-5| in DEFUN
STYLE-WARNING: redefining |MAKE-Struct-testa-7| in DEFUN
STYLE-WARNING: redefining |MAKE-Struct-testa-8| in DEFUN
STYLE-WARNING: redefining |MAKE-Struct-testa-10| in DEFUN
STYLE-WARNING: redefining |MAKE-Struct-testa-12| in DEFUN
STYLE-WARNING: redefining |MAKE-Struct-testa-14| in DEFUN
STYLE-WARNING: redefining |C0-testa-testa| in DEFUN
STYLE-WARNING: redefining |C1-testa-IsomorphismTypeCategory| in DEFUN
STYLE-WARNING: redefining |C2-testa-ACIsomorphismType| in DEFUN
STYLE-WARNING: redefining |C3-testa-addLevel0| in DEFUN
STYLE-WARNING: redefining |C4-testa-addLevel1| in DEFUN
STYLE-WARNING: redefining |C5-testa-CombinatorialSpecies| in DEFUN
STYLE-WARNING: redefining |C6-testa-addLevel0| in DEFUN
STYLE-WARNING: redefining |C7-testa-addLevel1| in DEFUN
STYLE-WARNING: redefining |C8-testa-isomorphismTypes| in DEFUN
STYLE-WARNING: redefining |C9-testa-addLevel0| in DEFUN
STYLE-WARNING: redefining |C10-testa-addLevel1| in DEFUN
STYLE-WARNING: redefining |C11-testa-axextend-init| in DEFUN

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
>>> Index: src/interp/foam_l.lisp
>>> ===================================================================
>>> --- src/interp/foam_l.lisp (revision 336)
>>> +++ src/interp/foam_l.lisp (working copy)
>>> @@ -50,7 +50,7 @@
>>> compile-as-file cases
>>>
>>> |Clos| |Char| |Bool| |Byte| |HInt| |SInt| |BInt| |SFlo| |DFlo| |Ptr|
>>> - |Word| |Arb| |Env| |Level| |Arr| |Record|
>>> + |Word| |Arb| |Env| |Level| |Arr| |Record| |Nil|
>>>
>>> |ClosInit| |CharInit| |BoolInit| |ByteInit| |HIntInit| |SIntInit|
>>> |BIntInit| |SFloInit| |DFloInit| |PtrInit| |WordInit| |ArbInit| |EnvInit|
>> This rest is not justified whether it doesn't break anything else.
>>
>>> @@ -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))))
>
> 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.
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:

(defmacro |SIntMin| () `(the |SInt| most-negative-fixnum))
(defmacro |SIntMax| () `(the |SInt| most-positive-fixnum))

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