aldor fricas connection (first success libaxiom.al can be compiled)
Ralf Hemmecke
I've just committed my recent work to the aldor-interface branch.
http://fricas.svn.sourceforge.net/viewvc/fricas/branches/aldor-interface/src/aldor/
I'd like to hear from people who test the compilation process on their
machines.
mkdir fricas
cd fricas
FRICASSVN=https://fricas.svn.sourceforge.net/svnroot/fricas
svn co $FRICASSVN/braches/aldor-interface fricas-src
mkdir fricas-build
cd fricas-build
../fricas-src/configure
make
cd src/aldor
make
(The last 'make' takes about 24 min on my laptop.)
The resulting libaxiom.al is probably not yet useful, but it's a first
milestone.
I'll add more documentation later, but it would be helpful if I get
comments of unclear parts in those files.
Ralf
Themos Tsikas
> svn co $FRICASSVN/braches/aldor-interface fricas-src
typo
-braches
+branches
________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.
This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs.
________________________________________________________________________
Bill Page
When trying to build the aldor interface according to your recipe
below the make script ended in the following error:
Generating dependency of subsetc.
DAASE=/home/page/fricas-aldor/fricas-build/target/x86_64-unknown-linux
/home/page/fricas-aldor/fricas-build/target/x86_64-unknown-linux/bin/AXIOMsys
< tmp/dep_subsetc.lsp > tmp/dep_subsetc.log
test -f gendeps/subsetc.dep
touch aldordepfiles
cliques libaxiom.lst > cliques.mk
/bin/sh: cliques: command not found
make: *** [cliques.mk] Error 127
--------
The problem is caused because I think you intended to run the program
'cliques' from the current directory. In this case the command should
be
./cliques libaxiom.lst > cliques.mk
After making this change:
root@sage:~/fricas-aldor/fricas-src/src/aldor# diff -au
Makefile.in.orig Makefile.in
--- Makefile.in.orig 2008-07-26 10:44:59.000000000 -0700
+++ Makefile.in 2008-07-26 10:45:38.000000000 -0700
@@ -262,7 +262,7 @@
$(ALDOR) $(CLIQUEOPTS) -dTRACE $<
cliques.mk: libaxiom.lst cliques domaindepfiles aldordepfiles
- cliques libaxiom.lst > $@
+ ./cliques libaxiom.lst > $@
###################################################################
It completed normally and I now have a file:
root@sage:~/fricas-aldor# ls -l fricas-build/src/aldor/al/libaxiom.al
-rw-r--r-- 1 root root 8804000 Jul 26 10:41
fricas-build/src/aldor/al/libaxiom.al
This file will have to be moved somewhere else in the FriCAS target
directory. Do you have a more complete version of this Makefile not
yet checked-in? I will try to set the rest up manually and let you
know how it goes.
Has anyone actually tried an aldor compile with version of libaxiom in
FriCAS yet?
Regards,
Bill Page.
Martin Rubey
missing # signs in lisp code.
I'll check them in, OK?
Index: gendepap.lsp
===================================================================
--- gendepap.lsp (revision 320)
+++ gendepap.lsp (working copy)
@@ -28,7 +28,7 @@
(defun init-forms (filename)
(let ((ilist (cdr (with-open-file (str (pathname filename))
(read str)))))
- (mapcan '(lambda (x) (and (eq (car x) '|Export|) (list x))) ilist)))
+ (mapcan #'(lambda (x) (and (eq (car x) '|Export|) (list x))) ilist)))
; *initforms* lists all the export forms of "initlist.ap"
(setq *initforms* (init-forms "initlist.ap"))
@@ -49,7 +49,7 @@
; from an Aldor source file. In particular for axlit.as and axextend.as
; we have to treat some tags differently. For example, an |Extend|
; should require full information of the extended domain.
-(setq *extends-axiom-domains* nil))
+(setq *extends-axiom-domains* nil)
; We introduce some debugging information.
(defun debug-print (x y)
@@ -95,7 +95,7 @@
((eq (car apform) '|Extend|) (test-easy (cadr apform)))
((member (car apform) '(|Define| |Export| |Extend|))
(test-easy1 (cadr apform)))
- (t nil)))))
+ (t nil))))
; Now we have to check whether the form looks like
; (|Declare| |SomeName| (|Apply| -> (|Declare| |#1| |Type|) ...))
@@ -735,7 +735,7 @@
(member var (env-vars env)))
(defun map-find-deps (env lst)
- (mapcan (lambda (x) (find-deps env x)) lst))
+ (mapcan #'(lambda (x) (find-deps env x)) lst))
; Return the list of argument names of a function.
; Only |Comma| and |Declare| is interesting here.
Index: Makefile.in
===================================================================
--- Makefile.in (revision 320)
+++ Makefile.in (working copy)
@@ -198,7 +198,7 @@
echo ")fin" > $@
echo '(with-open-file (str (pathname "tmp/attrib.all")' >> $@
echo ' :direction :output) (dolist (a ' >> $@
- echo "(mapcar 'car (mapcan '(lambda (x) (getdatabase x 'ATTRIBUTES))
; (|allConstructors|))))" >> $@
+ echo "(mapcar #'car (mapcan #'(lambda (x) (getdatabase x 'ATTRIBUTES))
; (|allConstructors|))))" >> $@
echo '(format str "~a~%" a)))' >> $@
echo "(quit)" >> $@
Bill Page
> ...
> I now have a file:
>
> root@sage:~/fricas-aldor# ls -l fricas-build/src/aldor/al/libaxiom.al
> -rw-r--r-- 1 root root 8804000 Jul 26 10:41
> fricas-build/src/aldor/al/libaxiom.al
>
> This file will have to be moved somewhere else in the FriCAS target
> directory. Do you have a more complete version of this Makefile not
> yet checked-in? I will try to set the rest up manually and let you
> know how it goes.
I did the following copy:
$ cd ~/fricas-aldor/fricas-build/target/x86_64-unknown-linux
$ cp ~/fricas-aldor/fricas-build/src/aldor/al/libaxiom.al algebra
Created a test file:
-- test.as --
# include "axiom.as"
import from Boolean, Integer, NonNegativeInteger;
sieve(n: Integer): Integer == {
isprime: OneDimensionalArray Boolean :=
new(n::NonNegativeInteger, true);
np:Integer := 0;
for p in 2..n | isprime p repeat {
np := np + 1;
for i in (p+p)..n by p repeat isprime i := false;
}
np
}
--
And then the the usual
$ export AXIOM=`pwd'
$ $AXIOM/bin/AXIOMsys
FriCAS (AXIOM fork) Computer Algebra System
Version: FriCAS 2008-05-28
Timestamp: Saturday July 26, 2008 at 08:13:11
(1) -> )co test.as
Compiling FriCAS source code from file
/home/page/fricas-aldor/fricas-build/target/x86_64-unknown-linux/test.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 ./test.lsp
Issuing )library command for test
Reading /home/page/fricas-aldor/fricas-build/target/x86_64-unknown-linux/test.asy
(1) -> sieve(10)
>> System error:
AxiomXL file "ARRAY1" is missing!
------
Well, I guess the good news is that there were no compile errors. :-)
I did not yet do anything about compiling 'axlit.as' and 'axextend.as'
as I guessed might be necessary during the presentation today. But
since the error message does not mention these, I might well be
mistaken about that.
I am quite uncertain how to debug past this point. Perhaps it is still
some unsatisfied dependency?
Regards,
Bill Page.
Ralf Hemmecke
On 07/26/2008 08:04 PM, Martin Rubey wrote:
> I have some more trivial changes to make it compatible with Common Lisp, mostly
> missing # signs in lisp code.
>
> I'll check them in, OK?
Looks OK to me. Go ahead... more comments below.
Ralf
> Index: gendepap.lsp
> ===================================================================
> --- gendepap.lsp (revision 320)
> +++ gendepap.lsp (working copy)
> @@ -28,7 +28,7 @@
> (defun init-forms (filename)
> (let ((ilist (cdr (with-open-file (str (pathname filename))
> (read str)))))
> - (mapcan '(lambda (x) (and (eq (car x) '|Export|) (list x))) ilist)))
> + (mapcan #'(lambda (x) (and (eq (car x) '|Export|) (list x))) ilist)))
Could someone explain me what and why there must be a # sign. Thanks.
It's really magic that something works at all with me knowing almost no
lisp at all. ;-)
> ; *initforms* lists all the export forms of "initlist.ap"
> (setq *initforms* (init-forms "initlist.ap"))
> @@ -49,7 +49,7 @@
> ; from an Aldor source file. In particular for axlit.as and axextend.as
> ; we have to treat some tags differently. For example, an |Extend|
> ; should require full information of the extended domain.
> -(setq *extends-axiom-domains* nil))
> +(setq *extends-axiom-domains* nil)
That's interesting, how can that have worked on my computer? Maybe it
slipped in before I finally committed. Hmmmm....
> ; We introduce some debugging information.
> (defun debug-print (x y)
> @@ -95,7 +95,7 @@
> ((eq (car apform) '|Extend|) (test-easy (cadr apform)))
> ((member (car apform) '(|Define| |Export| |Extend|))
> (test-easy1 (cadr apform)))
> - (t nil)))))
> + (t nil))))
Another additional paren? How broken must my lisp be that it didn't
complain?
Waldek Hebisch
> On 07/26/2008 08:04 PM, Martin Rubey wrote:
> > - (mapcan '(lambda (x) (and (eq (car x) '|Export|) (list x))) ilist)))
> > + (mapcan #'(lambda (x) (and (eq (car x) '|Export|) (list x))) ilist)))
>
> Could someone explain me what and why there must be a # sign. Thanks.
> It's really magic that something works at all with me knowing almost no
> lisp at all. ;-)
>
Think about types: '(lambda ...) is a list, mapcan expects a function.
#' is just a shorthand to convert lambda list to a function. An
expanded version would be:
(function (lambda (x) (and (eq (car x) '|Export|) (list x))))
and function above is just a convertion to function type.
> > ; should require full information of the extended domain.
> > -(setq *extends-axiom-domains* nil))
> > +(setq *extends-axiom-domains* nil)
>
> That's interesting, how can that have worked on my computer? Maybe it
> slipped in before I finally committed. Hmmmm....
It works in GCL.
>
> > - (t nil)))))
> > + (t nil))))
>
> Another additional paren? How broken must my lisp be that it didn't
> complain?
Now you know what Lisp folks think about GCL...
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Waldek Hebisch
I get the same error. I would help if somebody with working
interface would post the Lisp file produced by:
aldor -O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom -Y $AXIOM/algebra test.as
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Bill Page
> Bill Page wrote:
>>
>> >> System error:
>> AxiomXL file "ARRAY1" is missing!
>>
>
On Sun, Jul 27, 2008 at 2:06 AM, Waldek Hebisch wrote:
> I get the same error. I would help if somebody with working
> interface would post the Lisp file produced by:
>
> aldor -O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom -Y $AXIOM/algebra test.as
>
Waldek, do you require the result of this command specifically or is
the following information sufficient?
At the url below is my test tree for the fricas-aldor interface. In
the root is the file 'test.as' and files resulting from of doing
(1) -> )co test
(1)-> sieve(10)
in FriCAS.
http://sage.math.washington.edu/home/page/fricas-aldor/
-------
root@sage:~/fricas-aldor# fricas -nox
GCL (GNU Common Lisp) 2.6.8 CLtL1 Nov 9 2007 07:47:56
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
FriCAS (AXIOM fork) Computer Algebra System
Version: FriCAS 2007-10-02
Timestamp: Friday November 9, 2007 at 19:35:06
-----------------------------------------------------------------------------
Issue )copyright to view copyright notices.
Issue )summary for a summary of useful system commands.
Issue )quit to leave FriCAS and return to shell.
-----------------------------------------------------------------------------
(1) ->
(1) -> )co test.as
Compiling FriCAS source code from file
/home/page/fricas-aldor/test.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 ./test.lsp
Issuing )library command for test
Reading /home/page/fricas-aldor/test.asy
Loading /usr/local/lib/axiom/target/x86_64-unknown-linux/autoload/bc-matrix.
Loading /usr/local/lib/axiom/target/x86_64-unknown-linux/autoload/bc-misc.
Loading /usr/local/lib/axiom/target/x86_64-unknown-linux/autoload/bc-solve.
Loading /usr/local/lib/axiom/target/x86_64-unknown-linux/autoload/bc-util.
Loading /usr/local/lib/axiom/target/x86_64-unknown-linux/autoload/ht-util.
Loading /usr/local/lib/axiom/target/x86_64-unknown-linux/autoload/htsetvar.
Loading /usr/local/lib/axiom/target/x86_64-unknown-linux/autoload/ht-root.
Loading /usr/local/lib/axiom/target/x86_64-unknown-linux/autoload/br-con.
Loading /usr/local/lib/axiom/target/x86_64-unknown-linux/autoload/br-data.
Loading /usr/local/lib/axiom/target/x86_64-unknown-linux/autoload/showimp.
Loading /usr/local/lib/axiom/target/x86_64-unknown-linux/autoload/br-op1.
Loading /usr/local/lib/axiom/target/x86_64-unknown-linux/autoload/br-op2.
Loading /usr/local/lib/axiom/target/x86_64-unknown-linux/autoload/br-search.
Loading /usr/local/lib/axiom/target/x86_64-unknown-linux/autoload/br-util.
Loading /usr/local/lib/axiom/target/x86_64-unknown-linux/autoload/topics.
Loading /usr/local/lib/axiom/target/x86_64-unknown-linux/autoload/br-prof.
Loading /usr/local/lib/axiom/target/x86_64-unknown-linux/autoload/br-saturn.
(1) -> sieve(10)
Loading
/usr/local/lib/axiom/target/x86_64-unknown-linux/algebra/ARRAY1.o
for domain OneDimensionalArray
Loading
/usr/local/lib/axiom/target/x86_64-unknown-linux/algebra/UNISEG.o
for domain UniversalSegment
(1) 4
Type: PositiveInteger
(2) -> )q
-----
Regards,
Bill Page.
Waldek Hebisch
>
> > ...
> > Bill Page wrote:
> >>
> >> >> System error:
> >> AxiomXL file "ARRAY1" is missing!
> >>
> >
>
> On Sun, Jul 27, 2008 at 2:06 AM, Waldek Hebisch wrote:
>
> > I get the same error. I would help if somebody with working
> > interface would post the Lisp file produced by:
> >
> > aldor -O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom -Y $AXIOM/algebra test.as
> >
>
> Waldek, do you require the result of this command specifically or is
> the following information sufficient?
>
Thanks. Compiling with new libaxiom.al gives several line like
(g-boolean "BOOLEAN" |initializer| "")
in file-imports part of the generated Lisp file. Those lines
are absent in the good version.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Bill Page
> ...
> Compiling with new libaxiom.al gives several line like
>
> (g-boolean "BOOLEAN" |initializer| "")
>
> in file-imports part of the generated Lisp file. Those lines
> are absent in the good version.
>
Interesting ... however I have no idea what that might imply. :-(
Here is one more data point: The 'libaxiom.al' file produced by the
new method is a little *smaller* than the one produced the old way:
root@sage:~/fricas-aldor# ls -l
/usr/local/lib/axiom/target/x86_64-unknown-linux/algebra/libaxiom.al
-rw-r--r-- 1 root root 9112868 Nov 10 2007
/usr/local/lib/axiom/target/x86_64-unknown-linux/algebra/libaxiom.al
root@sage:~/fricas-aldor# ls -l
./fricas-build/target/x86_64-unknown-linux/algebra/libaxiom.al
-rw-r--r-- 1 root root 8804000 Jul 26 11:05
./fricas-build/target/x86_64-unknown-linux/algebra/libaxiom.al
This suggests again that perhaps it does not include all the domains
that it should.
Regards,
Bill Page.
leh...@bayou.uni-linz.ac.at
> I get the same error. I would help if somebody with working
> interface would post the Lisp file produced by:
>
> aldor -O -Fasy -Fao -Flsp -laxiom -Mno-AXL_W_WillObsolete -DAxiom -Y $AXIOM/algebra test.as
Attached is aldor 1.1.0 and fricas rev 276, with ver 2 of the aldor interface
on debian etch amd64.
regards
Franz
Waldek Hebisch
>
> On Sun, Jul 27, 2008 at 3:12 AM, Waldek Hebisch wrote:
> > ...
> > Compiling with new libaxiom.al gives several line like
> >
> > (g-boolean "BOOLEAN" |initializer| "")
> >
> > in file-imports part of the generated Lisp file. Those lines
> > are absent in the good version.
> >
>
> Interesting ... however I have no idea what that might imply. :-(
>
Those lines are responsible for the error messages. Namely,
in foam-l.lisp we have:
(defmacro file-imports (lst)
`(eval-when (load eval)
(when (fboundp 'process-import-entry)
(mapcar #'process-import-entry ,lst))
nil))
that is process-import-entry is called for each of those lines
(entries). But in daase.lisp we have:
(defun foam::process-import-entry (entry)
(let* ((asharpname (car entry))
(stringname (cadr entry))
(hcode (caddr entry))
(libname (cadddr entry))
(bootname (intern stringname 'boot)))
(declare (ignore libname))
(if (and (eq hcode 'foam-user::|initializer|) (not (boundp asharpname)))
(error (format nil "AxiomXL file ~s is missing!" stringname)))
....
so if the Aldor identifier in such entry is unbound (undefined) we
get the message.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Waldek Hebisch
Thanks for attached file, it looks like the file produced by Bill
Page.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Martin Rubey
http://axiom-wiki.newsynthesis.org/SandBoxSpecies
I have a working one that is an old wh-sandbox:
$ bin/AXIOMsys
GCL (GNU Common Lisp) 2.6.8 CLtL1 Mar 1 2007 16:42:04
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
AXIOM Computer Algebra System
Version: Axiom build-improvements branch 2006-11-26
Timestamp: Wednesday March 14, 2007 at 02:25:47
but I cannot tell exactly which version it is.
Copying the aldor subdirectory of that version into
fricas-buildrev101/target/i686-pc-linux, likewise libaxiom.al into
fricas-buildrev101/target/i686-pc-linux/algebra, I do *not* get something fully
functional - but mostly. Exactly this last command fails, below is the
backtrace.
In later versions, even
l: SetSpecies ACINT := set [i::ACINT for i in 1..4]
fails, but succeeds at second attempt... Very strange things indeed.
(19) -> [isomorphismTypes(m)$IsoT]$ACList(IsoT)
Error: Caught fatal error [memory may be damaged]
Error signalled by FUNCALL.
Broken at SYSTEM::BREAK-LEVEL. Type :H for Help.
BOOT>>:bt
#0 APPLY {loc0=#<compiled-function system:universal-error-handler>,loc1=:error,loc2=nil,l...} [ihs=54]
#1 APPLY {loc0=#<compiled-function system:universal-error-handler>,loc1=:error,loc2=nil,l...} [ihs=53]
#2 LAMBDA {} [ihs=50]
#3 C63-runtime-domainHash! {loc0=(|Interpret| ((1 # # ...)) (|ACInteger|)),loc1=#0=(#S(foam-user::|Struct-r...} [ihs=49]
#4 FUNCALL {loc0=#<compiled-function foam-user::|C63-runtime-domainHash!|>,loc1=(|Interpret...} [ihs=48]
#5 FUNCALL {loc0=#<compiled-function foam-user::|C63-runtime-domainHash!|>,loc1=(|Interpret...} [ihs=47]
#6 Computing args for + {#0=#S(foam-user::|Struct-runtime-51| foam-user::|rtAssertMessage-0| (#<compiled...} [ihs=44]
#7 Computing args for MOD {#0=#S(foam-user::|Struct-runtime-51| foam-user::|rtAssertMessage-0| (#<compiled...} [ihs=43]
#8 Computing args for FUNCALL {#0=#S(foam-user::|Struct-runtime-51| foam-user::|rtAssertMessage-0| (#<compiled...} [ihs=41]
#9 C15-csspecies-addLevel0 {#S(foam-user::|Struct-csspecies-14| foam-user::l-0 (#<vector 09876ab8> . #<vect...} [ihs=38]
#10 getDomainHash {dom=(#<vector 09876ab8> . #<vector 0a3353f0>),loc1=0,loc2=#<vector 0a3353f0>,lo...} [ihs=37]
#11 hashType {type=(#<vector 09876ab8> . #<vector 0a3353f0>),percenthash=0} [ihs=36]
#12 basicLookup {op=|isomorphismTypes|,sig=((|Generator| $) (|MultiSet| (|ACInteger|))),domain=(...} [ihs=35]
#13 compiledLookup {op=|isomorphismTypes|,sig=((|Generator| $) (|MultiSet| (|ACInteger|))),dollar=(...} [ihs=34]
#14 NRTcompiledLookup {op=|isomorphismTypes|,sig=((|Generator| $) (|MultiSet| (|ACInteger|))),dom=(#<v...} [ihs=33]
#15 NRTcompileEvalForm {opname=|isomorphismTypes|,sigtail=((|Generator| $) (|MultiSet| (|ACInteger|))),...} [ihs=32]
#16 evalForm {op=#<vector 0a335230>,opname=|isomorphismTypes|,argl=(#<vector 0a3350c4>),mms=(...} [ihs=31]
#17 bottomUpForm2 {t=(#<vector 0a335230> #<vector 0a3350c4>),op=#<vector 0a335230>,opname=|isomorp...} [ihs=30]
#18 bottomUpForm3 {t=(#<vector 0a335230> #<vector 0a3350c4>),op=#<vector 0a335230>,opname=|isomorp...} [ihs=29]
#19 bottomUpForm {t=(#<vector 0a335230> #<vector 0a3350c4>),op=#<vector 0a335230>,opname=|isomorp...} [ihs=28]
#20 bottomUp {t=(#<vector 0a335230> #<vector 0a3350c4>)} [ihs=27]
#21 upDollar {t=(#<vector 0a335310> |IsoT| (#<vector 0a335230> #<vector 0a3350c4>))} [ihs=26]
#22 bottomUp {t=(#<vector 0a335310> |IsoT| (#<vector 0a335230> #<vector 0a3350c4>)),loc1=|Dol...} [ihs=25]
#23 upDollarTuple {op=#<vector 0a335348>,f=|construct|,t=(|ACList| (|ACIsomorphismType| (|ACIntege...} [ihs=24]
#24 upDollar {t=(#<vector 0a335348> (|ACList| |IsoT|) (#<vector 0a33532c> (#<vector 0a335310>...} [ihs=23]
#25 bottomUp {t=(#<vector 0a335348> (|ACList| |IsoT|) (#<vector 0a33532c> (#<vector 0a335310>...} [ihs=22]
#26 interpret1 {x=((|$elt| (|ACList| |IsoT|) |construct|) ((|$elt| |IsoT| |isomorphismTypes|) |...} [ihs=21]
#27 interpret {g107613=(((|$elt| # |construct|) (# |m|)) (|Application| (|Fromdom| # #) (|Appl...} [ihs=20]
#28 interpretTopLevel {x=((|$elt| (|ACList| |IsoT|) |construct|) ((|$elt| |IsoT| |isomorphismTypes|) |...} [ihs=19]
#29 processInteractive1 {form=((|$elt| (|ACList| |IsoT|) |construct|) ((|$elt| |IsoT| |isomorphismTypes|...} [ihs=18]
#30 processInteractive {form=((|$elt| (|ACList| |IsoT|) |construct|) ((|$elt| |IsoT| |isomorphismTypes|...} [ihs=17]
#31 intInterpretPform {pf=(|Application| (|Fromdom| (# . []) (|Application| # #)) (|Application| (|Fro...} [ihs=16]
#32 ncConversationPhase {fn=#<compiled-function |phInterpret|>,args=(((|carrier| # # ...))),loc2=(|nonnu...} [ihs=15]
#33 intloopSpadProcess,interp {cc=((|carrier| (|ok?| . t) (|ptreePremacro| . #0=(|Application| # #)) ...)),ptr...} [ihs=14]
#34 intloopSpadProcess {stepno=1,lines=(((# . 1) . "[isomorphismTypes(m)$IsoT]$ACList(IsoT)")),ptree=(|...} [ihs=13]
#35 intloopProcess {n=1,interactive=t,s=(((#) (|Application| # #)) |nonnullstream| #<compiled-funct...} [ihs=12]
#36 intloopProcessString {s="[isomorphismTypes(m)$IsoT]$ACList(IsoT)",n=1} [ihs=11]
#37 intloopReadConsole {b="",n=1} [ihs=10]
#38 SpadInterpretStream {str=1,source=(tim daly ?),interactive?=t,loc3=nil,loc4=string-char,loc5=nil,loc...} [ihs=9]
#39 intloop {} [ihs=8]
#40 ncIntLoop {loc0=nil,loc1=nil,loc2=nil} [ihs=7]
#41 ncTopLevel {loc0=nil,loc1=0,loc2=#<synonym stream to *terminal-io*>,loc3=nil,loc4=".axiom.i...} [ihs=6]
#42 TOP-LEVEL {} [ihs=5]
#43 FUNCALL {loc0=#<compiled-function system:top-level>,loc1=nil,loc2=0,loc3=0,loc4=nil,loc5...} [ihs=4]
NIL
BOOT>>
I'm not sure how to go on from here. I think I could try to build the last
version of wh-sandbox + it's aldor interface using src_aldor2 (i.e., one of the
first versions), and see whether I can reproduce non-failing behaviour. But
that's a lot of work, I think.
Any other ideas?
Martin
Ralf Hemmecke
>
> (g-boolean "BOOLEAN" |initializer| "")
>
> in file-imports part of the generated Lisp file. Those lines
> are absent in the good version.
Hmm, the reason for that could be that I treat Boolean in a different
way than Peter. I have to look closer to that and make sure that the
right logic is behind it.
Unfortunately, I cannot say anything useful at the moment.
Ralf
Martin Rubey
> I would like to reproduce an axiom that does not fail the last command on
>
> http://axiom-wiki.newsynthesis.org/SandBoxSpecies
>
> I have a working one that is an old wh-sandbox:
I was now able (without work, actually), to reproduce good behaviour with
wh-sandbox rev. 646, which seems to be the last revision of wh-sandbox.
I'll now try early fricas revisions.
Martin
Martin Rubey
With fricas rev101 aldor-combinat doesn't even compile...
And indeed, MODULE.ao is missing from int/aldor/ao. I wonder why.
Compiling csaxcompat2.as ...
/users/rubey/aldor/linux/1.0.3/bin/aldor -Y /users/rubey/combinat/branches/iso-experiment-fricas/combinat/src -Y . -Y /users/rubey/aldor/linux/1.0.3/lib -I /users/rubey/combinat/branches/iso-experiment-fricas/combinat/include -I /users/rubey/aldor/linux/1.0.3/include -lcombinatax -dAxiom -q1 -Fasy -Flsp -laxiom -Mno-ALDOR_W_WillObsolete -Y /local/scratch/ax-buildrev101/target/i686-pc-linux//algebra -fao -dMacrosCombinat -Mno-mactext -M2 -Mno-abbrev csaxcompat2.as
#1 (Warning) Current file over-rides existing library in
`/users/rubey/combinat/branches/iso-experiment-fricas/combinat/src/libcombinatax.al'.
#2 (Fatal Error) Could not open file `MODULE.ao'.
make[5]: *** [libcombinatax.al(csaxcompat2.ao)] Fehler 1
make[5]: Verlasse Verzeichnis '/users/rubey/combinat/branches/iso-experiment-fricas/combinat/src'
make[4]: *** [LIBRARY.al] Fehler 2
make[4]: Verlasse Verzeichnis '/users/rubey/combinat/branches/iso-experiment-fricas/combinat/src'
make[3]: *** [libraryvariant.axiom] Fehler 2
make[3]: Verlasse Verzeichnis '/users/rubey/combinat/branches/iso-experiment-fricas/combinat/src'
make[2]: *** [all] Fehler 2
make[2]: Verlasse Verzeichnis '/users/rubey/combinat/branches/iso-experiment-fricas/combinat/src'
make[1]: *** [src.dir] Fehler 2
make[1]: Verlasse Verzeichnis '/users/rubey/combinat/branches/iso-experiment-fricas/combinat'
make: *** [alldefault] Fehler 2
rubey@aquin:~/combinat/branches/iso-experiment-fricas/combinat$
Martin Rubey
> > I was now able (without work, actually), to reproduce good behaviour with
> > wh-sandbox rev. 646, which seems to be the last revision of wh-sandbox.
> >
> > I'll now try early fricas revisions.
>
> With fricas rev101 aldor-combinat doesn't even compile...
>
> And indeed, MODULE.ao is missing from int/aldor/ao. I wonder why.
I just tried fricas rev 15, with a very similar result, this time DIVRING.ao is missing.
[...]
y/aldor/linux/1.0.3/include -lcombinatax -dAxiom -q1 -Fasy -Flsp -laxiom
-Mno-ALDOR_W_WillObsolete -Y
/local/scratch/ax-buildrev010/target/i686-pc-linux/algebra -fao
-dMacrosCombinat -Mno-mactext -M2 -Mno-abbrev csaxcompat2.as
#1 (Warning) Current file over-rides existing library in
`/users/rubey/combinat/branches/iso-experiment-fricas/combinat/src/libcombinatax.al'.
#2 (Fatal Error) Could not open file `DIVRING.ao'.
Unfortunately, I was unable to compile revision 10 of fricas, and the changeset
between last wh-sandbox and fricas 15 seems to be rather large. Well, I'll
have to double check, since I couldn't figure out how to ignore the .svn
directories. But still...
Waldek, do you happen to remember which fricas revision is the first one that
is supposed to compile?
I badly want to have this fixed...
Martin
Martin Rubey
> Unfortunately, I was unable to compile revision 10 of fricas, and the changeset
> between last wh-sandbox and fricas 15 seems to be rather large. Well, I'll
> have to double check, since I couldn't figure out how to ignore the .svn
> directories. But still...
>
> Waldek, do you happen to remember which fricas revision is the first one that
> is supposed to compile?
Just for the record: this is how fricas rev 10 make fails:
make[2]: Verlasse Verzeichnis '/local/scratch/ax-buildrev010/src/hyper'
30b running find-algebra-files
(cd ../../fricasrev010/src/algebra; \
. ../scripts/find-algebra-files) \
> algebra/tmp-extract-spad.mk
../../fricasrev010/src/../config/move-if-change \
algebra/tmp-extract-spad.mk algebra/extract-spad.mk
cd algebra && make
make[2]: Betrete Verzeichnis '/local/scratch/ax-buildrev010/src/algebra'
/usr/bin/install -c -m 644
../../../fricasrev010/src/algebra/acplot.spad.pamphlet
/local/scratch/ax-buildrev010/target/i686-pc-linux/src/alge
bra/acplot.spad.pamphlet
/usr/bin/install -c -m 644
../../../fricasrev010/src/algebra/aggcat2.spad.pamphlet
/local/scratch/ax-buildrev010/target/i686-pc-linux/src/alg
ebra/aggcat2.spad.pamphlet
/usr/bin/install -c -m 644
../../../fricasrev010/src/algebra/aggcat.spad.pamphlet
/local/scratch/ax-buildrev010/target/i686-pc-linux/src/alge
bra/aggcat.spad.pamphlet
/usr/bin/install -c -m 644
../../../fricasrev010/src/algebra/algcat.spad.pamphlet
/local/scratch/ax-buildrev010/target/i686-pc-linux/src/alge
bra/algcat.spad.pamphlet
/usr/bin/install -c -m 644
../../../fricasrev010/src/algebra/algext.spad.pamphlet
/local/scratch/ax-buildrev010/target/i686-pc-linux/src/alge
bra/algext.spad.pamphlet
/usr/bin/install -c -m 644
../../../fricasrev010/src/algebra/algfact.spad.pamphlet
/local/scratch/ax-buildrev010/target/i686-pc-linux/src/alg
ebra/algfact.spad.pamphlet
/usr/bin/install -c -m 644
../../../fricasrev010/src/algebra/algfunc.spad.pamphlet
/local/scratch/ax-buildrev010/target/i686-pc-linux/src/alg
ebra/algfunc.spad.pamphlet
/usr/bin/install -c -m 644
../../../fricasrev010/src/algebra/allfact.spad.pamphlet
/local/scratch/ax-buildrev010/target/i686-pc-linux/src/alg
ebra/allfact.spad.pamphlet
/usr/bin/install -c -m 644 ../../../fricasrev010/src/algebra/alql.spad.pamphlet
/local/scratch/ax-buildrev010/target/i686-pc-linux/src/algebr
a/alql.spad.pamphlet
make[2]: *** Keine Regel vorhanden, um das Target »/local/scratch/ax-buildrev010/target/i686-pc-linux/src/algebra/annacat.spad.pamphlet«,
benötigt von »stamp-spadsrc«, zu erstellen. Schluss.
make[2]: Verlasse Verzeichnis '/local/scratch/ax-buildrev010/src/algebra'
make[1]: *** [all-algebra] Fehler 2
make[1]: Verlasse Verzeichnis '/local/scratch/ax-buildrev010/src'
make: *** [all-src] Fehler 2
Martin Rubey
> Martin Rubey <martin...@univie.ac.at> writes:
>
> > > I was now able (without work, actually), to reproduce good behaviour with
> > > wh-sandbox rev. 646, which seems to be the last revision of wh-sandbox.
> > >
> > > I'll now try early fricas revisions.
> >
> > With fricas rev101 aldor-combinat doesn't even compile...
> >
> > And indeed, MODULE.ao is missing from int/aldor/ao. I wonder why.
>
> I just tried fricas rev 15, with a very similar result, this time DIVRING.ao
> is missing.
I meanwhile built fricas rev 11, and again DIVRING.ao is missing. Since rev 10
doesn't build, I guess that this is the first fricas revision that will build
on my system.
I wonder what the fundamental change between fricas rev 11 and the last
revision of wh-sandbox could be... I guess it's the databases?
I just noticed that using Ralf's new interface, MODULE.ao and DIVRING.ao are
also missing.
MODULE.ao is present in 11, 15 (missing in 101)
DIVRING.ao is present in 101 (missing in 11, 15)
Ralf, Waldek, any ideas? How is this list (i.e. the files in aldor/ao) put
together?
There is another difference between wh-sandbox and fricas 11:
COMPLEX.ao is also missing in 11
COMPCAT.ao and init_FRAC.ao are missing in wh-sandbox!
Martin
Ralf Hemmecke
> I just noticed that using Ralf's new interface, MODULE.ao and DIVRING.ao are
> also missing.
> MODULE.ao is present in 11, 15 (missing in 101)
> DIVRING.ao is present in 101 (missing in 11, 15)
> Ralf, Waldek, any ideas? How is this list (i.e. the files in aldor/ao) put
> together?
> There is another difference between wh-sandbox and fricas 11:
>
> COMPLEX.ao is also missing in 11
>
> COMPCAT.ao and init_FRAC.ao are missing in wh-sandbox!
I must say, I don't understand exactly what you are talking about. You
are handwaving. If you could send some commands that make your
observations easily reproducible by others that would be much more
helpful, for you and for me.
That .ao files are in any revision of fricas sounds strange to me. Maybe
I have seen libaxiom.al in Tim's Axiom repository, but I am too lazy to
check, since it should be generated anyway.
Hmmm, but now I somehow guess, I know what you are talking about.
As I have explained at the workshop, I collect the cliques in a
different way then Peter. The .ao files in libaxiom.al correspond to
cliques not to domains/categories. *All* cliques of size bigger than one
that my process is computing you see on page 7 of
http://axiom-wiki.newsynthesis.org/uploads/AldorFriCAS.pdf.
The name of the corresponding .ao file is always the lexicographically
smallest name in the clique. (Of course, for one-element cliques that
corresponds to the abbreviated name of the Axiom domain/category.)
Here is where I introduced this lexicographic ordering. That is not
important, but will help in the future to compare the generated files.
My memory tells me that Peter did not impose such a lexicographic order,
but just selected one name out of the clique.
So that is probably why you now find COMPCAT.ao but not COMPLEX.ao and
similar for others.
Look in src/aldor/ap/COMPAT.ap to find that the domain |Complex| is
defined there.
Does that help you?
Could you be more specific in your questions. I did not answer earlier,
because I was busy and had no time to guess what you were actually asking.
Ralf
Martin Rubey
IMPORTANT UPDATE: the error message complaining about missing MODULE.ao was
*my* fault! "make clean" does not remove src/libcombinatax.a*, and that caused
the problem.
I can now compile aldor-combinat at least with fricas rev. 11, and very very
likely also with the current version. I'll check this tomorrow. Also the test
(as on MathAction) passes now!
Martin
The rest below is just for the record
--OBSOLETE--------------------------------------------------------------------
I just looked into Ralf's new set of Makefiles and programs, to find out which
ao files are actually generated. Unfortunately, I did not understand.
It seems that for each clique, exactly one file is generated, namely the one
which happens to be first in the list. For example, from the clique
Clq(15-[ABELGRP,ALGEBRA,BMODULE,COMRING,ENTIRER,INTDOM,LMODULE,MODULE,RING,RMODULE,RNG,init_INT])
ABELGRP.ao is generated, the others seem to be ignored. Or am I mistaken here?
The point is of course the error message I get when trying to compile
aldor-combinat:
Compiling csaxcompat2.as ...
/users/rubey/aldor/linux/1.0.3/bin/aldor -Y /users/rubey/combinat/branches/iso-experiment-fricas/combinat/src -Y . -Y /users/rubey/aldor/linux/1.0.3/lib -I /users/rubey/combinat/branches/iso-experiment-fricas/combinat/include -I /users/rubey/aldor/linux/1.0.3/include -lcombinatax -dAxiom -q1 -Fasy -Flsp -laxiom -Mno-ALDOR_W_WillObsolete -Y /local/scratch/ax-buildrev101/target/i686-pc-linux//algebra -fao -dMacrosCombinat -Mno-mactext -M2 -Mno-abbrev csaxcompat2.as
#1 (Warning) Current file over-rides existing library in
`/users/rubey/combinat/branches/iso-experiment-fricas/combinat/src/libcombinatax.al'.
#2 (Fatal Error) Could not open file `MODULE.ao'.
Ralf Hemmecke
> IMPORTANT UPDATE: the error message complaining about missing MODULE.ao was
> *my* fault! "make clean" does not remove src/libcombinatax.a*, and that caused
> the problem.
Interesting that you think that FriCAS's "make clean" should remove
libcombinatax.a*. It doesn't know about the combinat files.
And if you actually meant "make clean" of aldor-combinat, then say so.
You are mathematician, so be precise!
AC's "make clean" does not remove the lib*.* files, because they cost
time to build them. Currently use "make distclean" to remove any file
that was generated after you unpacked an aldor-combinat distribution. It
will basically leave you with the files that are in the SVN repository.
> I can now compile aldor-combinat at least with fricas rev. 11, and very very
> likely also with the current version. I'll check this tomorrow. Also the test
> (as on MathAction) passes now!
Ooops, could you please, please tell me whether AC actually already runs
in FriCAS on your computer? I am currently looking at Peter's Makefile
and it seems there is some runtime stuff not yet compiled in
branches/aldor-interface.
> --OBSOLETE--------------------------------------------------------------------
>
> I just looked into Ralf's new set of Makefiles and programs, to find out which
> ao files are actually generated. Unfortunately, I did not understand.
>
> It seems that for each clique, exactly one file is generated, namely the one
> which happens to be first in the list. For example, from the clique
>
> Clq(15-[ABELGRP,ALGEBRA,BMODULE,COMRING,ENTIRER,INTDOM,LMODULE,MODULE,RING,RMODULE,RNG,init_INT])
>
> ABELGRP.ao is generated, the others seem to be ignored. Or am I mistaken here?
Yes, you are wrong. The exports of *all* the domains in the clique *are*
in the corresponding .ao file. Just look into src/aldor/ap/APELGRP.ap.
Ralf
Martin Rubey
> > IMPORTANT UPDATE: the error message complaining about missing MODULE.ao was
> > *my* fault! "make clean" does not remove src/libcombinatax.a*, and that
> > caused the problem.
>
> Interesting that you think that FriCAS's "make clean" should remove
> libcombinatax.a*. It doesn't know about the combinat files.
>
> And if you actually meant "make clean" of aldor-combinat, then say so. You
> are mathematician, so be precise!
I'm a mathematician, and I'm imprecise and chaotic. I know mathematicians of
all sorts... I meant make clean of aldor-combinat.
> AC's "make clean" does not remove the lib*.* files, because they cost time to
> build them. Currently use "make distclean" to remove any file that was
> generated after you unpacked an aldor-combinat distribution. It will
> basically leave you with the files that are in the SVN repository.
OK. I will probably never remember how Makefiles and their traditional targets
work. I'm afraid that you told me exactly this already once, sorry about that.
> > I can now compile aldor-combinat at least with fricas rev. 11, and very very
> > likely also with the current version. I'll check this tomorrow. Also the test
> > (as on MathAction) passes now!
>
> Ooops, could you please, please tell me whether AC actually already runs in
> FriCAS on your computer? I am currently looking at Peter's Makefile and it
> seems there is some runtime stuff not yet compiled in
> branches/aldor-interface.
Yes, it does (well, FriCAS rev. 11). But note that I was using the very old
aldor-interface (src_aldor2.tgz). Still, I think that this is very good,
because now I have something I can compare your new interface with.
> > --OBSOLETE--------------------------------------------------------------------
> > I just looked into Ralf's new set of Makefiles and programs, to find out which
> > ao files are actually generated. Unfortunately, I did not understand.
> > It seems that for each clique, exactly one file is generated, namely the one
> > which happens to be first in the list. For example, from the clique
> > Clq(15-[ABELGRP,ALGEBRA,BMODULE,COMRING,ENTIRER,INTDOM,LMODULE,MODULE,RING,RMODULE,RNG,init_INT])
> > ABELGRP.ao is generated, the others seem to be ignored. Or am I mistaken
> > here?
>
> Yes, you are wrong. The exports of *all* the domains in the clique *are* in the
> corresponding .ao file. Just look into src/aldor/ap/APELGRP.ap.
OK. Maybe it would make sense to add a note to the documentation (I'm not sure
where though), or rename the files so that it's apparent that the contain the
whole clique.
Maybe:
Index: libaxiom.tex
===================================================================
--- libaxiom.tex (revision 322)
+++ libaxiom.tex (working copy)
@@ -260,6 +260,10 @@
\item Call \file{cliques} on \file{libaxiom.lst} and all the
dependency files and thus compute \file{cliques.mk}.
+
+\item For each clique produce an \texttt{.ao} and then an \texttt{.ap} file.
+ For example, the file \file{ABELGRP.ap} could contain code for
+ \texttt{ABELGRP}, \texttt{ALGEBRA}, \texttt{BMODULE}, etc.
\end{enumerate}
Ralf Hemmecke
> where though), or rename the files so that it's apparent that the contain the
> whole clique.
> Maybe:
> Index: libaxiom.tex
> ===================================================================
> --- libaxiom.tex (revision 322)
> +++ libaxiom.tex (working copy)
> @@ -260,6 +260,10 @@
>
> \item Call \file{cliques} on \file{libaxiom.lst} and all the
> dependency files and thus compute \file{cliques.mk}.
> +
> +\item For each clique produce an \texttt{.ao} and then an \texttt{.ap} file.
> + For example, the file \file{ABELGRP.ap} could contain code for
> + \texttt{ABELGRP}, \texttt{ALGEBRA}, \texttt{BMODULE}, etc.
> \end{enumerate}
Yep. I have to rework the documentation anyway. And I will find a place
to put that kind of information.
Ralf
Ralf Hemmecke
> work. I'm afraid that you told me exactly this already once, sorry about that.
Don't remember, add this link to your bookmarks. ;-)
http://www.gnu.org/software/make/manual/make.html#Standard-Targets
It's a GNU convention, so everyone is free to follow or not to follow.
But sometimes it is easier if one at least approximates some kind of
standards. AC does not yet completely do so, but will if I've moved it
to Autoconf+Automake.
Ralf
Martin Rubey
> Dear Ralf and Peter,
>
> IMPORTANT UPDATE: the error message complaining about missing MODULE.ao was
> *my* fault! "make clean" does not remove src/libcombinatax.a*, and that caused
> the problem.
>
> I can now compile aldor-combinat at least with fricas rev. 11, and very very
> likely also with the current version. I'll check this tomorrow. Also the test
> (as on MathAction) passes now!
I can confirm that everything works OK even with current FriCAS.
(I had to hand-copy
attrib.o axextend.o axlit.o lang.o runtime.o
to /lib/fricas/target/$ARCH/aldor/lib, however. It seems that stub.o is not
needed, but I do not know.)
Ralf, how could I help now?
Martin
Ralf Hemmecke
>
> attrib.o axextend.o axlit.o lang.o runtime.o
>
> to /lib/fricas/target/$ARCH/aldor/lib, however. It seems that stub.o is not
> needed, but I do not know.)
>
> Ralf, how could I help now?
Give me some more time. ;-)
I've actually already figured out how to compile those files.
Below is the current version that should be added to
src/aldor/Makefile.in (don't forget to call 'config.status' in the top
build directory then).
After adding just call "make aldorofiles".
It was simply too late last night and I have not yet checked everything.
So I did not yet commit.
What is interesting, is that the stanzas below also generate and build
minimach.o and subsetc.o (which contains SubsetCategory), and boolean0.o
(containing just Boolean:with==add).
What I understood from Waldek, it really doesn't seem to be necessary to
include subsetc.o, because SubsetCategory is a SPAD builtin and should
be taken from there. And boolean0 just looks too thumb to be right.
I am not sure about minimach.o, though. it is also thumb, but why then
would lang.o be necessary?
Peter, do you know?
Ralf
-------------------------------------------------------
aldor_lsp_o_files := $(patsubst %,lib/%.o, runtime $(aldor_srcs))
$(aldor_lsp_o_files): lib/%.o: lsp/%.lsp
aldor_lsp_files := $(patsubst %,lsp/%.lsp, $(aldor_srcs))
lsp/runtime.lsp: runtime.ao lsp/.dir
ar x $(ALDORROOT)/lib/libfoam.al $<
$(ALDOR) -flsp=$@ $<
$(aldor_lsp_files): lsp/%.lsp: lsp/.dir al/libaxiom.al(%.ao)
ar x al/libaxiom.al $*.ao
$(ALDOR) -flsp=$@ $*.ao
rm $*.ao
foam_l=$(abs_top_builddir)/src/interp/foam_l.o
$(aldor_lsp_o_files): lib/%.o: lsp/%.lsp lib/.dir
echo '(progn (load "$(foam_l)") (compile-file "$(filter %.lsp,$^)"
:output-file "$@") (quit))' | ${DEPSYS} > tmp/o_$*.log
test -f $@
aldorofiles: $(aldor_lsp_o_files)
Martin Rubey
possibly you got my emails in the wrong order, or I currently do.
What I reported below is completely uninteresting now, since I misunderstood
which files are produced by the axiom-aldor interface. (I was not at all
talking about files in a repository, only about which files are produced by
src_aldor, given a build of some fricas revision.)
Meanwhile I understood that the names of the files in aldor/ao are not
essential... The only essential thing is to delete old versions of
libcombinatax*, as you told me.
Ralf Hemmecke <ra...@hemmecke.de> writes:
> The name of the corresponding .ao file is always the lexicographically
> smallest name in the clique. (Of course, for one-element cliques that
> corresponds to the abbreviated name of the Axiom domain/category.)
> Here is where I introduced this lexicographic ordering. That is not
> important, but will help in the future to compare the generated files.
> My memory tells me that Peter did not impose such a lexicographic order,
> but just selected one name out of the clique.
>
> So that is probably why you now find COMPCAT.ao but not COMPLEX.ao and
> similar for others.
>
> Look in src/aldor/ap/COMPAT.ap to find that the domain |Complex| is
> defined there.
>
> Does that help you?
Yes, that's what I understand now, and clarifying the order (i.e.,
lexicographic) seems like a wise decision to me.
All the best,
Martin
Ralf Hemmecke
>
> (I had to hand-copy
> attrib.o axextend.o axlit.o lang.o runtime.o
> to /lib/fricas/target/$ARCH/aldor/lib, however. It seems that stub.o is not
> needed, but I do not know.)
Martin, do you remember at which stage of the compilation process (of
aldor-combinat) these files are needed in
/lib/fricas/target/$ARCH/aldor/lib ?
Ralf
Martin Rubey
I believe they are not needed for compilation (at least, I didn't have them in
my path, I think), only for actually running it from within friCAS. However,
it might be that the corresponding lsp files (in linux/lib) from the aldor
distribution are taken instead for compilation.
I could try that, if you want to.
Martin
Ralf Hemmecke
>> /lib/fricas/target/$ARCH/aldor/lib ?
> I believe they are not needed for compilation (at least, I didn't
> have them in my path, I think),
Right. They are not needed for compiling .as files. libaxiom.al is
sufficient.
> only for actually running it from within friCAS.
That seems to be true. If I don't have them then FriCAS complains.
>> System error:
Cannot open the file
/home/hemmecke/software/lib/fricas/target/i686-pc-linux/aldor/lib/runtime.o.
> However, it might be that the corresponding lsp files (in linux/lib)
> from the aldor distribution are taken instead for compilation.
I have no idea. Perhaps libfoam.al is implicitly used.
There is foam_l.lsp, but you will see after my next commit (or if you
look at
http://groups.google.com/group/fricas-devel/browse_thread/thread/3ee15417dffa9ef7/c92a1bb5e6d8f6a4#c92a1bb5e6d8f6a4
) that there is ./src/interp/foam_l.lisp in the source directory and a
corresponding foam_l.o in the build directory which is used to compile
the runtime files. So, I guess, nothing is used from $ALDORROOT/lib.
> I could try that, if you want to.
Well, maybe you should svn-update your aldor-interface branch. I've just
committed a very important bugfix that (at least in my case) removes the
>> System error:
AxiomXL file "ARRAY1" is missing!
If you wait another few minutes (or hours), I'll try to also commit
those stanzas that move the aldor/lib/*.o files to the right place.
Ralf
Ralf Hemmecke
> Ralf Hemmecke wrote:
>> On 07/26/2008 08:04 PM, Martin Rubey wrote:
>>> - (mapcan '(lambda (x) (and (eq (car x) '|Export|) (list x))) ilist)))
>>> + (mapcan #'(lambda (x) (and (eq (car x) '|Export|) (list x))) ilist)))
>> Could someone explain me what and why there must be a # sign. Thanks.
>> It's really magic that something works at all with me knowing almost no
>> lisp at all. ;-)
> Think about types: '(lambda ...) is a list, mapcan expects a function.
> #' is just a shorthand to convert lambda list to a function. An
> expanded version would be:
>
> (function (lambda (x) (and (eq (car x) '|Export|) (list x))))
>
> and function above is just a convertion to function type.
Thank you. But it somehow breaks my understanding of the simplicity of
LISP. So there are other things than lists in LISP. Soso. How could I
have come that far without knowing all those details? ;-)
Ralf
Waldek Hebisch
>
> > (I had to hand-copy
> >
> > attrib.o axextend.o axlit.o lang.o runtime.o
> >
> > to /lib/fricas/target/$ARCH/aldor/lib, however. It seems that stub.o is not
> > needed, but I do not know.)
> >
> > Ralf, how could I help now?
>
> include subsetc.o, because SubsetCategory is a SPAD builtin and should
> be taken from there. And boolean0 just looks too thumb to be right.
> I am not sure about minimach.o, though. it is also thumb, but why then
> would lang.o be necessary?
>
I am not sure which of them are really necessary. But we in daase.lisp
we have (there is similar code in patches.lisp):
(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"))))
so runtime, lang, attrib, axlit, minimach and axextend are expected,
the other are not used.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Waldek Hebisch
>
> Martin Rubey <martin...@univie.ac.at> writes:
>
> > Unfortunately, I was unable to compile revision 10 of fricas, and the changeset
> > between last wh-sandbox and fricas 15 seems to be rather large. Well, I'll
> > have to double check, since I couldn't figure out how to ignore the .svn
> > directories. But still...
> >
> > Waldek, do you happen to remember which fricas revision is the first one that
> > is supposed to compile?
>
> Just for the record: this is how fricas rev 10 make fails:
> make[2]: *** Keine Regel vorhanden, um das Target ?/local/scratch/ax-buildrev010/target/i686-pc-linux/src/algebra/annacat.spad.pamphlet?,
> benötigt von ?stamp-spadsrc?, zu erstellen. Schluss.
> make[2]: Verlasse Verzeichnis '/local/scratch/ax-buildrev010/src/algebra'
> make[1]: *** [all-algebra] Fehler 2
> make[1]: Verlasse Verzeichnis '/local/scratch/ax-buildrev010/src'
> make: *** [all-src] Fehler 2
>
Revision 9 is the first which should bootstap (without graphic and
hyperdoc), 10 is the first one which should give complete system.
However, the main difference between wh-sandbox and early FriCAS is
removal of several files and changed algebra bootstrap -- the first
few revisions after revison 9 were mostly to fix resulting problems.
In particular the problem you see is because algebra Makefile.in
was not regenerated -- if you touch src/algebra/Makefile.pamphlet
the build should work (at least this particular problem should be
gone).
It seems that revision 16 is the first one with updated
src/algebra/Makefile.in in the repository.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
> we have (there is similar code in patches.lisp):
>
> (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"))))
>
> so runtime, lang, attrib, axlit, minimach and axextend are expected,
> the other are not used.
I've seen that in daase.lisp and patches.lisp and actually I would like
to know why it is there two times. Any idea?
Ralf
Waldek Hebisch
This code is called at different times. We could probably just call
it once -- I think NAG needed it the way it is in order to be
able to dump image containg Aldor files. Certainly we could
move it to a separate function an call it when needed.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Bill Page
On Fri, Aug 1, 2008 at 8:11 AM, Martin Rubey you wrote:
> ...
> I can confirm that everything works OK even with current FriCAS.
>
> (I had to hand-copy
>
> attrib.o axextend.o axlit.o lang.o runtime.o
>
> to /lib/fricas/target/$ARCH/aldor/lib, however. It seems that stub.o is not
> needed, but I do not know.)
>
While trying to compile the first Aldor file
#includeDir "/var/lib/zope/combinat/include"
#libraryDir "/var/lib/zope/combinat/lib"
#include "combinat"
macro {
E == EmptySetSpecies;
X == SingletonSpecies;
+ == Plus;
* == Times;
}
A(L: LabelType): CombinatorialSpecies L == (E + X*A*A)(L) add;
---
See page:
http://axiom-wiki.newsynthesis.org/SandBoxSpecies
Using my newly built Aldor interface and an up to date version of FriCAS
I get the following error:
Compiling FriCAS source code from file
/var/zope2/var/LatexWiki/5200085684951427974-25px003.as using
AXIOM-XL compiler and options
-O -Fasy -Fao -Flsp -laxiom -Mno-ALDOR_W_WillObsolete -DAxiom -Y
$AXIOM/algebra -I $AXIOM/algebra
Use the system command )set compiler args to change these
options.
#1 (Fatal Error) Could not open file `stub.ao'.
The )library system command was not called after compilation.
---
Are you sure that "stub.ao" is not needed? I find only the source file
in my build directory.
root@sage:~/fricas-aldor# find . -name 'stub.*'
./fricas-build/src/aldor/stub.as
Regards,
Bill Page.
Ralf Hemmecke
>
> I get the following error:
>
> Compiling FriCAS source code from file
> /var/zope2/var/LatexWiki/5200085684951427974-25px003.as using
> AXIOM-XL compiler and options
> -O -Fasy -Fao -Flsp -laxiom -Mno-ALDOR_W_WillObsolete -DAxiom -Y
> $AXIOM/algebra -I $AXIOM/algebra
> Use the system command )set compiler args to change these
> options.
> #1 (Fatal Error) Could not open file `stub.ao'.
> The )library system command was not called after compilation.
>
> ---
>
> Are you sure that "stub.ao" is not needed? I find only the source file
> in my build directory.
I am (nearly) 100% sure. FriCAS itself does not contain any reference to
stub.ao. And in libaxiom.al you won't find stub.ao. At least not in the
libaxiom.al that you compiled with the aldor-interface branch.
To me it rather seems that your system refers to an old libaxiom.al. (I
faintly remember that the original AXIOM had such a file. Perhaps you
should also look under $ALDORROOT/lib whether there is some leftover.
Note that in FriCAS $AXIOM refers to the FriCAS installation directory
something like
$exec_prefix/lib/fricas/target/$target
Ralf
Bill Page
On Thu, Aug 7, 2008 at 2:46 AM, you wrote:
> Bill Page wrote:
>> Using my newly built Aldor interface and an up to date version of FriCAS
>>
>> I get the following error:
>>
>> Compiling FriCAS source code from file
>> /var/zope2/var/LatexWiki/5200085684951427974-25px003.as using
>> AXIOM-XL compiler and options
>> -O -Fasy -Fao -Flsp -laxiom -Mno-ALDOR_W_WillObsolete -DAxiom -Y
>> $AXIOM/algebra -I $AXIOM/algebra
>> Use the system command )set compiler args to change these
>> options.
>> #1 (Fatal Error) Could not open file `stub.ao'.
>> The )library system command was not called after compilation.
>>
>> ---
>>
>> Are you sure that "stub.ao" is not needed? I find only the source file
>> in my build directory.
>
> I am (nearly) 100% sure. FriCAS itself does not contain any reference
> to stub.ao. And in libaxiom.al you won't find stub.ao. At least not in
> the libaxiom.al that you compiled with the aldor-interface branch.
> To me it rather seems that your system refers to an old libaxiom.al.
> (I faintly remember that the original AXIOM had such a file. Perhaps
> you should also look under $ALDORROOT/lib whether there is some
> leftover.
>
In fact I do have three libaxiom.al files:
root@sage:/usr/local# find . -name libaxiom.al -exec ls -l {} \;
-rw-r--r-- 1 root root 27650030 Aug 6 20:00
./lib/fricas/target/x86_64-unknown-linux/algebra/libaxiom.al
-rw-r--r-- 1 root root 9112868 Nov 10 2007
./lib/axiom/target/x86_64-unknown-linux/algebra/libaxiom.al
-rw-rw-r-- 1 root root 9776376 Jun 21 2006
./axiom/mnt/linux/algebra/libaxiom.al
./axiom/mnt/linux/algebra/libaxiom.al is from the original binary
distribution of Axiom with Aldor with the old binary distribution of
Aldor (1.0.3, I think).
./lib/axiom/target/x86_64-unknown-linux/algebra/libaxiom.al was built
using FriCAS from November last year and Peter's src2 Aldor interface
with the new Aldor compiler built from source (1.1.0)
./lib/fricas/target/... is the new library built from FriCAS HEAD
(plus patch to daase.lisp) with your new Aldor interface and new Aldor
compiler built from source.
It is interesting to notice how much larger this 'libaxiom.al' file is
than the other two. Do you know why? How does it compare to the size
of libaxiom.al on your 64 bit system? Later today I will try a
complete new rebuild of FriCAS and the Aldor interface and check if
this changes.
When FriCAS runs the AXIOM variable is set to one of:
/usr/local/lib/axiom/target/x86_64-unknown-linux
/usr/local/lib/fricas/target/x86_64-unknown-linux
ALDORROOT is set to:
root@sage:/# echo $ALDORROOT
/usr/local/aldor/linux/1.1.0
Here is the contents of $ALDORROOT/lib
root@sage:/usr/local# ls $ALDORROOT/lib
aldor_gloop.ao axextend.lsp libaldor.al libalgebrad.al libfoamlib.a
aldor_gloop.o axlit.asy libaldord.a libax0.al libfoamlib.al
aldor_gloopd.ao axlit.lsp libaldord.al libaxllib.a libgmp.a
aldor_gloopd.o comsgdb.msg libalgebra-gmp.a libaxllib.al minimach.asy
attrib.asy comsgpig.cat libalgebra-gmp.al libfoam-car.a minimach.lsp
attrib.lsp foam_l.lsp libalgebra.a libfoam-gmp.a runtime.lsp
axext_l.lsp lang.lsp libalgebra.al libfoam.a
axextend.asy libaldor.a libalgebrad.a libfoam.al
libaxiom.al is not present here.
> Note that in FriCAS $AXIOM refers to the FriCAS installation directory
> something like
>
> $exec_prefix/lib/fricas/target/$target
>
The error noted above occurs when linking to the aldor-combinat libraries:
#includeDir "/var/lib/zope/combinat/include"
#libraryDir "/var/lib/zope/combinat/lib"
#include "combinat"
These were separately compiled (outside FriCAS) from the
iso-experiment branch using the same Aldor compiler (1.1.0 from
source). This code works with the older
./lib/axiom/target/x86_64-unknown-linux version of FriCAS (except for
one error noted by Martin) but not with the new one.
The new build of FriCAS with the new Aldor interface seems to work
fine on other Aldor examples on the axiom-wiki.
---------
I find 'stub.*' in the following locations:
root@sage:/usr/local# find . -name 'stub.*' -exec ls -l {} \;
-rw-r--r-- 1 root root 27937 Nov 10 2007
./lib/axiom/target/x86_64-unknown-linux/aldor/lib/stub.data
-rw-r--r-- 1 root root 39829 Nov 10 2007
./lib/axiom/target/x86_64-unknown-linux/aldor/lib/stub.lsp
-rw-r--r-- 1 root root 30092 Nov 10 2007
./lib/axiom/target/x86_64-unknown-linux/aldor/lib/stub.fn
-rw-r--r-- 1 root root 107065 Nov 10 2007
./lib/axiom/target/x86_64-unknown-linux/aldor/lib/stub.o
-rw-rw-r-- 1 root root 39829 Jun 21 2006 ./axiom/mnt/linux/aldor/lib/stub.lsp
-rw-rw-r-- 1 root root 30092 Jun 21 2006 ./axiom/mnt/linux/aldor/lib/stub.fn
-rw-rw-r-- 1 root root 48334 Jun 21 2006 ./axiom/mnt/linux/aldor/lib/stub.o
Notice that it is not found in /lib/fricas/target/x86_64-unknown-linux
---------
Any more ideas would be greatly appreciated!
Regards,
Bill Page.
Ralf Hemmecke
> In fact I do have three libaxiom.al files:
> root@sage:/usr/local# find . -name libaxiom.al -exec ls -l {} \;
> -rw-r--r-- 1 root root 27650030 Aug 6 20:00
> ./lib/fricas/target/x86_64-unknown-linux/algebra/libaxiom.al
> -rw-r--r-- 1 root root 9112868 Nov 10 2007
> ./lib/axiom/target/x86_64-unknown-linux/algebra/libaxiom.al
> -rw-rw-r-- 1 root root 9776376 Jun 21 2006
> ./axiom/mnt/linux/algebra/libaxiom.al
> ./axiom/mnt/linux/algebra/libaxiom.al is from the original binary
> distribution of Axiom with Aldor with the old binary distribution of
> Aldor (1.0.3, I think).
Maybe ./axiom/mnt/linux/algebra/libaxiom.al still works for AXIOM.
Otherwise I don't see a point in keeping it on your system. It's in
Tim's source repository anyway.
> ./lib/fricas/target/... is the new library built from FriCAS HEAD
> (plus patch to daase.lisp) with your new Aldor interface and new Aldor
> compiler built from source.
> It is interesting to notice how much larger this 'libaxiom.al' file is
> than the other two. Do you know why? How does it compare to the size
> of libaxiom.al on your 64 bit system?
It is even that big on my 32bit Laptop. But bitsize should not matter,
because it should be machine independent.
The only thing that comes to my mind is that it might matter whether the
.ao files are compiled with the intermediate libaxiom_AAA.al libraries.
But I really really don't know. Maybe I should recompile with the
current aldor-interface branch without the short-cut of not using
intermediate libraries. It would be very strange if that gives an
explanation to the size of libaxiom.al. But I don't know what the aldor
compiler is actually storing inside the .ao file.
> Later today I will try a complete new rebuild of FriCAS and the Aldor
> interface and check if this changes.
> When FriCAS runs the AXIOM variable is set to one of:
> /usr/local/lib/axiom/target/x86_64-unknown-linux
> /usr/local/lib/fricas/target/x86_64-unknown-linux
Hmmm, I think you should make sure that the version with axiom in its
path is *not* used. srcaldor2 and my build process use a slightly
different compilation of files. It would surprise me if they can be used
interchangeably.
> The error noted above occurs when linking to the aldor-combinat libraries:
>
> #includeDir "/var/lib/zope/combinat/include"
> #libraryDir "/var/lib/zope/combinat/lib"
> #include "combinat"
> These were separately compiled (outside FriCAS) from the
> iso-experiment branch using the same Aldor compiler (1.1.0 from
> source). This code works with the older
> ./lib/axiom/target/x86_64-unknown-linux version of FriCAS (except for
> one error noted by Martin) but not with the new one.
Ah. If you run 'make' for aldor-combinat then libaxiom.al is used. So it
should certainly be the one that comes from aldor-interface, i.e.
./lib/fricas/target/x86_64-unknown-linux/algebra/libaxiom.al
You should certainly recompile AC. And before you do it look into
Makefile.def.nw. It looks like
VARIANTPOSTFIXaxiom=ax
VARIANTASSERTIONaxiom=-dAxiom
VARIANTFLAGSaxiom=-q1 -Fasy -Flsp -laxiom -Mno-ALDOR_W_WillObsolete -Y
$(AXIOM)/algebra
but should certainly be like what aldor-interface now has as options. So
change to
VARIANTFLAGSaxiom=-q1 -Fasy -Flsp -laxiom -Mno-ALDOR_W_WillObsolete -Y
$(AXIOM)/algebra -I $(AXIOM)/algebra
and make sure that the AXIOM variable is set properly before you call
'make'.
As far as I see it and as far as I remember, the AC Makefiles do not set
AXIOM themselves but rather rely on an existing value at build time so
you should say
make AXIOM=/usr/local/lib/fricas/target/x86_64-unknown-linux
Does that help?
> The new build of FriCAS with the new Aldor interface seems to work
> fine on other Aldor examples on the axiom-wiki.
> I find 'stub.*' in the following locations:
>
> root@sage:/usr/local# find . -name 'stub.*' -exec ls -l {} \;
> -rw-r--r-- 1 root root 27937 Nov 10 2007
> ./lib/axiom/target/x86_64-unknown-linux/aldor/lib/stub.data
> -rw-r--r-- 1 root root 39829 Nov 10 2007
> ./lib/axiom/target/x86_64-unknown-linux/aldor/lib/stub.lsp
> -rw-r--r-- 1 root root 30092 Nov 10 2007
> ./lib/axiom/target/x86_64-unknown-linux/aldor/lib/stub.fn
> -rw-r--r-- 1 root root 107065 Nov 10 2007
> ./lib/axiom/target/x86_64-unknown-linux/aldor/lib/stub.o
> -rw-rw-r-- 1 root root 39829 Jun 21 2006 ./axiom/mnt/linux/aldor/lib/stub.lsp
> -rw-rw-r-- 1 root root 30092 Jun 21 2006 ./axiom/mnt/linux/aldor/lib/stub.fn
> -rw-rw-r-- 1 root root 48334 Jun 21 2006 ./axiom/mnt/linux/aldor/lib/stub.o
>
> Notice that it is not found in /lib/fricas/target/x86_64-unknown-linux
Try "ar t libaxiom.al |grep stub" on your files then you might find out
where the stub.ao comes from. (Certainly the one that was used in the
build of aldor-combinat.)
Hopefully you can go on now.
Ralf
Bill Page
On Thu, Aug 7, 2008 at 10:40 AM, you wrote:
> Bill Page wrote:
Done. Thanks.
> and make sure that the AXIOM variable is set properly before you call
> 'make'.
>
Done.
> As far as I see it and as far as I remember, the AC Makefiles do not set
> AXIOM themselves but rather rely on an existing value at build time so
> you should say
>
> make AXIOM=/usr/local/lib/fricas/target/x86_64-unknown-linux
>
> Does that help?
>
Yes, thanks. I does help a lot.
I used the commands:
cd ~/iso-experiment/combinat
make clean
make VARIANTSTOBUILD=axiom
AXIOM=/usr/local/lib/fricas/target/x86_64-unknown-linux
But this compilation fails with the same message as I see when compile
inside FriCAS:
Could not open file `stub.ao'
I see "-Y /usr/local/lib/fricas/target/x86_64-unknown-linux/algebra -I
/usr/local/lib/fricas/target/x86_64-unknown-linux/algebra" in the
following log output so I think it most be looking in the right place.
No?
...
Compiling csaxcompat.as ...
/usr/local/aldor/linux/1.1.0/bin/aldor -Y
/home/page/iso-experiment/combinat/src -Y . -Y
/usr/local/aldor/linux/1.1.0/lib -I
/home/page/iso-experiment/combinat/include -I
/usr/local/aldor/linux/1.1.0/include -lcombinatax
-dAxiom -q1 -Fasy -Flsp -laxiom
-Mno-ALDOR_W_WillObsolete -Y
/usr/local/lib/fricas/target/x86_64-unknown-linux/algebra -I
/usr/local/lib/fricas/target/x86_64-unknown-linux/algebra -fao
-dMacrosCombinat -Mno-mactext -M2 -Mno-abbrev csaxcompat.as
ar rv libcombinatax.al csaxcompat.ao
r - csaxcompat.ao
rm -f csaxcompat.ao
Compiling csaxcompat2.as ...
/usr/local/aldor/linux/1.1.0/bin/aldor -Y
/home/page/iso-experiment/combinat/src -Y . -Y
/usr/local/aldor/linux/1.1.0/lib -I
/home/page/iso-experiment/combinat/include -I
/usr/local/aldor/linux/1.1.0/include -lcombinatax
-dAxiom -q1 -Fasy -Flsp -laxiom
-Mno-ALDOR_W_WillObsolete -Y
/usr/local/lib/fricas/target/x86_64-unknown-linux/algebra -I
/usr/local/lib/fricas/target/x86_64-unknown-linux/algebra -fao
-dMacrosCombinat -Mno-mactext -M2 -Mno-abbrev csaxcompat2.as
#1 (Warning) Current file over-rides existing library in
`/home/page/iso-experiment/combinat/src/libcombinatax.al'.
#2 (Fatal Error) Could not open file `stub.ao'.
make[5]: *** [libcombinatax.al(csaxcompat2.ao)] Error 1
make[5]: Leaving directory `/home/page/iso-experiment/combinat/src'
make[4]: *** [LIBRARY.al] Error 2
make[4]: Leaving directory `/home/page/iso-experiment/combinat/src'
make[3]: *** [libraryvariant.axiom] Error 2
make[3]: Leaving directory `/home/page/iso-experiment/combinat/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/page/iso-experiment/combinat/src'
make[1]: *** [src.dir] Error 2
make[1]: Leaving directory `/home/page/iso-experiment/combinat'
make: *** [alldefault] Error 2
root@sage:~/iso-experiment/combinat#
----------
Regards,
Bill Page.
Martin Rubey
"Bill Page" <bill...@newsynthesis.org> writes:
> I used the commands:
>
> cd ~/iso-experiment/combinat
> make clean
just a random shot: try
make distclean.
Martin
Bill Page
On Thu, Aug 7, 2008 at 1:18 PM, you wrote:
> Bill Page writes:
>
>> I used the commands:
>>
>> cd ~/iso-experiment/combinat
>> make clean
>
> just a random shot: try
>
> make distclean.
>
Has anyone ever said: You are an excellent Freischütz (shootist)!
That does solve the problem. Thanks.
Now I seem to have an up to date operational version of FriCAS with
the new Aldor interface.
And as you can see from
http://axiom-wiki.newsynthesis.org/SandBoxSpecies
this does solve the problem with
[isomorphismTypes(m)$IsoT]$ACList(IsoT)
Great. :-)
Regards,
Bill Page.
Ralf Hemmecke
>
> cd ~/iso-experiment/combinat
> make clean
> make VARIANTSTOBUILD=axiom
> AXIOM=/usr/local/lib/fricas/target/x86_64-unknown-linux
>
> But this compilation fails with the same message as I see when compile
> inside FriCAS:
>
> Could not open file `stub.ao'
Should be fine. Have you issued "make distclean" before?
Otherwise the old libcombinatax.al is just updated. Simply remove all
libcombinatax.al libraries you see.
Ralf
Ralf Hemmecke
>> make clean
>
> just a random shot: try
>
> make distclean.
I think that is a good guess. ;-)
'make clean' does not remove lib*.al.
Ralf