Building the Aldor interface on FriCAS or OpenAxiom
Bill Page
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
> 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
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
> "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
> 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
>
> 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
> 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
> 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
Martin
Bill Page
>
> 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
> 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
> 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
>
> >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.
> >
> >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
> >> 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
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
[...]
| 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
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
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
>
> 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
>
> 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
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
>
> 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
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
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
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
> 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
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
> 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
Waldek Hebisch
> 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
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
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
> 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
> > 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
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
> 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
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:
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