Building the Aldor interface on FriCAS or OpenAxiom

23 views
Skip to first unread message

Bill Page

unread,
Nov 8, 2007, 4:48:04 AM11/8/07
to fricas...@googlegroups.com, Martin Rubey, open-axi...@lists.sourceforge.net
Martin,

Have you been able to compile the Axiom/Aldor interface for a recent
version of FriCAS or OpenAxiom? As you know the instructions here:

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

are rather out of date and the referenced emails from Franz and Gaby
have only brief notes on a recipe that apparently worked on an earlier
version. I have been trying unsuccessfully to complete a build with
FriCAS and the new version of Aldor but I am running into many
problems. I would really like to provide the Aldor interface at the
new web site with a more recent version/fork of Axiom.

If anyone has any advice, I would greatly appreciate it.

Regards,
Bill Page.

Martin Rubey

unread,
Nov 8, 2007, 8:48:12 AM11/8/07
to Bill Page, fricas...@googlegroups.com, open-axi...@lists.sourceforge.net
"Bill Page" <bill...@newsynthesis.org> writes:

> Martin,
>
> Have you been able to compile the Axiom/Aldor interface for a recent
> version of FriCAS or OpenAxiom? As you know the instructions here:

No, so far I have only a build with the very last wh-sandbox. I will try it as
soon as I can. But really, it's Peter who is the boss of the axiom-aldor
interaction.

> http://axiom-wiki.newsynthesis.org/AldorForAxiom
>
> are rather out of date and the referenced emails from Franz and Gaby have
> only brief notes on a recipe that apparently worked on an earlier version. I
> have been trying unsuccessfully to complete a build with FriCAS and the new
> version of Aldor but I am running into many problems. I would really like to
> provide the Aldor interface at the new web site with a more recent
> version/fork of Axiom.

Yes. In fact, I wish that the aldor interface would be automatically built
when axiom is built.

Maybe you could just state what's the first problem you run into?

Martin

Ralf Hemmecke

unread,
Nov 8, 2007, 9:30:32 AM11/8/07
to Bill Page, fricas...@googlegroups.com, open-axi...@lists.sourceforge.net, Peter Broadbery
Peter,

how far are you with replacing JAVA by Aldor for this process?
Could we help? Do you have some repository set up for these scripts?

Ralf

Bill Page

unread,
Nov 8, 2007, 10:14:21 AM11/8/07
to Martin Rubey, fricas...@googlegroups.com, open-axi...@lists.sourceforge.net, Peter Broadbery
On 08 Nov 2007 14:48:12 +0100, Martin Rubey wrote:

> "Bill Page" writes:
> > Have you been able to compile the Axiom/Aldor interface for a recent
> > version of FriCAS or OpenAxiom? As you know the instructions here:
>
> No, so far I have only a build with the very last wh-sandbox. I will try it as
> soon as I can. But really, it's Peter who is the boss of the axiom-aldor
> interaction.
>

Indeed! :-)

> > http://axiom-wiki.newsynthesis.org/AldorForAxiom
> >
> > are rather out of date and the referenced emails from Franz and Gaby
> > have only brief notes on a recipe that apparently worked on an earlier
> > version. I have been trying unsuccessfully to complete a build with
> > FriCAS and the new version of Aldor but I am running into many
> > problems. I would really like to provide the Aldor interface at the new
> > web site with a more recent version/fork of Axiom.
>
> Yes. In fact, I wish that the aldor interface would be automatically built
> when axiom is built.
>

You mean the FriCAs/OpenAxiom build should check for an existing
installation of Aldor and just do the right thing to install the
interface, right? Of course licensing issues preclude actually
distributing Aldor with Axiom (unless we were to adopt APL2 for some
variant of Axiom), but this does not prevent doing what you suggest.

> Maybe you could just state what's the first problem you run into?
>

The first problem is that the scripts in src_aldor2.tgz assume the
existence of intermediate directories named ./obj/xxx/bin and
./int/algebra/... On FriCAS (and OpenAxiom?) this has been replaced
with directory names ./build/xxx/bin and ./src/algebra/...
respectively (xxx is the host identifier. The email notes suggest
building these missing directories and adding appropriate symbolic
links. Both FriCAS and OpenAxiom builds are designed to work
"out-of-source" but the src_aldor2 build does not work this way (yet).

Of course the right way to do this would be to modify the scripts. My
first attempt started this way. I got this to "almost" work by a
series of incremental changes but I found that assumptions about the
build environment were embedded rather deeply in the code - including
one place in a lisp file. The build proceeded quite far into the
process, including running the java code to sort the dependencies, but
obviously I missed at least one more place somewhere since I got to a
point where the pathnames were clearly incorrect.

So then started again, this time using the approach suggested in the
emails - adding the missing directories and symbolic links. Oddly
perhaps, I actually ended up with essential the same result and at
nearly the same point in the build. So I decided to ask if anyone else
had tried and succeeded yet.

Here is the current output of the make script:

-------

root@sage:~/fricas-test/src/aldor# echo $AXIOM
/home/page/fricas-test/target/x86_64-unknown-linux

root@sage:~/fricas-test/src/aldor# echo $ALDORROOT
/home/page/aldor-src/aldor/install/aldor/linux/1.1.0

root@sage:~/fricas-test/src/aldor# make
/bin/sh: line 0: cd:
/home/page/fricas-test/target/x86_64-unknown-linux/../../int: No such
file or directory
Building libaxiom.al and associated files
/home/page/fricas-test/src/aldor/aldor
/bin/sh: line 0: cd:
/home/page/fricas-test/target/x86_64-unknown-linux/../../int: No such
file or directory
make[1]: Entering directory `/home/page/fricas-test/src/aldor'
/home/page/fricas-test/src/aldor/libaxiom.mk:37: AXO_AP_FILES:
/home/page/fricas-test/src/aldor
/home/page/fricas-test/src/aldor/libaxiom.mk:44: AXO_GEN_AP_FILES:
/home/page/fricas-test/src/aldor/aldor
/home/page/fricas-test/src/aldor/types.mk:156:
/home/page/fricas-test/src/aldor/aldor/saxiom/spadset.mk
/home/page/fricas-test/src/aldor/Make.rules:179: ALL SPADSETS sax0 saxiom
/home/page/fricas-test/src/aldor/Make.rules:200: (0,0)
/home/page/fricas-test/src/aldor/Make.rules:204:
/home/page/fricas-test/src/aldor/aldor/sax0/spadset.mk: No such file
or directory
/home/page/fricas-test/src/aldor/Make.rules:200: (1,1)
/home/page/fricas-test/src/aldor/Make.rules:204:
/home/page/fricas-test/src/aldor/aldor/saxiom/spadset.mk: No such file
or directory
/home/page/fricas-test/src/aldor/Make.rules:106: W: 1 I: 1
/home/page/fricas-test/src/aldor/Make.rules:107: W:
/home/page/fricas-test/src/aldor/aldor/sax0/spadset.mk
ls: /home/page/fricas-test/src/aldor/aldor/../algebra/*.spad: No such
file or directory
/home/page/fricas-test/src/aldor/aldor/typelist unchanged
make[1]: *** No rule to make target
`/home/page/fricas-test/src/aldor/as//home/page/fricas-test/src/aldor/aldor/ap/axlit.as',
needed by `/home/page/fricas-test/src/aldor/aldor/ap/axlit.ap'. Stop.
make[1]: Leaving directory `/home/page/fricas-test/src/aldor'
make: *** [all] Error 2
root@sage:~/fricas-test/src/aldor#

---------

Notice this incorrect path:

/home/page/fricas-test/src/aldor/as//home/page/fricas-test/src/aldor/aldor/ap/axlit.as

As I said, I get this result in both my attempts.

I think what I would like to do is return to the first approach, i.e.
"do it right" so that this can eventually be included in the standard
make files of FriCAS and OpenAxiom. It will be later today before I
can get back to this.

Any help greatly appreciated.

Regards,
Bill Page.

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

unread,
Nov 8, 2007, 2:27:16 PM11/8/07
to fricas...@googlegroups.com
Hello,

> are rather out of date and the referenced emails from Franz and Gaby
> have only brief notes on a recipe that apparently worked on an earlier
> version. I have been trying unsuccessfully to complete a build with
> FriCAS and the new version of Aldor but I am running into many
> problems.

I tried the 1.1.0rc binary from www.aldor.org recently on fricas rev 88
(amd64) and it failed at the point where $ALDORROOT/lib/runtime.lsp
is required in the Makefile of the aldor-for-axiom package.
This file is absent in aldor 1.1.0, but present in aldor 1.0.2.
Therefore I stepped back to the 1.0.2 binary which fortunately still lives
on my hard disk.

A new problem appeared recently which was described earlier in
http://www.mail-archive.com/axiom-d...@nongnu.org/msg04622.html
and after doing what this message indicates the build succeeded.

> If anyone has any advice, I would greatly appreciate it.

Since now both aldor and fricas became moving targets,
the right way is of course to understand and modify the aldor-for-axiom
Makefile, however this exceeds my capabilities and I don't have the time
to dig into it.
Anyways, below is what worked for me for fricas rev 88 and aldor 1.0.2.

regards,
Franz

#
#Aldor
#
#(PWD is ax-build)

ARCH=x86_64-unknown-linux
export AXIOM=$PWD/target/$ARCH
export ALDORROOT=/usr/local/aldor/linux/1.0.2

(cd $AXIOM/bin; ln -s ../../../build/scripts/document .)
mkdir -p obj/$ARCH
(cd obj/$ARCH ; ln -s ../../build/$ARCH/bin .)
(cd obj/$ARCH ; ln -s ../../src/interp/ .)

cd src
#for axiom.sty
ln -s ../../fricas-88/src/scripts/ .

tar xzf ../../src_aldor2.tgz
cd aldor
ln -s ../../build/$ARCH .

for pp in *.pamphlet; do ../../build/scripts/document $pp;done

(cd ../..; mkdir -p int/algebra;cd int/algebra; lndir ../../src/algebra/)

make

#http://www.mail-archive.com/axiom-d...@nongnu.org/msg04622.html
#says
# I have successfully built Axiom --patch-49 on my machine. And in the
# process of building the Aldor interface (I followed the procedure
# described in http://wiki.axiom-developer.org/AldorForAxiomissue) i
# encountered the following undocumented issue:
#
# the build process stopped with this message:
#
# cp /usr/local/axiom/src/aldor/as/attrib.as.head #
/usr/local/axiom/int/aldor/as/attrib.as
# Please add new attributes to /attrib.as.head
# make[1]: *** [/usr/local/axiom/int/aldor/as/attrib.as] Erreur 1
# make[1]: *** Destruction du fichier
# « /usr/local/axiom/int/aldor/as/attrib.as »
# make[1]: quittant le répertoire « /usr/local/axiom/src/aldor »
#
# It seems that the build process stops to allow user to modify
# attrib.as.head that contains attributes defined in the axiom library
# (for example shallowMutable). Indeed the libaxiom.mk contains a
"@false"
# line 70. So I modified libaxiom.mk and commented out this "@false" and
# the build completes without any problem. I successfully tested Aldor in
# axiom with the sample provided. So my questions are: is it a known
# issue ?

#after commenting out @false in libaxiom.mk the build indeed completes
# and apparently the compiler works correctly.

Bill Page

unread,
Nov 8, 2007, 4:39:45 PM11/8/07
to fricas...@googlegroups.com
On 11/8/07, Franz wrote:

>
> Bill Page wrote:
> > are rather out of date and the referenced emails from Franz and Gaby
> > have only brief notes on a recipe that apparently worked on an earlier
> > version. I have been trying unsuccessfully to complete a build with
> > FriCAS and the new version of Aldor but I am running into many
> > problems.
>
> I tried the 1.1.0rc binary from www.aldor.org recently on fricas
> rev 88 (amd64) and it failed at the point where
> $ALDORROOT/lib/runtime.lsp is required in the Makefile of the
> aldor-for-axiom package. This file is absent in aldor 1.1.0, but
> present in aldor 1.0.2.

This file is present in aldor 1.1.0 built from the source distribution.

root@sage:~/aldor-src/aldor# find . -name runtime.lsp
./install/aldor/linux/1.1.0/lib/runtime.lsp

> Therefore I stepped back to the 1.0.2 binary which fortunately
> still lives on my hard disk.
>
> A new problem appeared recently which was described earlier in
> http://www.mail-archive.com/axiom-d...@nongnu.org/msg04622.html
> and after doing what this message indicates the build succeeded.
>

Great. I will try this recipe.

> > If anyone has any advice, I would greatly appreciate it.
>
> Since now both aldor and fricas became moving targets,
> the right way is of course to understand and modify the
> aldor-for-axiom Makefile, however this exceeds my capabilities
> and I don't have the time to dig into it.

I agree with you. After I get the first good compile the old way
I will try to modify it incrementally to conform to the FriCAS
distribution.

> Anyways, below is what worked for me for fricas rev 88 and
> aldor 1.0.2.
>

Thanks. I appreciate it.

Regards,
Bill Page.

Bill Page

unread,
Nov 8, 2007, 9:19:16 PM11/8/07
to fricas...@googlegroups.com, Peter Broadbery
On 11/8/07, Bill Page wrote:
> On 11/8/07, Franz wrote:
> > ...

> > Anyways, below is what worked for me for fricas rev 88 and
> > aldor 1.0.2.
> >
>
> Thanks. I appreciate it.
>

Well, I still seem to have the same problem. :-(

Here is my build script:

root@sage:~/fricas-test# cat ./build-aldor4axiom
#
#Aldor
#
echo Build directory \(expect ~/fricas-test\):
pwd

export ARCH=x86_64-unknown-linux
echo ARCH=$ARCH
export AXIOM=$PWD/target/$ARCH
echo AXIOM=$AXIOM
export ALDORROOT=~/aldor-src/aldor/install/aldor/linux/1.1.0
echo ALDORROOT=$ALDORROOT

echo Clean up from last time
rm -rf int obj src/aldor $AXIOM/bin/document src/scripts

echo Build directories


(cd $AXIOM/bin; ln -s ../../../build/scripts/document .)
mkdir -p obj/$ARCH
(cd obj/$ARCH ; ln -s ../../build/$ARCH/bin .)
(cd obj/$ARCH ; ln -s ../../src/interp/ .)

cd src

echo For axiom.sty in `pwd`
ln -s $AXIOM/src/scripts .

echo Unpack src_aldor2.tgz
tar xzf ~/fricas-src/src_aldor2.tgz

cd aldor

echo Add /bin and /lib to `pwd`
ln -s ../../build/$ARCH .

echo Tangle sources in `pwd`
for pp in *.pamphlet; do ../../build/scripts/document --tangle $pp;done

echo Link algebra files
(cd ../..; mkdir -p int/algebra;cd int/algebra; lndir -silent
../../src/algebra/)

echo Start build
make

--------

And here is the output:

root@sage:~/fricas-test# cat nohup.out
Build directory (expect /home/page/fricas-test):
/home/page/fricas-test
ARCH=x86_64-unknown-linux
AXIOM=/home/page/fricas-test/target/x86_64-unknown-linux
ALDORROOT=/home/page/aldor-src/aldor/install/aldor/linux/1.1.0
Clean up from last time
Build directories
For axiom.sty in /home/page/fricas-test/src
Unpack src_aldor2.tgz
Add /bin and /lib to /home/page/fricas-test/src/aldor
Tangle sources in /home/page/fricas-test/src/aldor
Link algebra files
Start build


Building libaxiom.al and associated files

/home/page/fricas-test/int/aldor


make[1]: Entering directory `/home/page/fricas-test/src/aldor'

/home/page/fricas-test/src/aldor/types.mk:45:
/home/page/fricas-test/int/aldor/all_spad_types.mk: No such file or
directory
/home/page/fricas-test/src/aldor/types.mk:46:
/home/page/fricas-test/int/aldor/all_spad_cats.mk: No such file or
directory
/home/page/fricas-test/src/aldor/types.mk:156:
/home/page/fricas-test/int/aldor/saxiom/spadset.mk
/home/page/fricas-test/src/aldor/Make.rules:357:
/home/page/fricas-test/int/aldor/all_spadsets.mk: No such file or
directory
/home/page/fricas-test/src/aldor/Make.axiom:53:
/home/page/fricas-test/int/aldor/dep_ax0.mk: No such file or directory
/home/page/fricas-test/src/aldor/Make.axiom:53:
/home/page/fricas-test/int/aldor/dep_spad.mk: No such file or
directory
mkdir -p /home/page/fricas-test/int/aldor
touch -t 199901010000 /home/page/fricas-test/int/aldor/.dir
echo > /home/page/fricas-test/int/aldor/dep_spad.mk
echo 'MODE := DEP' >> /home/page/fricas-test/int/aldor/dep_spad.mk
echo 'THIS_DEP := spad' >> /home/page/fricas-test/int/aldor/dep_spad.mk
echo 'include $(IN)/Make.rules' >> /home/page/fricas-test/int/aldor/dep_spad.mk
echo > /home/page/fricas-test/int/aldor/dep_ax0.mk
echo 'MODE := DEP' >> /home/page/fricas-test/int/aldor/dep_ax0.mk
echo 'THIS_DEP := ax0' >> /home/page/fricas-test/int/aldor/dep_ax0.mk
echo 'include $(IN)/Make.rules' >> /home/page/fricas-test/int/aldor/dep_ax0.mk
mkdir -p /home/page/fricas-test/int/aldor/make
touch -t 199901010000 /home/page/fricas-test/int/aldor/make/.dir
SPADSET MK: all_spadsets.mk


make[1]: Leaving directory `/home/page/fricas-test/src/aldor'

make[1]: Entering directory `/home/page/fricas-test/src/aldor'
/home/page/fricas-test/src/aldor/types.mk:156:
/home/page/fricas-test/int/aldor/saxiom/spadset.mk


/home/page/fricas-test/src/aldor/Make.rules:179: ALL SPADSETS sax0 saxiom

/home/page/fricas-test/src/aldor/Make.rules:365:
/home/page/fricas-test/int/aldor/sax0/spadset_check.mk: No such file
or directory
/home/page/fricas-test/src/aldor/Make.rules:365:
/home/page/fricas-test/int/aldor/saxiom/spadset_check.mk: No such file
or directory
/home/page/fricas-test/src/aldor/Make.rules:106: W: 1 I: 0
/home/page/fricas-test/src/aldor/Make.rules:107: W:
/home/page/fricas-test/int/aldor/sax0/spadset.mk
mkdir -p /home/page/fricas-test/int/aldor/ao
touch -t 199901010000 /home/page/fricas-test/int/aldor/ao/.dir
mkdir -p /home/page/fricas-test/int/aldor/saxiom
touch -t 199901010000 /home/page/fricas-test/int/aldor/saxiom/.dir
mkdir -p /home/page/fricas-test/int/aldor/sax0
touch -t 199901010000 /home/page/fricas-test/int/aldor/sax0/.dir


make[1]: Leaving directory `/home/page/fricas-test/src/aldor'

make[1]: Entering directory `/home/page/fricas-test/src/aldor'
/home/page/fricas-test/src/aldor/types.mk:156:
/home/page/fricas-test/int/aldor/saxiom/spadset.mk


/home/page/fricas-test/src/aldor/Make.rules:179: ALL SPADSETS sax0 saxiom
/home/page/fricas-test/src/aldor/Make.rules:200: (0,0)
/home/page/fricas-test/src/aldor/Make.rules:204:

/home/page/fricas-test/int/aldor/sax0/spadset.mk: No such file or


directory
/home/page/fricas-test/src/aldor/Make.rules:200: (1,1)
/home/page/fricas-test/src/aldor/Make.rules:204:

/home/page/fricas-test/int/aldor/saxiom/spadset.mk: No such file or


directory
/home/page/fricas-test/src/aldor/Make.rules:106: W: 1 I: 1
/home/page/fricas-test/src/aldor/Make.rules:107: W:

/home/page/fricas-test/int/aldor/sax0/spadset.mk
(javac -d /home/page/fricas-test/int/aldor
/home/page/fricas-test/src/aldor/Sort.java)
Note: /home/page/fricas-test/src/aldor/Sort.java uses unchecked or
unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
mkdir -p /home/page/fricas-test/int/aldor/gendeps
touch -t 199901010000 /home/page/fricas-test/int/aldor/gendeps/.dir
mkdir -p /home/page/fricas-test/int/aldor/deps
touch -t 199901010000 /home/page/fricas-test/int/aldor/deps/.dir
mkdir -p /home/page/fricas-test/int/aldor/tmp
touch -t 199901010000 /home/page/fricas-test/int/aldor/tmp/.dir
Creating dependencies for spad C: 963
mkdir -p /home/page/fricas-test/int/aldor/init_ap
touch -t 199901010000 /home/page/fricas-test/int/aldor/init_ap/.dir
echo > /home/page/fricas-test/int/aldor/mkinit.lsp
echo ")set bre fast" >> /home/page/fricas-test/int/aldor/mkinit.lsp
echo ")lisp (break)" >> /home/page/fricas-test/int/aldor/mkinit.lsp
echo '(load "/home/page/fricas-test/src/aldor/genax.lsp")' >>
/home/page/fricas-test/int/aldor/mkinit.lsp
echo '(generate-init-files
"/home/page/fricas-test/src/aldor/baselist.lsp"
"/home/page/fricas-test/int/aldor/initdomains.tmp")' >>
/home/page/fricas-test/int/aldor/mkinit.lsp
(cd /home/page/fricas-test/int/aldor;
DAASE="/home/page/fricas-test/int"; export DAASE;
/home/page/fricas-test/obj/x86_64-unknown-linux/bin/interpsys) \
<
/home/page/fricas-test/int/aldor/mkinit.lsp >
/home/page/fricas-test/int/aldor/tmp/mkinit.log
test -f /home/page/fricas-test/int/aldor/initdomains.tmp
touch /home/page/fricas-test/int/aldor/initdomains.stamp


make[1]: *** No rule to make target

`/home/page/fricas-test/src/aldor/as//home/page/fricas-test/int/aldor/ap/axlit.as',
needed by `/home/page/fricas-test/int/aldor/ap/axlit.ap'. Stop.


make[1]: Leaving directory `/home/page/fricas-test/src/aldor'
make: *** [all] Error 2

root@sage:~/fricas-test#

----------

I've tried to trace the execution of the make files but this sure is a
complicated beast! So far I do not understand what (or even exactly
where) it is failing.

Any ideas?

Regards,
Bill Page.

Waldek Hebisch

unread,
Nov 8, 2007, 10:34:30 PM11/8/07
to fricas...@googlegroups.com
Bill Page wrote:
> make[1]: *** No rule to make target
> `/home/page/fricas-test/src/aldor/as//home/page/fricas-test/int/aldor/ap/axlit.as',
> needed by `/home/page/fricas-test/int/aldor/ap/axlit.ap'. Stop.
> make[1]: Leaving directory `/home/page/fricas-test/src/aldor'
> make: *** [all] Error 2
> root@sage:~/fricas-test#
>
> ----------
>
> I've tried to trace the execution of the make files but this sure is a
> complicated beast! So far I do not understand what (or even exactly
> where) it is failing.
>
> Any ideas?
>

It looks that intended dependency is given by the line:

$(AX0_AP_FILES): $(MID)/ap/%.ap: $(IN)/as/%.as $(MID)/ap/.dir

in libaxiom.mk. Namely, in the same file earlier we have:

AX0_AP_FILES := $(patsubst %.as,$(MID)/ap/%.ap,$(LIBAX0_ALDOR_ITEMS))

and earlier

LIBAX0_ALDOR_ITEMS := lang.as stub.as axlit.as axextend.as

OTOH, if the error is really in that line, it looks like make bug:
the % in $(IN)/as/%.as is supposed to be the same as % in
$(MID)/ap/%.ap -- that is percent should match the basename.
But the message looks like percent got matched to the pathname
minus extension.

To check if that is really the case you may try to replace the
pattern rule above by 3 spearate rules like:

/home/page/fricas-test/int/aldor/ap/axlit.ap: /home/page/fricas-test/src/aldor/as/axlit.as /home/page/fricas-test/int/aldor/ap/.dir

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

Martin Rubey

unread,
Nov 9, 2007, 12:29:53 AM11/9/07
to fricas...@googlegroups.com
What make version are you using?

Martin

Bill Page

unread,
Nov 9, 2007, 9:12:48 AM11/9/07
to fricas...@googlegroups.com, Waldek Hebisch, Martin Rubey
On 09 Nov 2007 06:29:53 +0100, Martin Rubey <martin...@univie.ac.at> wrote:
>
> What make version are you using?
>

root@sage:/# make --version
GNU Make 3.81beta4
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for x86_64-pc-linux-gnu
root@sage:/#

It looks like Waldek's analysis is correct. It very likely is a make
bug. I thought what I was running here in the chroot on the Sage
server was the same as in the base system which is a fairly recent
version of Ubuntu, but apparently not since outside the chroot jail I
see:

page@sage:~$ make --version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for x86_64-pc-linux-gnu
page@sage:~$

------

I tried ran 'apt-get update' and 'apt-get upgrade' in the chroot but
make remains the old version - even after 'apt-get remove make'
'apt-get install make'. I don't know what is going on here. So I
decided to rebuild make from source and put it in /usr/local/bin where
I can control it. Now I see:

root@sage:/# which make
/usr/local/bin/make
root@sage:/# make --version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for x86_64-unknown-linux-gnu
root@sage:/#

------

And now I get ...

...
Creating dependencies for ax0 C: 2
(cd /home/page/fricas-test/int/aldor; \
java -cp `pwd` Sort base
/home/page/fricas-test/int/aldor/deps/axextend.dep
/home/page/fricas-test/int/aldor/typelist
/home/page/fricas-test/int/aldor/initdomains \

/home/page/fricas-test/src/aldor/extra_deps.lst)
Top level is: [PFECAT, SAOS, OMENC, LOGIC, LMODULE, COMRING, FRETRCT,
POLYCAT, SGROUP, CHARZ, IXAGG, CHAR, OAMONS, SINT, MONOID, INFORM,
FRAC, TYPE, ENTIRER, PATTERN, OAGROUP, RCAGG, FSAGG, RNS, OUTFORM,
CARD, NNI, UFD, ES, OMDEV, INTDOM, EQ, STAGG, STREAM, RNG, HOAGG,
LSAGG, MATRIX, PID, SYMBOL, IEVALAB, EVALAB, BGAGG, FINITE, LZSTAGG,
OM, FR, URAGG, INT, INS, LIST, ALAGG, A1AGG, REAL, TBAGG, GROUP,
KERNEL, ATRIG, ALGEBRA, VECTCAT, NONE, CCLASS, PATRES, RADCAT, UPOLYC,
KDAGG, FIELD, ABELMON, PI, ORDSET, RETRACT, DIFRING, ELTAGG, QFCAT,
DIOPS, SEXCAT, HYPCAT, AMR, LINEXP, BASTYPE, OAMON, CABMON, RING,
STEP, OASGP, FLOAT, AHYP, DIVRING, SETAGG, ALIST, PDRING, FEVALAB,
ORDRING, SUP, SETCAT, SEG, BMODULE, BOOLEAN, EUCDOM, UNISEG, LNAGG,
BOP, CACHSET, FLAGG, ORDFIN, SEGCAT, KONVERT, ELTAB, PATMAB, STRICAT,
ELEMFUN, ABELSG, TRIGCAT, MATCAT, TRANFUN, SRAGG, CFCAT, CLAGG, SEX,
MODULE, ELAGG, AGG, VSPACE, ARR2CAT, DFLOAT, ABELGRP, RMODULE, ANY,
VECTOR, GCDDOM, DIAGG, SEGXCAT, PATAB, CHARNZ, FAMR, DIFEXT, FPS,
FPATMAB, OCAMON, OINTDOM, FLINEXP, STRING, KOERCE]
Exception: java.io.FileNotFoundException: deps/REAL.dep (Too many open files)
Exception in thread "main" java.lang.RuntimeException:
java.io.FileNotFoundException: deps/REAL.dep (Too many open files)
at Sort.getNames(Sort.java:676)
at Sort.generateBaseSet(Sort.java:625)
at Sort.run(Sort.java:464)
at Sort.main(Sort.java:432)
Caused by: java.io.FileNotFoundException: deps/REAL.dep (Too many open files)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:106)
at java.io.FileReader.<init>(FileReader.java:55)
at Sort.getNames(Sort.java:666)
... 3 more
make[1]: *** [/home/page/fricas-test/int/aldor/sax0/spadset.mk] Error 1


make[1]: Leaving directory `/home/page/fricas-test/src/aldor'
make: *** [all] Error 2

--------

which is a definite improvement! :-)

Thanks for the help. I will keep you all informed.

Regards,
Bill Page.

Bill Page

unread,
Nov 9, 2007, 10:08:08 AM11/9/07
to fricas...@googlegroups.com, Waldek Hebisch, Martin Rubey
On 11/9/07, Bill Page <bill...@newsynthesis.org> wrote:
>
> And now I get ...
> ...
> Caused by: java.io.FileNotFoundException: deps/REAL.dep (Too many open files)
> at java.io.FileInputStream.open(Native Method)
> at java.io.FileInputStream.<init>(FileInputStream.java:106)
> at java.io.FileReader.<init>(FileReader.java:55)
> at Sort.getNames(Sort.java:666)
> ... 3 more
> make[1]: *** [/home/page/fricas-test/int/aldor/sax0/spadset.mk] Error 1
> make[1]: Leaving directory `/home/page/fricas-test/src/aldor'
> make: *** [all] Error 2
>
> --------
>

This is still like "pulling my hair"! :-)

After setting:

ulimit -n 65535

I now get:

...
mkdir -p /home/page/fricas-test/obj/x86_64-unknown-linux/aldor/build
touch -t 199901010000
/home/page/fricas-test/obj/x86_64-unknown-linux/aldor/build/.dir
MERGE: libaxiom_lang.lst (1)
(cd /home/page/fricas-test/int/aldor/ao; \
ar x /home/page/aldor-src/aldor/install/aldor/linux/1.1.0/lib/libaxllib.al
lang.ao)
mkdir -p /home/page/fricas-test/int/aldor/lsp
touch -t 199901010000 /home/page/fricas-test/int/aldor/lsp/.dir
aldor -Flsp -R /home/page/fricas-test/int/aldor/lsp
/home/page/fricas-test/int/aldor/ao/lang.ao
mkdir -p /home/page/fricas-test/target/x86_64-unknown-linux/aldor/lib
touch -t 199901010000
/home/page/fricas-test/target/x86_64-unknown-linux/aldor/lib/.dir
cp /home/page/fricas-test/int/aldor/lsp/lang.lsp
/home/page/fricas-test/target/x86_64-unknown-linux/aldor/lib/lang.lsp
echo LSP->O: lang.o
GCL (GNU Common Lisp) 2.6.8 ANSI Sep 11 2007 22:04:47
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/

>
Loading /home/page/fricas-test/obj/x86_64-unknown-linux/interp/foam_l.o
start address -T 0x31ba020 Finished loading
/home/page/fricas-test/obj/x86_64-unknown-linux/interp/foam_l.o
Compiling /home/page/fricas-test/target/x86_64-unknown-linux/aldor/lib/lang.lsp.
Error in IN-PACKAGE [or a callee]: A package error occurred on
#<"FOAM-USER" package>: "Cannot use package as it will produce a name
conflict".

Fast links are on: do (use-fast-links nil) for debugging
Broken at APPLY. Type :H for Help.
1 (Continue)
2 (SYSTEM:ERROR-SET
'(EVAL '(IN-PACKAGE "FOAM-USER" :USE '("FOAM" "LISP"))))
3 (Abort) Return to top level.
dbl:>>make[1]: ***
[/home/page/fricas-test/target/x86_64-unknown-linux/aldor/lib/lang.o]


Error 1
make[1]: Leaving directory `/home/page/fricas-test/src/aldor'
make: *** [all] Error 2

[1]+ Exit 2 nohup ./build-aldor4axiom
root@sage:~/fricas-test#

---------

I am guessing, but I think it is possible that this problem is caused
by the fact that I am using the ANSI version of GCL 2.6.8pre to
compile FriCAS. I guess I will try this all again starting with
rebuilding GCL in non-ANSI mode and rebuild FriCAS and then src_aldor2
again.

Regards,
Bill Page.

Martin Rubey

unread,
Nov 9, 2007, 10:45:30 AM11/9/07
to Bill Page, fricas...@googlegroups.com
"Bill Page" <bill...@newsynthesis.org> writes:

> On 09 Nov 2007 06:29:53 +0100, Martin Rubey <martin...@univie.ac.at> wrote:
> >
> > What make version are you using?
> >
>
> root@sage:/# make --version
> GNU Make 3.81beta4

Hehe, you did read my comments on MathAction, didn't you :-)

Sorry I didn't spot that possibility earlier.

Martin

Bill Page

unread,
Nov 9, 2007, 10:12:23 PM11/9/07
to Peter Broadbery, Martin Rubey, fricas...@googlegroups.com, open-axi...@lists.sourceforge.net
On 11/9/07, Peter Broadbery wrote:
>
> >On 08 Nov 2007 14:48:12 +0100, Martin Rubey wrote:
> > ...

> > > But really, it's Peter who is the boss of the axiom-aldor
> > > interaction.
> >
> > "Bill Page" writes:
> >Indeed! :-)
>
> Um, I'll not be the boss of anything. I just hack stuff sometimes...
>

By "boss" I understood Martin to mean: "The one who knows the most
about this subject." For better or worse you might have to admit to
that label ... at least until a few of us are able to learn more about
this magic. :-)

> From the output
> `/home/page/fricas-test/src/aldor/as//home/page/fricas-test/src/aldor/aldor/ap/axlit.as',
>
> looks like you've got a full path where a relative one was expected.
> ...

Actually I think Waldek and Martin had this right and this very
unexpected error is actually caused by using a beta version of GNU
Make prior to the release of 3.81.

After updating 'make', rebuilding 'gcl' for CLtL1 instead of ANSI, and
recompiling FriCAS using this older Lisp, I get much further but then
the build stops with the following error:

...
MERGE: libaxiom_SMP.lst (43)
GEN AP: SMP.spad -> SMP.ap
AOBUILD LIB: axiom ELT: SMP DEPS: 4
MERGE: libaxiom_FS.lst (45)
GEN AP: FS.spad -> FS.ap
AOBUILD LIB: axiom ELT: FS DEPS: 4
aldor -Y /home/page/fricas-test/int/aldor/tmp -L
AxiomLib=axiom_FS -Wname=axiom -fao
/home/page/fricas-test/int/aldor/ap/FS.ap
"/home/page/fricas-test/int/aldor/ap/FS.ap", line 355:
(|Apply| |Polynomial|
......................................................^
[L355 C55] #9 (Error) No one possible return type satisfies the context type.
These possible return types were rejected:
-- PolynomialCategory(#1, IndexedExponents(Symbol), Symbol) with ...
The context requires an expression of type with
%%: PolynomialCategory(Fraction....

"/home/page/fricas-test/int/aldor/ap/FS.ap", line 593:
(|Apply| |Polynomial|
.....................................................^
[L593 C54] #5 (Error) No one possible return type satisfies the context type.
These possible return types were rejected:
-- PolynomialCategory(#1, IndexedExponents(Symbol), Symbol) with ...
The context requires an expression of type with
%%: PolynomialCategory(#1 prete....

"/home/page/fricas-test/int/aldor/ap/FS.ap", line 1254:
(|Apply| |Polynomial|
....................................................^
[L1254 C53] #3 (Error) No one possible return type satisfies the context type.
These possible return types were rejected:
-- PolynomialCategory(#1, IndexedExponents(Symbol), Symbol) with ...
The context requires an expression of type with
%%: PolynomialCategory(#1 prete....

"/home/page/fricas-test/int/aldor/ap/FS.ap", line 1318:
(|Apply| |Polynomial|
......................................................^
[L1318 C55] #1 (Error) No one possible return type satisfies the context type.
These possible return types were rejected:
-- PolynomialCategory(#1, IndexedExponents(Symbol), Symbol) with ...
The context requires an expression of type with
%%: PolynomialCategory(#1 prete....
[L1318 C55] #11 (Fatal Error) Too many errors (use `-M emax=n' or `-M
no-emax' to change the limit).

make[1]: *** [/home/page/fricas-test/int/aldor/ao/FS.ao] Error 1


make[1]: Leaving directory `/home/page/fricas-test/src/aldor'
make: *** [all] Error 2
root@sage:~/fricas-test/src/aldor#

--------

> ...
> Against aldor-1.1 you'll need a small patch to the way axiom computes
> hash codes (I couldn't have got this without the source code, by the ways..):
>
> hashType(type, percentHash) ==
> SYMBOLP type =>
> type = '$ => percentHash
> type = "%" => percentHash
> hashString SYMBOL_-NAME type
> STRINGP type => hashCombine(hashString type,
> hashString('"Enumeration"))
> type is ['QUOTE, val] => hashType(val, percentHash)
> type is [dom] => hashString SYMBOL_-NAME dom
> type is ['_:, ., type2] => hashType(type2, percentHash)
> isDomain type => getDomainHash type
> [op, :args] := type
> hash := hashString SYMBOL_-NAME op
> op = 'Mapping =>
> hash := hashString '"->"
> [retType, :mapArgs] := args
> for arg in mapArgs repeat
> hash := hashCombine(hashType(arg, percentHash), hash)
> retCode := hashType(retType, percentHash)
> EQL(retCode, $VoidHash) => hash
> hashCombine(retCode, hashCombine(32236, hash))
> op = 'Enumeration =>
> for arg in args repeat
> hash := hashCombine(hashString(STRING arg), hash)
> hash
> op in $DomainsWithoutLisplibs =>
> for arg in args repeat
> hash := hashCombine(hashType(arg, percentHash), hash)
> hash
>
> cmm := CDDAR getConstructorModemap(op)
> cosig := CDR GETDATABASE(op, 'COSIG)
> for arg in args for c in cosig for ct in cmm repeat
> if c then
> hash := hashCombine(hashType(arg, percentHash), hash)
> else
> hash := hashCombine(7, hash)
> -- !!! If/when asharp hashes values using their type, use instead
> -- ctt := EQSUBSTLIST(args, $FormalMapVariableList, ct)
> -- hash := hashCombine(hashType(ctt, percentHash), hash)
>
>
> hash

Thanks for this code! I am guessing again that the error in the most
recent build attempt might have somthing to do with this hash
function. So I will apply this patched version of 'hashType' to
FriCAS, rebuild Axiom and try again.

Thanks again for your help.

Regards,
Bill Page.

Martin Rubey

unread,
Nov 10, 2007, 3:10:56 AM11/10/07
to Peter Broadbery, fricas...@googlegroups.com, open-axi...@lists.sourceforge.net
Peter Broadbery <p_bro...@hotmail.com> writes:

> >> But really, it's Peter who is the boss of the axiom-aldor interaction.
> >>
> >
> >Indeed! :-)
>

> Um, I'll not be the boss of anything. I just hack stuff sometimes...

And doing a good job there!

Martin

Bill Page

unread,
Nov 11, 2007, 3:13:37 PM11/11/07
to fricas...@googlegroups.com, Peter Broadbery, open-axi...@lists.sourceforge.net, axiom...@nongnu.org
Success!

After a little more fighting with the src_aldor2.tgz makefile, I have
finally managed to build the Aldor interface in FriCAS. As Peter said,
a patch to Axiom's 'hashType' was necessary to make this work. I now
have Axiom (FriCAS) with Aldor 1.1.0 (including Peter's most recent
patch to Aldor for destructing in for-loops), installed and working at
the new Axiom wiki:

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

Note: The build instructions here are still not up to date. I will get
to that later today.

On this system we have Axiom (FriCAS) and Aldor built with:

Aldor: Rev 16
FriCAS: Rev 123

If you have a chance, please give this a test and let me know if you
find any problems.

My plan next is to incorporate a preliminary version of the build
script into the FriCAS distribution so that building the interface
(should) become easier.

Regards,
Bill Page.

Gabriel Dos Reis

unread,
Nov 11, 2007, 3:59:45 PM11/11/07
to Bill Page, fricas...@googlegroups.com, open-axi...@lists.sourceforge.net, axiom...@nongnu.org, Peter Broadbery
"Bill Page" <bill...@newsynthesis.org> writes:

[...]

| My plan next is to incorporate a preliminary version of the build
| script into the FriCAS distribution so that building the interface
| (should) become easier.

Do you plan similar scripts for OpenAxiom?

-- Gaby

Bill Page

unread,
Nov 11, 2007, 4:08:48 PM11/11/07
to Gabriel Dos Reis, fricas...@googlegroups.com, open-axi...@lists.sourceforge.net, axiom...@nongnu.org, Peter Broadbery

Yes, I think the same build script will work for both FriCAS and
OpenAxiom. I will let you know in a few days.

Regards,
Bill Page

Martin Rubey

unread,
Dec 15, 2007, 2:50:58 PM12/15/07
to fricas...@googlegroups.com, Peter Broadbery, open-axi...@lists.sourceforge.net, axiom...@nongnu.org
Dear Bill, Peter, Waldek,

two questions concerning the axiom-aldor interface:

1) do you think you could already

> incorporate a preliminary version of the build script into the FriCAS
> distribution so that building the interface (should) become easier.

2) is the patch to 'hashType' already in FriCAS, or do I have to apply it
myself?

many thanks,

Martin

Bill Page

unread,
Dec 15, 2007, 4:18:11 PM12/15/07
to fricas...@googlegroups.com, Peter Broadbery, open-axi...@lists.sourceforge.net, axiom...@nongnu.org
On 15 Dec 2007 20:50:58 +0100, Martin Rubey wrote:
>
> two questions concerning the axiom-aldor interface:
>
> 1) do you think you could already
>
> > incorporate a preliminary version of the build script into the
> > FriCAS distribution so that building the interface (should)
> > become easier.
>

I was planning to do this but got sidetracked on other subjects. I
would be glad to help you do it.

> 2) is the patch to 'hashType' already in FriCAS, or do I have
> to apply it myself?
>

It is not yet in FriCAS. You could submit at patch.

> many thanks,
>

Let me know how I can help.

Regards,
Bill Page.

Waldek Hebisch

unread,
Dec 16, 2007, 3:20:37 PM12/16/07
to fricas...@googlegroups.com
Bill Page wrote:
>
> On 15 Dec 2007 20:50:58 +0100, Martin Rubey wrote:
> > 2) is the patch to 'hashType' already in FriCAS, or do I have
> > to apply it myself?
> >
>
> It is not yet in FriCAS. You could submit at patch.
>

I would be good to know if we always had 'hashType' wrong or
if this is an incompatible change in Aldor. If the later
we probably should document which Aldor versions are supposed
to work.

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

Martin Rubey

unread,
Dec 17, 2007, 8:57:06 AM12/17/07
to Bill Page, Franz Lehner, fricas...@googlegroups.com, open-axi...@lists.sourceforge.net, Peter Broadbery
Dear Bill, *,

I just can't get it to work.

I did:

cd ax-build-clean

# create the directory structure expected by the aldor interface
mkdir int
cd int
ln -s ../src/algebra .
cd ../..
# now I'm in ax-build-clean again
ln -s build obj

cd src/aldor
document Makefile.pamphlet
export $AXIOM=/local/scratch/ax-build-clean/target/i686-pc-linux .

make

# make stops with
# SPADSET MK: all_spadsets.mk
# make[1]: *** Keine Regel, um »/local/scratch/ax-build-clean/int/aldor/all_spad_cats.mk« zu erstellen. Schluss.
# make[1]: Verlasse Verzeichnis '/local/scratch/ax-build-clean/src/aldor'
# make: *** [all] Fehler 2

cd ../..
# now I'm in ax-build-clean again
touch int/aldor/dep_spad.pamphlet

cd src/aldor
document Make.functions.pamphlet
make

But now I get:

make[1]: [/local/scratch/ax-build-clean/int/aldor/initdomains.stamp] Fehler 255 (ignoriert)
test -f /local/scratch/ax-build-clean/int/aldor/initdomains.tmp
touch /local/scratch/ax-build-clean/int/aldor/initdomains.stamp
../../target/i686-pc-linux//bin/document /local/scratch/ax-build-clean/src/aldor/as/axlit.as
(cd $(dirname /local/scratch/ax-build-clean/src/aldor/as/axlit.as); ../../target/i686-pc-linux//bin/document /local/scratch/ax-build-clean/src/aldor/as/axlit.as)
/bin/sh: ../../target/i686-pc-linux//bin/document: No such file or directory
make[1]: *** [/local/scratch/ax-build-clean/src/aldor/as/axlit.as] Fehler 127
make[1]: Verlasse Verzeichnis '/local/scratch/ax-build-clean/src/aldor'
make: *** [all] Fehler 2

I really really need help! I can't read Makefiles. Many thanks,

Martin


Bill Page

unread,
Dec 17, 2007, 10:43:44 AM12/17/07
to Martin Rubey, Franz Lehner, fricas...@googlegroups.com, open-axi...@lists.sourceforge.net, Peter Broadbery
On 17 Dec 2007 14:57:06 +0100, Martin Rubey wrote:
>
> I just can't get it to work.
>
> I did:
> ...

> I really really need help! I can't read Makefiles. Many
> thanks,
>

I do not see immediately from the output in your email what that
problem might be although as I recall the process was not smooth one
the last time I tried. I need to update FriCAS on newsynthesis.org and
I want to add Aldor support to OpenAxiom there also, so I will try to
repeat in yet more detail the process I described in my emails of a
few weeks ago. (If you haven't read these yet, perhaps there is
something in the email archive that might help.)

It might take be a couple of days to get back to you on this.

Regards,
Bill Page.

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

unread,
Dec 17, 2007, 1:15:41 PM12/17/07
to fricas...@googlegroups.com
Dear Martin,

On Mon, Dec 17, 2007 at 02:57:06PM +0100, Martin Rubey wrote:
> /bin/sh: ../../target/i686-pc-linux//bin/document: No such file or directory
That means that document is not where it is supposed to be.
I saw that error too sometimes.
In my last installation I made it point to

fricas-build/target/x86_64-unknown-linux/bin$ ls -l document
lrwxrwxrwx 1 lehner lehner 31 2007-11-01 00:45 document -> ../../../build/scripts/document

and the build proceeded.

> I really really need help! I can't read Makefiles. Many thanks,

I also gave up on those recursive Makefiles.
Bill, did you succeed last time by modifying the Makefile or by building a link
farm?

good luck,
Franz

Bill Page

unread,
Dec 17, 2007, 11:52:04 PM12/17/07
to fricas...@googlegroups.com

By building links - the same as you did, based on your notes. But we
all agree that this is not the best approach... right? With a little
more time I think this could fairly easily be done right. Recently
Peter said here that he was working on a new build system but we have
not heard anything more from him lately.

Regards,
Bill Page.

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

unread,
Jan 16, 2008, 5:16:00 AM1/16/08
to fricas...@googlegroups.com
Dear Bill, Martin,

> After a little more fighting with the src_aldor2.tgz makefile, I have
> finally managed to build the Aldor interface in FriCAS. As Peter said,
> a patch to Axiom's 'hashType' was necessary to make this work.

Is this patch publicly available anywhere?

The following applies to an debian etch-amd64 system on a core2 duo
machine. First I compiled fricas-183.
@Waldek:
A cosmetic remark.
At the first try I didn't notice that more X libraries are needed now and the
X interface was not compiled. However the fricas script does
not reflect this fact and without -nosman it looks for hypertex etc
and goes into an infinite loop which can only be terminated by kill -9.


As I don't have the time and expertise for Makefile surgery,
I did as earlier (PWD is fricas-build):


ARCH=x86_64-unknown-linux
export AXIOM=$PWD/target/$ARCH
export ALDORROOT=/usr/opt/Aldor-1.0.2-amd64/aldor/linux/1.0.2

(cd $AXIOM/bin; ln -s ../../../build/scripts/document .)
mkdir -p obj/$ARCH
(cd obj/$ARCH ; ln -s ../../build/$ARCH/bin .)
(cd obj/$ARCH ; ln -s ../../src/interp/ .)

cd src


#for axiom.sty
ln -s ../../fricas-88/src/scripts/ .

tar xzf ../../src_aldor2.tgz
cd aldor
ln -s ../../build/$ARCH .

for pp in *.pamphlet; do ../../build/scripts/document $pp;done

(cd ../..; mkdir -p int/algebra;cd int/algebra; lndir

../../src/algebra/)

make

and there was NO error message at all. A few tests indicate that
everything seems to work as it should.

Then I wanted to repeat the process with aldor 1.1.0.
First I built the latter from scratch; it turns out that in addition
to the steps in README.building one has to do
cd lib/libax0; make in order to have axiom.as
Is this documented somewhere?

Then I repeated the above steps with aldor-1.1.0 (from a clean
build of fricas-183) and ran into the error reported by Bill
and which apparently can be overcome by the hashType patch.

The next thing to try will be sbcl (for profiling).

best regards,
Franz

Martin Rubey

unread,
Jan 17, 2008, 3:21:22 AM1/17/08
to fricas...@googlegroups.com
Dear Franz,

MANY MANY thanks for your instructions! They just worked! (except that I don't
have lndir, but I did for f in ../../src/algebra/*; do ln -s $f; done; instead)

They should definitively replace the old instructions on the wiki. In fact, I
think that both src_aldor2.tgz and your script should go into the fricas
contrib directory, say, contrib/aldor. Maybe you could polish your script so
that it doesn't use lndir, detects ARCH automatically and does not depend on
the fricas source directory any longer.

ARCH is detected also in contrib/debian/mk_deb, you could steal it from there

The fricas source directory is used only to get axiom.sty, I think? Maybe you
could just pack it into contrib too?

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

> > After a little more fighting with the src_aldor2.tgz makefile, I have
> > finally managed to build the Aldor interface in FriCAS. As Peter said, a
> > patch to Axiom's 'hashType' was necessary to make this work.

> Is this patch publicly available anywhere?

Here it is:

Index: src/interp/hashcode.boot
===================================================================
--- src/interp/hashcode.boot (Revision 183)
+++ src/interp/hashcode.boot (Arbeitskopie)
@@ -55,7 +55,7 @@


hash := hashCombine(hashType(arg, percentHash), hash)
retCode := hashType(retType, percentHash)
EQL(retCode, $VoidHash) => hash

- hashCombine(retCode, hash)
+ hashCombine(retCode, hashCombine(32236, hash))


op = 'Enumeration =>
for arg in args repeat
hash := hashCombine(hashString(STRING arg), hash)

Don't ask me what it does, however :-)

Many thanks again,


Martin

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

unread,
Jan 17, 2008, 10:09:56 AM1/17/08
to fricas...@googlegroups.com
Dear Martin,

> think that both src_aldor2.tgz and your script should go into the fricas
> contrib directory, say, contrib/aldor.

Ok I now have a self-contained script that works with aldor 1.0.2
(see attachment). From $FRICAS_BUILD you should see

usr/local/src/axiom/fricas-gcl$ ls aldor:
mkaldor.sh scripts src_aldor2.tgz

usr/local/src/axiom/fricas-gcl$ ls aldor/scripts/tex/
axiom.sty

The latter is copied from the fricas source tree. Can you try it in
your config?

However the hashcode patch doesn't fix the aldor 1.1.0 problem here,
I still get
...


GEN AP: FS.spad -> FS.ap
AOBUILD LIB: axiom ELT: FS DEPS: 4

aldor -Y /home/lehner/usr/local/src/axiom/fricas-gcl/int/aldor/tmp -L AxiomLib=axiom_FS -Wname=axiom -fao
/home/lehner/usr/local/src/axiom/fricas-gcl/int/aldor/ap/FS.ap
"/home/lehner/usr/local/src/axiom/fricas-gcl/int/aldor/ap/FS.ap", line 355:


(|Apply| |Polynomial|
......................................................^
[L355 C55] #9 (Error) No one possible return type satisfies the context type.
These possible return types were rejected:
-- PolynomialCategory(#1, IndexedExponents(Symbol), Symbol) with ...
The context requires an expression of type with
%%: PolynomialCategory(Fraction....

...

regards,
Franz

mkaldor.sh

Waldek Hebisch

unread,
Jan 17, 2008, 12:26:50 PM1/17/08
to fricas...@googlegroups.com
Martin Rubey wrote:
> They should definitively replace the old instructions on the wiki. In fact, I
> think that both src_aldor2.tgz and your script should go into the fricas
> contrib directory, say, contrib/aldor. Maybe you could polish your script so
> that it doesn't use lndir, detects ARCH automatically and does not depend on
> the fricas source directory any longer.
>

I am affraid that we are not allowed to put src_aldor2.tgz on
sourceforge. From SourceForge Terms of Use:

8. LICENSING AND OTHER TERMS APPLYING TO CODE AND OTHER CONTENT POSTED
ON SOURCEFORGE.NET

SourceForge.net fosters software development and content creation
under Open-Source Initiative ("OSI")-approved licenses or other
arrangements relating to software and/or content development that may
be approved by COMPANY. For more information about OSI, and
OSI-approved licenses, visit www.opensource.org.

Use, reproduction, modification, and ownership of intellectual
property rights to data stored in CVS, SVN or as a file release and
posted by any user on SourceForge.net ("Source Code") shall be
governed by and subject to the OSI-approved license, or to such other
licensing arrangements approved by COMPANY, applicable to such Source
Code.


AFAICS src_aldor2.tgz contains parts of Aldor runtime. This means that
Aldor licence (which I belive is not OSI compliant) applies...

Similarly, if we want FriCAS to be main or contrib part of Debian
we can not include Aldor files in the source tarball.

So, before the build scripts go into contrib we must separate added
parts (which can go in) from Aldor part. And we need to teach the
scripts (or the user) where to find needed Aldor parts -- it seems
that 'lib/libax0' in Aldor installation contains the needed parts.

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

Martin Rubey

unread,
Jan 17, 2008, 1:52:48 PM1/17/08
to Stephen Watt, Mike Dewar, fricas...@googlegroups.com, peter.b...@ntlworld.com
Dear Mike, Dear Stephen,

we would like to provide the aldor interface with axiom/fricas. However, as
you can see below, parts of it violate at least debian rules. Is there a
chance of having these parts of aldor under the modified BSD? As far as I can
see, the files in question are

attrib.as.head attrib.as axextend.as axlit.as minimach.as stub.as

Many thanks,

Martin

Martin Rubey

unread,
Jan 21, 2008, 11:06:50 AM1/21/08
to fricas...@googlegroups.com, Peter Broadbery
Dear Peter, dear Franz,

could the two of you prepare a patch that can go into the friCAS distribution?
Neither Stephen Watt, nor Mike Dewar replied, so I guess we really have to
fetch the files in question (those with NAG copyright)

attrib.as:6:---- Copyright The Numerical Algorithms Group Limited 1991, 1992, 1993, 1994.
axextend.as:6:---- Copyright The Numerical Algorithms Group Limited 1991, 1992, 1993, 1994.
axlit.as:7:---- Copyright The Numerical Algorithms Group Limited 1991, 1992, 1993, 1994.
lang.as:6:---- Copyright (c) 1990-2007 Aldor Software Organization Ltd (Aldor.org).
stub.as.safe:6:---- Copyright The Numerical Algorithms Group Limited 1991, 1992, 1993, 1994.

from somewhere else. Are they in the aldor binary distribution, maybe?

It will be quite sufficient to tell people where to get them from.

I'm really happy that you are working on this - I do depend a lot on the aldor
interface!

Many thanks,

Martin

Ralf Hemmecke

unread,
Jan 21, 2008, 11:57:31 AM1/21/08
to fricas...@googlegroups.com
On 01/21/2008 05:06 PM, Martin Rubey wrote:
> Dear Peter, dear Franz,
>
> could the two of you prepare a patch that can go into the friCAS distribution?
> Neither Stephen Watt, nor Mike Dewar replied, so I guess we really have to
> fetch the files in question (those with NAG copyright)
>
> attrib.as:6:---- Copyright The Numerical Algorithms Group Limited 1991, 1992, 1993, 1994.
> axextend.as:6:---- Copyright The Numerical Algorithms Group Limited 1991, 1992, 1993, 1994.
> axlit.as:7:---- Copyright The Numerical Algorithms Group Limited 1991, 1992, 1993, 1994.
> lang.as:6:---- Copyright (c) 1990-2007 Aldor Software Organization Ltd (Aldor.org).
> stub.as.safe:6:---- Copyright The Numerical Algorithms Group Limited 1991, 1992, 1993, 1994.
>
> from somewhere else. Are they in the aldor binary distribution, maybe?

What about putting

#----------------------
libax0:
svn co https://aquarium.aldor.csd.uwo.ca/svn/trunk/aldor/lib/libax0 libax0

libax0/lang.as: libax0
svn cat
https://aquarium.aldor.csd.uwo.ca/svn/trunk/aldor/aldor/lib/libfoamlib/lang.as
> libax0/lang.as
#----------------------

into the Makefile?

If the person has SVN and an internet connection there would be no need
to type anything.

Ralf

Martin Rubey

unread,
Jan 21, 2008, 12:51:07 PM1/21/08
to fricas...@googlegroups.com
Ralf Hemmecke <ra...@hemmecke.de> writes:

> > from somewhere else. Are they in the aldor binary distribution, maybe?

> What about putting
>
> #----------------------
> libax0:
> svn co https://aquarium.aldor.csd.uwo.ca/svn/trunk/aldor/lib/libax0 libax0
>
> libax0/lang.as: libax0
> svn cat
> https://aquarium.aldor.csd.uwo.ca/svn/trunk/aldor/aldor/lib/libfoamlib/lang.as
> > libax0/lang.as
> #----------------------
>
> into the Makefile?
>
> If the person has SVN and an internet connection there would be no need to
> type anything.

OK for me. Although, in case these files are even in the binary distribution
of Aldor (I do not know), I'd rather get them from there (ALDORROOT should be
set, I suppose).

Martin

Ralf Hemmecke

unread,
Jan 22, 2008, 4:56:21 AM1/22/08
to fricas...@googlegroups.com, Stephen Watt

In fact, one could do a similar thing for all of Aldor. At build-time,
you fetch the aldor-trunk from the above repository, make a reasonable
modification (by a script or even leave it as it is and call MAKE with
appropriate variable assignments on the command line) to
Makefile.globals and build the aldor compiler + its libraries.

Then you know where the above files are in your build tree and can use
them from there.

In fact, one should make the aldor connection in such a way that one
would have to give --with-aldor at configure time. "configure" would
have to figure out whether an aldor executable is already installed
(probably by looking whether ALDORROOT is set and whether aldor is in
the PATH). According to that Fricas' make should either fetch the whole
of aldor-trunk and build aldor inside the fricas build dir or it gets
only the files I mentioned in my previous mail. Then Peter Broadbery's
routines should be compiled.

Unfortunately, Aldor connection would only be available if somebody
compiles Fricas herself. A binary version would have to be under APL2
(or one would have to ask Stephen Watt whether such a combination really
falls under an addition/improvement of Aldor). In fact, putting
Fricas+Aldor under APL2 does not hurt, since Fricas (without Aldor would
still be under mBSD).

Another option would be to contribute to aldor.org a library libaxx0.al
(under APL2) which contains the copyrighted .as files in Broadbery's
src_aldor3.tgz and which should be distributed together with the next
Aldor release.

Then one would only have to check whether aldor is already installed and
simply build libaxiom.al on top of libaxx0.al

In fact, with the current licensing issues, I would prefer the last
solution. That make a clear cut between aldor and fricas. The only
question is whether aldor.org would distribute such a library and when
their next release is.

Comments?

Ralf


Martin Rubey

unread,
Jan 22, 2008, 7:11:37 AM1/22/08
to fricas...@googlegroups.com, Stephen Watt
Ralf Hemmecke <ra...@hemmecke.de> writes:


> Another option would be to contribute to aldor.org a library libaxx0.al
> (under APL2) which contains the copyrighted .as files in Broadbery's
> src_aldor3.tgz and which should be distributed together with the next Aldor
> release.
>
> Then one would only have to check whether aldor is already installed and
> simply build libaxiom.al on top of libaxx0.al

I like this one best.

Martin

Bill Page

unread,
Oct 19, 2009, 6:42:14 PM10/19/09
to fricas-devel
For some reason this historically important email does not appear in
the fricas-devel archives (nor open-axiom-devel or anywhere else on
the Web, I think). Perhaps Peter was not subscribed to either group at
the time he sent the message so only Martin and I received it -
although it was clearly intended to appear here. Below is a copy for
our reference from my own email archive.

See also the thread which followed this email:

http://groups.google.com/group/fricas-devel/browse_thread/thread/e618d8d7274282ae/bea8a95ec3cb73be#bea8a95ec3cb73be

As you can see Peter says very little about the patch, only: "Against


aldor-1.1 you'll need a small patch to the way axiom computes hash

codes."

---------- Forwarded message ----------
From: Peter Broadbery <p_bro...@hotmail.com>
Date: Fri, Nov 9, 2007 at 4:45 PM
Subject: RE: Building the Aldor interface on FriCAS or OpenAxiom
To: Bill Page <bill...@newsynthesis.org>, Martin Rubey
<martin...@univie.ac.at>
Cc: fricas...@googlegroups.com, open-axi...@lists.sourceforge.net

>On 08 Nov 2007 14:48:12 +0100, Martin Rubey wrote:

> "Bill Page" writes:
>>> Have you been able to compile the Axiom/Aldor interface for a recent
>>> version of FriCAS or OpenAxiom? As you know the instructions here:
>>
> No, so far I have only a build with the very last wh-sandbox. I will try it as
>> soon as I can. But really, it's Peter who is the boss of the axiom-aldor
>> interaction.
>>
>
>Indeed! :-)

Um, I'll not be the boss of anything.  I just hack stuff sometimes...

From the output
`/home/page/fricas-test/src/aldor/as//home/page/fricas-test/src/aldor/aldor/ap/axlit.as',

looks like you've got a full path where a relative one was expected.

Difficult to say what exactly, as I don't have that code to hand any
more (I decided that the way it was put together was a bit too mad, so
moved the logic away from the makefiles & into the java sorting code).
 Will release soon..  Against aldor-1.1 you'll need a small patch to


the way axiom computes hash codes (I couldn't have got this without
the source code, by the ways..):

Peter


hashType(type, percentHash) ==
       SYMBOLP type  =>
          type = '$ => percentHash
          type = "%" => percentHash
          hashString SYMBOL_-NAME type
       STRINGP type  => hashCombine(hashString type,
                                       hashString('"Enumeration"))
       type is ['QUOTE, val] => hashType(val, percentHash)
       type is [dom] => hashString SYMBOL_-NAME dom
       type is ['_:, ., type2] => hashType(type2, percentHash)
       isDomain type => getDomainHash type
       [op, :args] := type
       hash := hashString SYMBOL_-NAME op
       op = 'Mapping =>
               hash := hashString '"->"
               [retType, :mapArgs] := args
               for arg in mapArgs repeat

                       hash := hashCombine(hashType(arg, percentHash), hash)
               retCode := hashType(retType, percentHash)
               EQL(retCode, $VoidHash) => hash

               hashCombine(retCode, hashCombine(32236, hash))
       op = 'Enumeration =>
               for arg in args repeat
                       hash := hashCombine(hashString(STRING arg), hash)

               hash
       op in $DomainsWithoutLisplibs =>


               for arg in args repeat

                       hash := hashCombine(hashType(arg, percentHash), hash)
               hash

       cmm :=   CDDAR getConstructorModemap(op)
       cosig := CDR   GETDATABASE(op, 'COSIG)
       for arg in args for c in cosig for ct in cmm repeat
               if c then

                       hash := hashCombine(hashType(arg, percentHash), hash)

               else
                       hash := hashCombine(7, hash)
--           !!!   If/when asharp hashes values using their type, use instead
--                      ctt := EQSUBSTLIST(args, $FormalMapVariableList, ct)
--                      hash := hashCombine(hashType(ctt, percentHash), hash)


       hash
_________________________________________________________________
The next generation of MSN Hotmail has arrived - Windows Live Hotmail
http://www.newhotmail.co.uk

Reply all
Reply to author
Forward
0 new messages