aldor interface
Martin Rubey
please try the following:
1) get the very latest FriCAS (revision 283) with
svn co https://fricas.svn.sourceforge.net/svnroot/fricas/trunk fricas
and build it with gcl using the instructions in INSTALL. PLEASE build it in
a directory different from fricas, eg. fricas-build
if that worked (after some hours):
2) unzip and untar the attached file aldor4.tgz in the src directory of fricas,
so that you then have a directory
fricas/src/aldor
with some files in it.
Ralf Hemmecke
> Dear Thomas,
>
> please try the following:
>
> 1) get the very latest FriCAS (revision 283) with
>
> svn co https://fricas.svn.sourceforge.net/svnroot/fricas/trunk fricas
>
>
>
>
> and build it with gcl using the instructions in INSTALL. PLEASE
> build it in a directory different from fricas, eg. fricas-build
Martin, why don't you more clearly say what to do here?
Thomas, you should just create any directory you like for where the
build should go, for example, say
cd $HOME
# anything we do will be below the following directory
FRICASDIR=$HOME/fricas
mkdir $FRICASDIR
cd $FRICASDIR
svn co https://fricas.svn.sourceforge.net/svnroot/fricas/trunk fricas-src
# Now you have a directory $FRICASDIR/fricas-src
mkdir $FRICASDIR/fricas-build
cd $FRICASDIR/fricas-build
# Build fricas in $FRICASDIR/fricas-build with installation
# target $FRICASDIR/fricas
$FRICASDIR/fricas-src/configure --prefix=$FRICASDIR
make
> if that worked (after some hours):
Hmm, my laptop takes about 1.5 hours.
> 2) unzip and untar the attached file aldor4.tgz in the src directory
> of fricas, so that you then have a directory
>
> fricas/src/aldor
>
> with some files in it.
Martin, could you be a bit more precise here?
With the directories above, should I put it into $FRICASDIR/fricas-src
or $FRICASDIR/fricas-build?
> 3) put the following text into a file makeAldor in the fricas-build
> directory you created in step 1 and make it executable. Possibly
> you'll have to adapt ARCH and ALDOR_SRC. Also ALDORROOT should be
> set, see the README of your aldor distribution.
Should I put it into $FRICASDIR/fricas-build? Or some subdir?
> 4) execute makeAldor in the build directory, i.e., fricas-build or
> so.
> Please don't hesitate to ask. Ideally, keep the makelogs, i.e,
> execute makeAldor using
> nohup ./makeAldor > mkaldorlog 2>&1
>
> 5) make install.
Ralf
Martin Rubey
> > 2) unzip and untar the attached file aldor4.tgz in the src directory
> > of fricas, so that you then have a directory
> >
> > fricas/src/aldor
> >
> > with some files in it.
>
> Martin, could you be a bit more precise here?
> With the directories above, should I put it into $FRICASDIR/fricas-src
> or $FRICASDIR/fricas-build?
cd fricas-src/src/
tar -xzf aldor4.tgz
> > 3) put the following text into a file makeAldor in the fricas-build
> > directory you created in step 1 and make it executable. Possibly
> > you'll have to adapt ARCH and ALDOR_SRC. Also ALDORROOT should be
> > set, see the README of your aldor distribution.
>
> Should I put it into $FRICASDIR/fricas-build? Or some subdir?
$FRICASDIR/fricas-build
> > 4) execute makeAldor in the build directory, i.e., fricas-build or
> > so.
>
> > Please don't hesitate to ask. Ideally, keep the makelogs, i.e,
> > execute makeAldor using
>
> > nohup ./makeAldor > mkaldorlog 2>&1
> >
> > 5) make install.
Hope that helps,
Martin
Ralf Hemmecke
>> With the directories above, should I put it into $FRICASDIR/fricas-src
>> or $FRICASDIR/fricas-build?
>
> cd fricas-src/src/
> tar -xzf aldor4.tgz
I have said
cd $FRICASDIR/fricas-build/src
tar -xzf aldor4.tgz
My $FRICASDIR/fricas-build/mkAldor is:
# makeAldor
###################################################################
# the name of the svn repository should be fricas
# this script should be started in the build directory
ARCH=i686-pc-linux
BASE=$(pwd)
FRICASDIR=/home/hemmecke/scratch/fricas
ALDOR_SRC=$FRICASDIR/fricas-build/src/aldor
export AXIOM=$BASE/target/$ARCH
# export ALDORROOT=/usr/local/aldor/linux/1.0.2
cd src/aldor
make ARCH=$ARCH BASE=$BASE ALDOR_SRC=$ALDOR_SRC
###############################################################################
Unfortunately
sh mkAldor 2>&1 | tee mkaldor.log
did not succeed. See
http://www.risc.uni-linz.ac.at/people/hemmecke/mkaldor.log.gz .
Ralf
Martin Rubey
-------------------------------------------------------------------------------
ar: creating /home/hemmecke/scratch/fricas/fricas-build/src/aldor/tmp/libaxiom_FS.al
(Message Preview)
"/home/hemmecke/scratch/fricas/fricas-build/src/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
if (#1 has Algebra(Fraction(Integer))) then integrate: (%,
Symbol) -> %
else
The context requires an expression of type with
-------------------------------------------------------------------------------
which is very bad news - it's the type of message I got when I didn't uncomment
#blacklisted_domains := FRMOD IDECOMP RIDIST ODERTRIC QALGSET2
however, FS should not be blacklisted, I'd say. On the other hand, you could
just try.
What aldor are you using? You might want to try with 1.0.3. There is also a
patch of Peter somewhere, that you might want to apply to your aldor sources,
with which it should not be necessary to blacklist anymore.
Martin
http://www.mail-archive.com/axiom-developer%40nongnu.org/msg13003.html
Thomas Feulner
On 21 Mai, 06:58, Martin Rubey <martin.ru...@univie.ac.at> wrote:
> I see the following error:
>
> -------------------------------------------------------------------------------
> ar: creating /home/hemmecke/scratch/fricas/fricas-build/src/aldor/tmp/libaxiom_FS.al
> (Message Preview)
> "/home/hemmecke/scratch/fricas/fricas-build/src/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
> if (#1 has Algebra(Fraction(Integer))) then integrate: (%,
> Symbol) -> %
> else
> The context requires an expression of type with
>
> -------------------------------------------------------------------------------
makeAldor.
> which is very bad news - it's the type of message I got when I didn't uncomment
>
> #blacklisted_domains := FRMOD IDECOMP RIDIST ODERTRIC QALGSET2
>
> however, FS should not be blacklisted, I'd say. On the other hand, you could
> just try.
>
> What aldor are you using? You might want to try with 1.0.3. There is also a
> patch of Peter somewhere, that you might want to apply to your aldor sources,
> with which it should not be necessary to blacklist anymore.
>
it?
Just another question: I have used gcl 2.6.7. The FriCAS FAQ 7 tells
me not to do so, might there be a problem? (FriCAS seems to run well).
Thomas
Martin Rubey
http://www.aldor.org/downl.html
and choose the first option "Linux version 1.0.3 (glibc2.3)". However, I hope
that somebody (Peter) is able to fix it.
> Just another question: I have used gcl 2.6.7. The FriCAS FAQ 7 tells
> me not to do so, might there be a problem? (FriCAS seems to run well).
I think for FriCAS it's ok. The FAQ you cite is in fact below the lines
----------------------------------------------------------------------
Below is old Axiom FAQ
which is kept in case something goes wrong, I think. I guess we should delete
those items that do not apply anymore.
Martin
Ralf Hemmecke
> My Aldor version is 1.1.0. You proposed to try 1.0.3, where do I get
> it?
You should not go back to 1.0.3.
Ralf
Martin Rubey
did you try? Do you get the same error message with 1.0.3?
Martin
Ralf Hemmecke
why should I prefer 1.0.3 over a self-build Aldor from SVN-HEAD (which
is an epsilon bigger than 1.1.0?
Ralf
Ralf Hemmecke
> me not to do so, might there be a problem? (FriCAS seems to run well).
That question should be best answered by Waldek, but for the connection
to Aldor, i.e., generation of libaxiom.al, it does not matter (much)
which lisp version you have. Aldor is not using Lisp.
Ralf
Ralf Hemmecke
OK, if you like, I'll try that in the weekend.
Ralf
Bill Page
Isn't 1.0.3 the newest release of Aldor?
Regards,
Bill Page.
Bill Page
What is Aldor version 1.1.0?
Waldek Hebisch
> Thomas Feulner <thomas....@uni-bayreuth.de> writes:
> > Just another question: I have used gcl 2.6.7. The FriCAS FAQ 7 tells
> > me not to do so, might there be a problem? (FriCAS seems to run well).
>
> I think for FriCAS it's ok. The FAQ you cite is in fact below the lines
>
> ----------------------------------------------------------------------
>
> Below is old Axiom FAQ
>
> which is kept in case something goes wrong, I think. I guess we should delete
> those items that do not apply anymore.
>
This FAQ item is wrong now. In fact, any gcl version earlier than 2.6.7
will _not_ work. INSTALL file constains reasonably up-to-date
information about supported Lisps.
More generally, more than half of the old FAQ is wrong or irrelevant
now. Few entires are genuinely useful, few while inaccurate may
give useful hints.
I have kept the old FAQ mostly to avoid losing information: while
most entries give no information about FriCAS (after all, this is
_Axiom_ FAQ) there is information about OS or Lisp quirks which may
be still useful.
I see to possibilities:
1) Add clearer disclaimer, for example:
Below is old Axiom FAQ -- mostly obsolete.
2) Delete most of the entries and update a few remaining ones.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Bill Page
>
> I have kept the old FAQ mostly to avoid losing information: while
> most entries give no information about FriCAS (after all, this is
> _Axiom_ FAQ) there is information about OS or Lisp quirks which
> may be still useful.
>
> I see to possibilities:
>
> 1) Add clearer disclaimer, for example:
>
> Below is old Axiom FAQ -- mostly obsolete.
>
> 2) Delete most of the entries and update a few remaining ones.
>
I think 2) is best. The association of FriCAS with "old Axiom" is
becoming less relevant.
Regards,
Bill Page.
Ralf Hemmecke
Ralf Hemmecke
> Typo:
>
> What is Aldor version 1.1.0?
https://aquarium.aldor.csd.uwo.ca/svn/trunk
in revision something between 1 and 15.
But who really cares, take revison 23 (HEAD).
Ralf
Bill Page
Oh yes, thanks. I am sometimes a little confused over Aldor release
numbers... sorry.
So I agree with you: What is the point of linking an older binary
version of Aldor released prior to it's availability as "open source"
to FriCAS? At this stage I think it is important to build both Aldor
and FriCAS from source so that we have an opportunity to report and
fix problems. Reports of problems with older versions of Aldor are
unlikely to be resolved.
Regards,
Bill Page.
Thomas Feulner
On 21 Mai, 10:01, Martin Rubey <martin.ru...@univie.ac.at> wrote:
Also my original problem (installing the libcombinatd.a) is possible.
BUT calling make test and make check leads to an error. Ralf, is it
just the ExtIO and AldorUnit problem, you wrote in your first Email?
Thomas
Martin Rubey
> I tried it [Aldor 1.0.3], and I think everything is ok *a great success*!
> Also my original problem (installing the libcombinatd.a) is possible.
Super.
> BUT calling make test and make check leads to an error.
What error?
Now, the next thing to do to get species in axiom/FriCAS, is to
cd combinat/branches/iso-experiment/combinat
make VARIANTSTOBUILD=axiom
cd lib
for f in $(ar t libcombinatax.al); do echo ")lib $f" >> combinat.input; done
Then start axiom,
)cd ~/combinat/branches/iso-experiment/combinat/src
)re ../lib/combinat.input
Now,
lab: SetSpecies ACINT := set [i::ACINT for i in 1..4]
structures(lab)$Partition ACINT
should give you the set partitions of {1,2,3,4}. Otherwise pleas post output.
Martin
Ralf Hemmecke
> BUT calling make test and make check leads to an error. Ralf, is it
> just the ExtIO and AldorUnit problem, you wrote in your first Email?
Yes. I don't think that you need to install it now, since you will
probably not yet develop for Aldor-Combinat.
If, however, you really, really want it, then you should say
svn export svn://svn.risc.uni-linz.ac.at/caistlei/extio
and you will have the latest version. Christian has already fixed that
problem in the svn repository.
Ralf
Thomas Feulner
I still have got some problems with the aldor interface. Last week I did not
test the fact.as file. See the error.log for my actual problem.
Also I am a bit confused by step 5) of your description.
make install creates an additional
folder /users/tfeulner/programme/fricas/lib/fricas/target/
but the folder algebra does not contain the libaxiom.al
In contrast the folder
/users/tfeulner/programme/fricas/lib/fricas/target/
built in the previous steps does contain it.
Which fricas binary should I use? There is even one more
in /users/tfeulner/programme/fricas/bin
Thomas
Ralf Hemmecke
It looks as if there are some strange characters in the input that the
aldor compiler doesn't like. That should have nothing to do with fricas
(my guess).
Ralf
Thomas Feulner
bad characters in the input file.
Last Friday I wrote, that installing the libcombinatd.a was possible, too.
Now I'm confused by the appended error message, which occurs if I call make
VARIANTSTOBUILD=axiom
Thomas
Ralf Hemmecke
Nothing to worry.
make VARIANTSTOBUILD=debug
should still work.
What you experience is most probably a problem with the place where
libaxiom.al lives on your computer. You find the flags under
======= Building libcombinatax.al with FLAGS =======
-Y /users/tfeulner/programme/combinat/combinat/src -Y . -Y
/users/tfeulner/programme/aldor1.0.3/aldor/linux/1.0.3/lib -I
/users/tfeulner/programme/combinat/combinat/include -I
/users/tfeulner/programme/aldor1.0.3/aldor/linux/1.0.3/include
-lcombinatax -dAxiom -q1 -Fasy -Flsp -laxiom -Mno-ALDOR_W_WillObsolete
-Y
/users/tfeulner/programme/fricas/fricas-build/target/x86_64-suse-linux/algebra
-fao -dMacrosCombinat -Mno-mactext -M2 -Mno-abbrev
======= Building libcombinatax.al end FLAGS =======
If you don't have libaxiom.al anywhere in the directories specified by
-Y and axiom.as anywhere in a directory specified by -I, then the aldor
compiler cannot find it.
You seem to have axiom.as already in the right place.
My idea was that libaxiom would live in $ALDORROOT/lib. If you move or
link it there, I guess, everything will workout fine.
As I said, that is only a guess. The compiler should actually find what
is meant by that. If you still encounter problems tell me again.
Sorry, for the inconvenience. I am going to improve the aldor connection
of fricas in the next few days and I will probably update also
aldor-combinat to better integrate into fricas.
Stay tuned.
Thomas Feulner
I won't capitulate.
>
> make VARIANTSTOBUILD=debug
>
> should still work.
Yes, it does.
> What you experience is most probably a problem with the place where
> libaxiom.al lives on your computer. You find the flags under
>
> ======= Building libcombinatax.al with FLAGS =======
> -Y /users/tfeulner/programme/combinat/combinat/src -Y . -Y
> /users/tfeulner/programme/aldor1.0.3/aldor/linux/1.0.3/lib -I
> /users/tfeulner/programme/combinat/combinat/include -I
> /users/tfeulner/programme/aldor1.0.3/aldor/linux/1.0.3/include
> -lcombinatax -dAxiom -q1 -Fasy -Flsp -laxiom -Mno-ALDOR_W_WillObsolete
> -Y
> /users/tfeulner/programme/fricas/fricas-build/target/x86_64-suse-linux/alge
>bra -fao -dMacrosCombinat -Mno-mactext -M2 -Mno-abbrev
> ======= Building libcombinatax.al end FLAGS =======
> If you don't have libaxiom.al anywhere in the directories specified by
> -Y and axiom.as anywhere in a directory specified by -I, then the aldor
> compiler cannot find it.
>
> You seem to have axiom.as already in the right place.
>
> My idea was that libaxiom would live in $ALDORROOT/lib. If you move or
> link it there, I guess, everything will workout fine.
Sorry, but this does not work. I moved the libaxiom.al to $ALDORROOT/lib
which lives in /users/tfeulner/programme/fricas/fricas-build/src/aldor/al/,
but there is still the same error message,
>
> As I said, that is only a guess. The compiler should actually find what
> is meant by that. If you still encounter problems tell me again.
>
> Sorry, for the inconvenience. I am going to improve the aldor connection
> of fricas in the next few days and I will probably update also
> aldor-combinat to better integrate into fricas.
>
> Stay tuned.
Thomas
Ralf Hemmecke
>> -Y /users/tfeulner/programme/combinat/combinat/src -Y . -Y
>> /users/tfeulner/programme/aldor1.0.3/aldor/linux/1.0.3/lib -I
>> /users/tfeulner/programme/combinat/combinat/include -I
>> /users/tfeulner/programme/aldor1.0.3/aldor/linux/1.0.3/include
>> -lcombinatax -dAxiom -q1 -Fasy -Flsp -laxiom -Mno-ALDOR_W_WillObsolete
>> -Y
>> /users/tfeulner/programme/fricas/fricas-build/target/x86_64-suse-linux/alge
>> bra -fao -dMacrosCombinat -Mno-mactext -M2 -Mno-abbrev
>> ======= Building libcombinatax.al end FLAGS =======
>> My idea was that libaxiom would live in $ALDORROOT/lib. If you move or
>> link it there, I guess, everything will workout fine.
> Sorry, but this does not work. I moved the libaxiom.al to $ALDORROOT/lib
> which lives in /users/tfeulner/programme/fricas/fricas-build/src/aldor/al/,
> but there is still the same error message,
Ehm, I would have thought that $ALDORROOT in your case points to where
the compiler lives and the lib subdir is where the compiler expects its
libraries. From what I see above most probably, you most probably should say
mv /users/tfeulner/programme/fricas/fricas-build/src/aldor/al/libaxiom.al
/users/tfeulner/programme/aldor1.0.3/aldor/linux/1.0.3/lib
(all one line)
What is the error message then?
Ralf
Thomas Feulner
> >> ======= Building libcombinatax.al with FLAGS =======
> >> -Y /users/tfeulner/programme/combinat/combinat/src -Y . -Y
> >> /users/tfeulner/programme/aldor1.0.3/aldor/linux/1.0.3/lib -I
> >> /users/tfeulner/programme/combinat/combinat/include -I
> >> /users/tfeulner/programme/aldor1.0.3/aldor/linux/1.0.3/include
> >> -lcombinatax -dAxiom -q1 -Fasy -Flsp -laxiom -Mno-ALDOR_W_WillObsolete
> >> -Y
> >> /users/tfeulner/programme/fricas/fricas-build/target/x86_64-suse-linux/a
> >> ======= Building libcombinatax.al end FLAGS =======
> >>
> >> My idea was that libaxiom would live in $ALDORROOT/lib. If you move or
> >> link it there, I guess, everything will workout fine.
> >
> > Sorry, but this does not work. I moved the libaxiom.al to $ALDORROOT/lib
> > which lives in
> > /users/tfeulner/programme/fricas/fricas-build/src/aldor/al/, but there is
> > still the same error message,
>
> Ehm, I would have thought that $ALDORROOT in your case points to where
> the compiler lives and the lib subdir is where the compiler expects its
> libraries. From what I see above most probably, you most probably should
> say
ALDORROOT points to "/users/tfeulner/programme/aldor1.0.3/aldor/linux/1.0.3"
> mv /users/tfeulner/programme/fricas/fricas-build/src/aldor/al/libaxiom.al
> /users/tfeulner/programme/aldor1.0.3/aldor/linux/1.0.3/lib
done.
>
> (all one line)
>
> What is the error message then?
This is my new (old?) error message.
> Ralf
Ralf Hemmecke
that is a strange problem
thread:
http://groups.google.com/group/fricas-devel/browse_thread/thread/4edc7d9a8dfd0be
> This is my new (old?) error message.
Hmm, now I am a bit helpless.
Oh... I just realise that with aldor 1.0.3 I see the same error.
Interestingly enough, I am able to compile and run aaa.as via
)co aaa.as
aaa()
in FriCAS.
---BEGIN aaa.as
#include "axiom"
import from Integer, UniversalSegment Integer;
AAA: with {
aaa: () -> Integer;
} == add {
aaa(): Integer == {
for i in 1.. repeat if i > 9 then break;
1
}
}
---END aaa.as
But compiling csaxcompat.as yields the same error:
"/home/hemmecke/scratch/aldor/csaxcompat.as", line 86:
for i: Integer in 1..(#a::Integer) repeat
yield((a.i)::ACCharacter);
...........................^
[L86 C28] #2 (Error) There are no suitable meanings for the operator `..'.
Then interestingly, I could compile (parts of) the file (see attachment
for the shortened version) with
generator(a: %): Generator ACCharacter == generate {
import from Integer, NNI, ACCharacter, UniversalSegment Integer;
len: NNI := #a;
l: Integer := len::Integer;
us: UniversalSegment Integer := (1..l)$UniversalSegment(Integer);
for i: Integer in us repeat yield((a.i)::ACCharacter);
}
listOfChars(a: %): List ACCharacter == [generator a];
by calling
)co csaxcompat.as
(1) -> acs: ACString := "abcde"
(1) "abcde"
Type: ACString
(2) -> listOfChars acs
(2) [a,b,c,d,e]
Type: List ACCharacter
So that seems to work.
Anyway, I have the big suspicion that something is wrong with the
libaxiom.al that is generated in the way Martin described it.
I don't really want to write "(1..l)$UniversalSegment(Integer)" each
time I use the .. operator. But I have no idea why aldor 1.0.3 is not
able to find the function .. even if I explicitly import from
UniversalSegment(Integer) right before .. appears. Very strange!
Ralf
Martin Rubey
> libaxiom.al that is generated in the way Martin described it.
> I don't really want to write "(1..l)$UniversalSegment(Integer)" each
> time I use the .. operator. But I have no idea why aldor 1.0.3 is not
> able to find the function .. even if I explicitly import from
> UniversalSegment(Integer) right before .. appears. Very strange!
Hm, how can I find out which libaxiom is used? I renamed the libaxiom in
~/lib/fricas/target/ixxx/algebra, and make didn't complain...
Martin
Ralf Hemmecke
In fact, when you compile aldor-combinat, you see something like
======= Building libcombinatax.al with FLAGS =======
-Y /users/tfeulner/programme/combinat/combinat/src -Y . -Y
/users/tfeulner/programme/aldor1.0.3/aldor/linux/1.0.3/lib -I
/users/tfeulner/programme/combinat/combinat/include -I
/users/tfeulner/programme/aldor1.0.3/aldor/linux/1.0.3/include
-lcombinatax -dAxiom -q1 -Fasy -Flsp -laxiom -Mno-ALDOR_W_WillObsolete
-Y
/users/tfeulner/programme/fricas/fricas-build/target/x86_64-suse-linux/alge
bra -fao -dMacrosCombinat -Mno-mactext -M2 -Mno-abbrev
======= Building libcombinatax.al end FLAGS =======
Try in any of the directories specified by -Y. The first hit counts.
Ralf
Martin Rubey
> Check whether you have something in $ALDORROOT/lib.
>
> In fact, when you compile aldor-combinat, you see something like
>
> ======= Building libcombinatax.al with FLAGS =======
> -Y /users/tfeulner/programme/combinat/combinat/src -Y . -Y
> /users/tfeulner/programme/aldor1.0.3/aldor/linux/1.0.3/lib -I
> /users/tfeulner/programme/combinat/combinat/include -I
> /users/tfeulner/programme/aldor1.0.3/aldor/linux/1.0.3/include
> -lcombinatax -dAxiom -q1 -Fasy -Flsp -laxiom -Mno-ALDOR_W_WillObsolete
> -Y
> /users/tfeulner/programme/fricas/fricas-build/target/x86_64-suse-linux/alge
> bra -fao -dMacrosCombinat -Mno-mactext -M2 -Mno-abbrev
> ======= Building libcombinatax.al end FLAGS =======
>
> Try in any of the directories specified by -Y. The first hit counts.
OK, I just saw that my bashrc still exports AXIOM, which points to an ancient
one. And indeed, it seems that
libaxiom built with srcaldor2 works
libaxiom built with srcaldor3/4 does not work.
(I cannot be completely sure, but I checked several trees built with srcaldor2
and several built with srcaldor3/4. I cannot be sure, because all these trees
also correspond to different revisions of fricas.)
Maybe the best thing for the moment is to follow the instructions in my old
makeAldor, attached below.
WARNING: src_aldor2.tgz needs java, and does not work with GNU Make 3.81beta4
(make 3.80 is OK, for example)
I wonder how we could compare.
# makeAldor for src_aldor2.tgz.
# the name of the svn repository should be fricas
# src_aldor2.tgz is expected in the directory above fricas and fricas-build
# when I download aldor2.tgz, it is actually not gzipped,
# so I say "tar -xf" instead of "tar -xzf"
ARCH=i686-pc-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/src/scripts/ .
tar xf ../../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; for f in ../../src/algebra/*; do ln -s $f; done)
make
Ralf Hemmecke
> and several built with srcaldor3/4. I cannot be sure, because all these trees
> also correspond to different revisions of fricas.)
> Maybe the best thing for the moment is to follow the instructions in my old
> makeAldor, attached below.
I don't want, since I'd like to make an integration of srcaldor4 into
fricas, and I am already quite far. But it seems that there is some
difference in the build to srcaldor2.
Does, by accident, somebody have the full build directory (for
srcaldor2) available.
That directory should contain subdirs
al ao ap deps gendeps ...
and all the generated files of a successful build. In particular
something like domains.mk, libaxiom.lst.
If I could download that from mathaction, that would greatly help me to
check the differences. Otherwise I would have to regenerate myself. :-(
Ralf
Ralf Hemmecke
could you more explicitly say something about your directory layout.
You seem to have something like
SOMEDIR/
fricas/
configure.ac
configure
config/
contrib/
license/
Makefile.in
...
fricas-build
Makefile
config.log
src/
aldor/
Or what is it to make the script below work?
Could you send the first few lines of config.log?
Thank you
Ralf
Martin Rubey
> Martin,
>
> could you more explicitly say something about your directory layout.
>
> You seem to have something like
>
> SOMEDIR/
> fricas/
> configure.ac
> configure
> config/
> contrib/
> license/
> Makefile.in
> ...
> fricas-build
> Makefile
> config.log
> src/
> aldor/
>
>
> Or what is it to make the script below work?
fricas is just svn checkout
fricas-build is obtained by
mkdir fricas-build # assuming that fricas and fricas-build share parent dir
../fricas/configue
make
(i.e., just as above, except that src/aldor is missing.
src_aldor2.tgz is assumed to be in the parent-dir of fricas and fricas-build.
> Could you send the first few lines of config.log?
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by FriCAS configure 2008-01-19, which was
generated by GNU Autoconf 2.61. Invocation command line was
$ ../fricasrev200/configure -with-lisp=/local/scratch/gcl/bin/gcl
## --------- ##
## Platform. ##
## --------- ##
hostname = aquin
uname -m = i686
uname -r = 2.6.15-51-686
uname -s = Linux
uname -v = #1 SMP PREEMPT Tue Feb 12 16:59:15 UTC 2008
Martin
PS: aldor.succ was a tgz. sorry, I missed the extension.
Thomas Feulner
I think you also meant me to use the src_aldor2.tgz instead to build
libaxiom.
I started your old makeAldor and got the following error message. May you tell
me, how to avoid the following error.
Thomas
Ralf Hemmecke
Please take libaxiom.al from the bottom of
http://axiom-wiki.newsynthesis.org/AldorForAxiom
which is:
http://axiom-wiki.newsynthesis.org/uploads/libaxiom.al
I hope the production of libaxiom.al will become better in the future.
Ralf
PS: Of course, you should already have axiom.as.
Thomas Feulner
> Hi Thomas,
>
> Please take libaxiom.al from the bottom of
> http://axiom-wiki.newsynthesis.org/AldorForAxiom
> which is:
>
> http://axiom-wiki.newsynthesis.org/uploads/libaxiom.al
I put it into $ALDORROOT/lib and started to build combinat. Make failed with
the attached error message, I think because of missing the gcc32.
Thomas
Ralf Hemmecke
> the attached error message, I think because of missing the gcc32.
That is a problem that can be solved by changing
$ALDORROOT/include/aldor.conf.
You linux section should look like
[linux]
inherit = linuxcore
# these enforce ieee
# ieee-opts = -ffloat-store -mieee-fp
ieee-opts = -ffloat-store
fast-opts = -ffast-math -O2
#cc-name = gcc32
#link-name = gcc32
i.e. in particular the last 2 lines should be comments. Actually there
is also a problem with "writable strings" (not really serious for us at
the moment). If you don't want to have that, then you should install a
gcc-3.4 (something smaller than 4 and bigger than 3.2) and change the
above to
cc-name = gcc-3.4
link-name = gcc-3.4
Of course, gcc-3.4 must then be in your PATH.
Ralf
Thomas Feulner
I have installed gcc-3.4 as you proposed.
And I could build the libraries!
I proceeded in the way, Martin described it and started fricas.
Calling
(1) lab: SetSpecies ACINT := set [i::ACINT for i in 1..4]
structures(lab)$Partition ACINT
gives me some more errors. I wonder why the call of (1) gave once an error and
once there was none.
Thomas
Ralf Hemmecke
That looks like some work for you.
Just one remark...
(2) -> structures(lab)$Partition ACINT
Looking in ACList(ACFraction(ACInteger)) for generator with code 978938982
>> System error:
FOAM-USER::|fiRaiseException| is invalid as a function.
that cannot work since that command returns a Generator and FriCAS does
not have that.
And it reminds me only of an error logged here:
http://www.risc.uni-linz.ac.at/people/hemmecke/AldorCombinat/combinatsu50.html
So you must at least suppress the output by adding a semicolon at the end.
s := structures(lab)$Partition ACINT;
next! s
Does that help?
Anyway. The error message looks like there is the aldor compiler
involved. Does someone know what FriCAS does here?
Ralf
Martin Rubey
> Hi Martin,
>
> That looks like some work for you.
Hm, I think you pointed to the problem already. What should work, however, is
P ==> Partition ACINT
[structures(lab)$P]$ACLIST(P)
Very unfortunately, the axiom interpreter is not clever enough to find the
right bracket function, so you have to tell him explicitely to take the one
from ACLIST(P).
I admit that the whole thing is very shaky, and I guess that this is not going
to change without putting in some effort. I guess this effort would be more
efficiently spent in making SPAD smarter.
I have no idea why
> > Calling
> > (1) lab: SetSpecies ACINT := set [i::ACINT for i in 1..4]
> > structures(lab)$Partition ACINT
> >
> > gives me some more errors. I wonder why the call of (1) gave once an error and
> > once there was none.
fails however. It should return
(1) -> s
(1) [<generator>]
Type: Generator Partition ACInteger
I must say that I'm pretty shocked how difficult it is to get all this
running. I'm very sorry.
Ralf, is it only working on my computer? Maybe you could try to issue
)set break break
lab: SetSpecies ACINT := set [i::ACINT for i in 1..4]
structures(lab)$Partition ACINT
and then type, in case of gcl ":bt", in sbcl "backtrace", and post the result.
But I'm afraid that the interface is not working properly.
Martin
Thomas Feulner
> )set break break
> lab: SetSpecies ACINT := set [i::ACINT for i in 1..4]
> structures(lab)$Partition ACINT
>
> and then type, in case of gcl ":bt", in sbcl "backtrace", and post the
> result. But I'm afraid that the interface is not working properly.
This is my result to the above sequence of commands. I hope it helps and that
only my computer is that persistent.
Thomas