aldor-interface
Ralf Hemmecke
I'm happy to announce that now branches/aldor-interface can be built
using the standard
./configure && make && make install
It will conditionally build the interface if aldor is available and skip
that part with a warning at configure time if some aldor stuff is missing.
After I've added a bit more documentation, it should be ready to be
merged with trunk. But as I said before, there are testers needed.
Ralf
Bill Page
On Sat, Aug 2, 2008 at 9:07 PM, Ralf Hemmecke wrote:
>
> I'm happy to announce that now branches/aldor-interface can be built
> using the standard
>
> ./configure && make && make install
>
> It will conditionally build the interface if aldor is available and skip
> that part with a warning at configure time if some aldor stuff is missing.
>
I di 'svn update' to revision 331 of your branch. When I tried just:
./configure && make
the Aldor interface was not automatically built.
> After I've added a bit more documentation, it should be ready to be
> merged with trunk. But as I said before, there are testers needed.
>
So far I have not yet been able to build it. :-(
Regards,
Bill Page.
Ralf Hemmecke
> Ralf,
>
> On Sat, Aug 2, 2008 at 9:07 PM, Ralf Hemmecke wrote:
>> I'm happy to announce that now branches/aldor-interface can be built
>> using the standard
>>
>> ./configure && make && make install
> I did 'svn update' to revision 331 of your branch.
Good. Now you should have revision 333. I've just commited two patches
that fixed the issues. Sorry, but the make process of FriCAS is not so
easy to understand.
You should have been able to compile FriCAS already. I think, if you say
svn update
cd $FRICAS_BUILD_DIR # whereever this is on your computer...
$FRICAS_SRC_DIR/configure
make
make install
should hopefully now work (even with a partial build that you might have).
Good luck.
Ralf
Bill Page
Thanks for all your work on this. I am getting closer, but there is
still a problem.
On Sun, Aug 3, 2008 at 9:51 AM, Ralf Hemmecke wrote:
>
> On 08/03/2008 02:29 PM, Bill Page wrote:
>> Ralf,
>>
>> On Sat, Aug 2, 2008 at 9:07 PM, Ralf Hemmecke wrote:
>>> I'm happy to announce that now branches/aldor-interface can be built
>>> using the standard
>>>
>>> ./configure && make && make install
>
>> I did 'svn update' to revision 331 of your branch.
>
> Good. Now you should have revision 333. I've just commited two patches
> that fixed the issues. Sorry, but the make process of FriCAS is not so
> easy to understand.
root@sage:~/fricas-aldor# svn info fricas-src
Path: fricas-src
URL: https://fricas.svn.sourceforge.net/svnroot/fricas/branches/aldor-interface
Repository Root: https://fricas.svn.sourceforge.net/svnroot/fricas
Repository UUID: b0c55286-4f34-0410-a049-a1e7e93b0762
Revision: 333
Node Kind: directory
Schedule: normal
Last Changed Author: hemmecke
Last Changed Rev: 333
Last Changed Date: 2008-08-03 06:46:11 -0700 (Sun, 03 Aug 2008)
>
> You should have been able to compile FriCAS already. I think, if you say
>
> svn update
> cd $FRICAS_BUILD_DIR # whereever this is on your computer...
> $FRICAS_SRC_DIR/configure
> make
> make install
>
> should hopefully now work (even with a partial build that you might have).
>
> Good luck.
Ok, better. But now after 'make install' I get the following error message:
Looking in OneDimensionalArray(Boolean()) for new with code 1050701442
>> System error:
FOAM-USER::|fiRaiseException| is invalid as a function.
--------
Here's the output from FriCAS in full:
FriCAS (AXIOM fork) Computer Algebra System
Version: FriCAS 2008-05-28
Timestamp: Saturday August 2, 2008 at 21:21:01
-----------------------------------------------------------------------------
Issue )copyright to view copyright notices.
Issue )summary for a summary of useful system commands.
Issue )quit to leave FriCAS and return to shell.
-----------------------------------------------------------------------------
(1) ->
(1) -> )co test.as
Compiling FriCAS source code from file
/home/page/fricas-aldor/test.as using AXIOM-XL compiler and
options
-O -Fasy -Fao -Flsp -laxiom -Mno-ALDOR_W_WillObsolete -DAxiom -Y
$AXIOM/algebra -I $AXIOM/algebra
Use the system command )set compiler args to change these
options.
Compiling Lisp source code from file ./test.lsp
Issuing )library command for test
Reading /home/page/fricas-aldor/test.asy
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/bc-matrix.
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/bc-misc.
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/bc-solve.
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/bc-util.
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/ht-util.
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/htsetvar.
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/ht-root.
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/br-con.
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/br-data.
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/showimp.
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/br-op1.
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/br-op2.
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/br-search.
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/br-util.
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/topics.
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/br-prof.
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/br-saturn.
(1) -> )sys cat test.as
# include "axiom.as"
import from Boolean, Integer, NonNegativeInteger;
sieve(n: Integer): Integer == {
isprime: OneDimensionalArray Boolean :=
new(n::NonNegativeInteger, true);
np:Integer := 0;
for p in 2..n | isprime p repeat {
np := np + 1;
for i in (p+p)..n by p repeat isprime i := false;
}
np
}
(1) -> sieve 10
Loading
/usr/local/lib/fricas/target/x86_64-unknown-linux/algebra/ARRAY1.o
for domain OneDimensionalArray
Loading
/usr/local/lib/fricas/target/x86_64-unknown-linux/algebra/A1AGG-.o
for domain OneDimensionalArrayAggregate&
Loading
/usr/local/lib/fricas/target/x86_64-unknown-linux/algebra/FLAGG-.o
for domain FiniteLinearAggregate&
Loading
/usr/local/lib/fricas/target/x86_64-unknown-linux/algebra/LNAGG-.o
for domain LinearAggregate&
Loading
/usr/local/lib/fricas/target/x86_64-unknown-linux/algebra/IXAGG-.o
for domain IndexedAggregate&
Loading
/usr/local/lib/fricas/target/x86_64-unknown-linux/algebra/CLAGG-.o
for domain Collection&
Loading
/usr/local/lib/fricas/target/x86_64-unknown-linux/algebra/HOAGG-.o
for domain HomogeneousAggregate&
Loading
/usr/local/lib/fricas/target/x86_64-unknown-linux/algebra/ORDSET-.o
for domain OrderedSet&
Loading
/usr/local/lib/fricas/target/x86_64-unknown-linux/algebra/AGG-.o
for domain Aggregate&
Loading
/usr/local/lib/fricas/target/x86_64-unknown-linux/algebra/ELTAGG-.o
for domain EltableAggregate&
Loading
/usr/local/lib/fricas/target/x86_64-unknown-linux/algebra/SETCAT-.o
for domain SetCategory&
Loading
/usr/local/lib/fricas/target/x86_64-unknown-linux/algebra/BASTYPE-.o
for domain BasicType&
Looking in OneDimensionalArray(Boolean()) for new with code 1050701442
>> System error:
FOAM-USER::|fiRaiseException| is invalid as a function.
(1) ->
----------
Regards,
Bill Page.
Bill Page
On Sun, Aug 3, 2008 at 12:15 PM, I wrote:
> ...
> Ok, better. But now after 'make install' I get the following error message:
>
> Looking in OneDimensionalArray(Boolean()) for new with code 1050701442
>
> >> System error:
> FOAM-USER::|fiRaiseException| is invalid as a function.
>
Hmm, this looks the kind of error I have seen due to the change in the
hashcode function in Aldor 1.1 (built from APL2 sources). What verison
of Aldor are you using/assuming for testing? Did you include the
hashcode patch in the FriCAS sources?
root@sage:~/fricas-aldor# aldor -v
Aldor version 1.1.0 for LINUX(glibc2.3)
#1 (Warning) No files! Type `aldor -help' for help.
Totals:
Time 0.0 s
Store 592 K pool, 277K alloc - 42K free - 143K gc = 92K final
----------
Regards,
Bill Page.
Ralf Hemmecke
> Ralf,
>
> still a problem.
> Ok, better. But now after 'make install' I get the following error message:
>
> Looking in OneDimensionalArray(Boolean()) for new with code 1050701442
>
> >> System error:
> FOAM-USER::|fiRaiseException| is invalid as a function.
Ooops....
I've really no idea where that comes from. Was that from a fresh build?
I don't even know who actually issues that error message. Looks like
FriCAS does not find something.
Hmmm, could you try on a 32bit system? But actually, I really, don't
know. Which Aldor-compiler are you using?
I am using 1.1.0 with a few minor tweaks that should not matter. I
haven't yet tested it with the binary 1.0.3 that is distributed in
binary form from aldor.org. Maybe I should find other test environments.
Ralf
Bill Page
>
> On 08/03/2008 06:15 PM, Bill Page wrote:
>
>> Ok, better. But now after 'make install' I get the following error message:
>>
>> Looking in OneDimensionalArray(Boolean()) for new with code 1050701442
>>
>> >> System error:
>> FOAM-USER::|fiRaiseException| is invalid as a function.
>
> Ooops....
>
> I've really no idea where that comes from. Was that from a fresh build?
Yes.
> I don't even know who actually issues that error message. Looks like
> FriCAS does not find something.
>
> Hmmm, could you try on a 32bit system? But actually, I really, don't
> know. Which Aldor-compiler are you using?
>
As I said in my previous email, I am using Aldor 1.1.0 compiled from source.
> I am using 1.1.0 with a few minor tweaks that should not matter.
> I haven't yet tested it with the binary 1.0.3 that is distributed in
> binary form from aldor.org. Maybe I should find other test
> environments.
>
If you really are using Aldor 1.1.0 I am at a loss to explain why it
works for you. The fricas-src directory from your repository does not
have the hashcode patch. Without this patch I do not think it is
possible to use Aldor 1.1. In any case, applying this patch (original
was supplied by Peter), fixes the problem for me.
root@sage:~/fricas-aldor# svn diff fricas-src
Index: fricas-src/src/interp/hashcode.boot
===================================================================
--- fricas-src/src/interp/hashcode.boot (revision 333)
+++ fricas-src/src/interp/hashcode.boot (working copy)
@@ -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)
-----------
Note: If you are using a previous version of Aldor you should *not*
apply this patch or else you will get similar failures. I guess this
will make it rather hard for the build system to be compatible with
older versions. It seems that in order to have a working system with a
given verison of Aldor, a compatible change must be made to the FriCAS
source.
In any case now I have a fully operational Aldor interface! Could you
please check your configuration again and make sure you are using
Aldor 1.1.0 compiled from source. I think this is the version that we
should intend first of all to support. For me, this requires the patch
above.
I think this new interface build is excellent work on your part, even
more so because it includes very useful documentation that was missing
from in the two previous versions done by Peter.
Thanks Ralf!
Regards,
Bill Page.
Ralf Hemmecke
> works for you. The fricas-src directory from your repository does not
> have the hashcode patch. Without this patch I do not think it is
> possible to use Aldor 1.1. In any case, applying this patch (original
> was supplied by Peter), fixes the problem for me.
OK. So this patch is in fricas-trunk???
> root@sage:~/fricas-aldor# svn diff fricas-src
> Index: fricas-src/src/interp/hashcode.boot
> ===================================================================
> --- fricas-src/src/interp/hashcode.boot (revision 333)
> +++ fricas-src/src/interp/hashcode.boot (working copy)
> @@ -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)
>
> Note: If you are using a previous version of Aldor you should *not*
> apply this patch or else you will get similar failures. I guess this
> will make it rather hard for the build system to be compatible with
> older versions. It seems that in order to have a working system with a
> given verison of Aldor, a compatible change must be made to the FriCAS
> source.
Well, one could check at configure time, but I agree, we should forget
about 1.0.3 and rather make 1.1.0 working.
> I think this new interface build is excellent work on your part, even
> more so because it includes very useful documentation that was missing
> from in the two previous versions done by Peter.
I am not completely satisfied with the documentation, and will probably
iron out some things that I changed in the last minute. But of course,
it would be wonderful, if some other person tries to understand the code
and asks now if something is unclear. I'd like to increase the
bus-factor of that code to >=2. ;-)
Ralf
Bill Page
>
>> If you really are using Aldor 1.1.0 I am at a loss to explain why it
>> works for you. The fricas-src directory from your repository does not
>> have the hashcode patch. Without this patch I do not think it is
>> possible to use Aldor 1.1. In any case, applying this patch (original
>> was supplied by Peter), fixes the problem for me.
>
> OK. So this patch is in fricas-trunk???
>
No. Do you think that it should be?
> ...
Regards,
Bill Page.
Ralf Hemmecke
> On Mon, Aug 4, 2008 at 4:04 AM, Ralf Hemmecke wrote:
>>> If you really are using Aldor 1.1.0 I am at a loss to explain why it
>>> works for you. The fricas-src directory from your repository does not
>>> have the hashcode patch. Without this patch I do not think it is
>>> possible to use Aldor 1.1. In any case, applying this patch (original
>>> was supplied by Peter), fixes the problem for me.
That is all I could find for the origin of the patch.
http://groups.google.com/group/fricas-devel/browse_thread/thread/e618d8d7274282ae/08230f9f98c9cd19?lnk=gst&q=hashCombine#08230f9f98c9cd19
Martin, where did you get it from?
>> OK. So this patch is in fricas-trunk???
> No. Do you think that it should be?
I don't know. I rather think it is an issue with the Aldor compiler,
isn't it? I am just compiling with vanilla Aldor -r23 on a 64 bit
machine. Let's see what that brings.
Oh, there was even another patch by Peter Broadbery that might be
relevant to the interface.
http://groups.google.com/group/fricas-devel/browse_thread/thread/66a0a62a632aa2f4/a98f944113bc323e?lnk=gst&q=broadbery+patch#a98f944113bc323e
It looks to me like that might be relevant also for what I have changed
in editlevels.h
after a suggestion by Laurentiu.
http://www.nabble.com/Compilation-problem-td14295218.html
I haven't tested so far. But if that works then, perhaps we should open
a branch on algebraist and let people get the source from there. These
nasty little details just prevent people from being able to compile and
work with the aldor compiler.
See also http://www.nabble.com/byacc---%3E-zacc-td18802731.html .
Oh, by the way, there are so many patches floating around. Perhaps also
FriCAS should have a patch list like openaxiom?
http://www.open-axiom.org/lists.html
Ralf
Bill Page
> ...
> I don't know. I rather think it is an issue with the Aldor compiler,
> isn't it? I am just compiling with vanilla Aldor -r23 on a 64 bit
> machine. Let's see what that brings.
This is just a guess but, I have been compiling on a 64 bit debian
machine (sage.math...). (Maybe) the reason you did not see the problem
with hashcode is because you have been using a 32-bit platform for
development? The patch to hashcode seems to suggest something to do
with the hash size, although I have to admit I do not understand the
magic.
Regards,
Bill Page.
Ralf Hemmecke
Ralf
(1) -> )co sieve.as
Compiling FriCAS source code from file /home/hemmecke/sieve.as using
AXIOM-XL compiler and options
-O -Fasy -Fao -Flsp -laxiom -Mno-ALDOR_W_WillObsolete -DAxiom -Y
$AXIOM/algebra -I $AXIOM/algebra
Use the system command )set compiler args to change these
options.
Compiling Lisp source code from file ./sieve.lsp
Issuing )library command for sieve
Reading /home/hemmecke/sieve.asy
(1) -> sieve 10
Looking in OneDimensionalArray(Boolean()) for new with code 1050701442
>> System error:
FOAM-USER::|fiRaiseException| is invalid as a function.
Bill Page
On Tue, Aug 5, 2008 at 5:17 AM, Ralf Hemmecke wrote:
>
> Well, now that is my error on an unpatched 64 bit system. :-(
> ...
Well, I am glad that you can confirm this. Have you tried applying the
hashcode patch and re-building the interface? My guess is still that
this patch is necessary when building the Aldor interface on a 64 bit
platform. In that case, then maybe it should always be applied to
FriCAS. As far as I can see, it does not have any negative impact to
FriCAS when the Aldor interface is not used.
---------
Here is another data point. After successfully building and running
your 'aldor-interface' branch, I decided to try updating the FriCAS
sources to head and then re-build the interface with the most recent
version of FriCAS. My intention was to create a new version of FriCAS
including Aldor for use on the axiom-wiki.
I did this by using the following svn merge command:
cd ~/fricas-aldor/fricas-src
svn update
svn merge -r 288:HEAD https://fricas.svn.sourceforge.net/svnroot/fricas/trunk
If I understand the use of svn correctly, this should result in
applying all changes in FriCAS since you cloned the branch to my local
working copy. This is did not show any merge conflicts, so I did a
clean build.
cd ~/fricas-aldor/fricas-build
rm -rf *
../fricas-src/configure && make
Everything built without errors, including the Aldor interface. But now after
make install
when I compile my 'test.as' file and calling the 'sieve' function I get:
>> System error:
The function NIL is undefined.
Here's the console log:
root@sage:~/fricas-aldor# axiom
(HyperDoc) Cannot connect to the X11 server!
GCL (GNU Common Lisp) 2.6.8 CLtL1 Nov 9 2007 07:47:56
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
openServer result 0
FriCAS (AXIOM fork) Computer Algebra System
Version: FriCAS 2008-05-28
Timestamp: Tuesday August 5, 2008 at 19:20:38
-----------------------------------------------------------------------------
Issue )copyright to view copyright notices.
Issue )summary for a summary of useful system commands.
Issue )quit to leave FriCAS and return to shell.
-----------------------------------------------------------------------------
(1) ->
(1) -> )co test.as
Compiling FriCAS source code from file
/home/page/fricas-aldor/test.as using AXIOM-XL compiler and
options
-O -Fasy -Fao -Flsp -laxiom -Mno-ALDOR_W_WillObsolete -DAxiom -Y
$AXIOM/algebra -I $AXIOM/algebra
Use the system command )set compiler args to change these
options.
Compiling Lisp source code from file ./test.lsp
Issuing )library command for test
Reading /home/page/fricas-aldor/test.asy
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/bc-matrix.
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/bc-misc.
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/bc-solve.
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/bc-util.
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/ht-util.
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/htsetvar.
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/ht-root.
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/br-con.
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/br-data.
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/showimp.
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/br-op1.
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/br-op2.
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/br-search.
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/br-util.
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/topics.
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/br-prof.
Loading /usr/local/lib/fricas/target/x86_64-unknown-linux/autoload/br-saturn.
(1) -> sieve 10
>> System error:
The function NIL is undefined.
(1) ->
----------
I am not sure yet what change in FriCAS since rev: 288 is causing this
error. Waldek, any ideas?
Regards,
Bill Page.
Bill Page
> ...
> Here is another data point. After successfully building and running
> your 'aldor-interface' branch, I decided to try updating the FriCAS
> sources to head and then re-build the interface with the most recent
> version of FriCAS. My intention was to create a new version of
> FriCAS including Aldor for use on the axiom-wiki.
>
> >> System error:
> The function NIL is undefined.
>
> (1) ->
>
> ----------
>
> I am not sure yet what change in FriCAS since rev: 288 is causing this
> error. Waldek, any ideas?
>
I noticed that in FriCAS head compared to rev: 288 there are some
changes to the algebra. For example 'OrderedSemiGroup' is added as a
category and referred to in several places.
Ralf, when adding such changes to the algebra, is it necessary to
modify any of the Aldor interface files or is this supposed to be
automatic in the new build process?
Regards,
Bill Page.
Ralf Hemmecke
> changes to the algebra. For example 'OrderedSemiGroup' is added as a
> category and referred to in several places.
> Ralf, when adding such changes to the algebra, is it necessary to
> modify any of the Aldor interface files or is this supposed to be
> automatic in the new build process?
You would have to rebuild but my build process is nearly immune against
algebra changes. The only file that must be manually modified is
src/aldor/initlist.as. So if some domain that appears there is renamed
then also initlist.as has to be adapted. But these occasions will
certainly be rare. And with "extend" initlist.as can be removed completely.
Other points are:
If SubsetCategory is no longer a SPAD builtin but becomes a true
category in the algebra library, then all parts related to subsetc.as
can be removed.
If attributes are removed from SPAD then everything related to
"attrib.as" can be removed.
Ralf
Bill Page
On Wed, Aug 6, 2008 at 3:26 PM, Ralf Hemmecke you wrote:
>
> Bill Page wrote:
>> I noticed that in FriCAS head compared to rev: 288 there are some
>> changes to the algebra. For example 'OrderedSemiGroup' is added
>> as a category and referred to in several places.
>
>> Ralf, when adding such changes to the algebra, is it necessary to
>> modify any of the Aldor interface files or is this supposed to be
>> automatic in the new build process?
>
> You would have to rebuild but my build process is nearly immune against
> algebra changes. The only file that must be manually modified is
> src/aldor/initlist.as. So if some domain that appears there is renamed
> then also initlist.as has to be adapted. But these occasions will
> certainly be rare. And with "extend" initlist.as can be removed completely.
>
Ok, thanks. That is reassuring.
I am currently bisecting the changes from -rev: 288 to 337 (HEAD) to
find the change to FriCAS that causes the "NIL not found" error in the
Aldor interface build that I reported earlier. So far I know that
'svn merge -r288:312 ... ' works. So the problem occurs sometime after
rev: 312. I am doing a complete rebuild after each step so this may
take some time. I will let you know when I find it.
Regards,
Bill Page.
Ralf Hemmecke
> find the change to FriCAS that causes the "NIL not found" error in the
> Aldor interface build that I reported earlier. So far I know that
> 'svn merge -r288:312 ... ' works. So the problem occurs sometime after
> rev: 312. I am doing a complete rebuild after each step so this may
> take some time. I will let you know when I find it.
Interesting. I was thinking about merging changes from trunk to
aldor-improvements. So maybe I should wait.
Could you give a link (into the mailinglist) to your error report. I am
somehow rather unorganized at the moment.
What are the machine specifications of your computer. Which Lisp, which
Aldor?
Ralf
Bill Page
On Wed, Aug 6, 2008 at 5:15 PM, you wrote:
> Bill Page wrote:
>> I am currently bisecting the changes from -rev: 288 to 337 (HEAD)
>> to find the change to FriCAS that causes the "NIL not found" error
>> in the Aldor interface build that I reported earlier. So far I know that
>> 'svn merge -r288:312 ... ' works. So the problem occurs sometime
>> after rev: 312. I am doing a complete rebuild after each step so this
>> may take some time. I will let you know when I find it.
>
> Interesting. I was thinking about merging changes from trunk to
> aldor-improvements. So maybe I should wait.
>
> Could you give a link (into the mailinglist) to your error report. I am
> somehow rather unorganized at the moment.
>
http://groups.google.com/group/fricas-devel/msg/9319d528f5e0a94c?hl=en
> What are the machine specifications of your computer.
16 processor, 64-bit AMD Opteron, running Debian (sage.math....)
> Which Lisp,
GCL-2.6.8pre
> which Aldor?
>
1.1.0 from recent source.
Regards,
Bill Page.
Ralf Hemmecke
Might that be related to the patch Gregory sent recently?
Gaby has applied that patch in revision 677 of OpenAxiom.
Ralf
Bill Page
Yes I tried that, but it had no effect. I guess the reason is that
|Nil| (name with Lisp escape characters) is not NIL (unescaped Lisp
symbol). Maybe that is something that only applies to SBCL?
Regards,
Bill Page.
Bill Page
>
> I am currently bisecting the changes from -rev: 288 to 337 (HEAD)
> to find the change to FriCAS that causes the "NIL not found" error
> in the Aldor interface build that I reported earlier. So far I know that
> 'svn merge -r288:312 ... ' works. So the problem occurs sometime
> after rev: 312. I am doing a complete rebuild after each step so this
> may take some time. I will let you know when I find it.
>
Ok, the result of the search shows that the error:
>> System error:
The function NIL is undefined.
appears exactly with the last non-aldor-related revision: 336.
http://fricas.svn.sourceforge.net/viewvc/fricas?view=rev&revision=336
entitled: Misc cleanups.
Unfortunately this is a rather large a diverse set of changes with
minimal documentation :-(. But something here breaks the aldor
interface build... so now I am reversing each patched file in this set
one at a time. Luckly, this does not seem to require a complete
re-build for each change.
--------
The result is that the following patch to daase.lisp:
is what causes the breakage. The reason does not at all see obvious to
me. Can anyone see why this patch would cause this error when a
function compiled with Aldor:
)co test.as
--
# include "axiom.as"
import from Boolean, Integer, NonNegativeInteger;
sieve(n: Integer): Integer == {
isprime: OneDimensionalArray Boolean :=
new(n::NonNegativeInteger, true);
np:Integer := 0;
for p in 2..n | isprime p repeat {
np := np + 1;
for i in (p+p)..n by p repeat isprime i := false;
}
np
}
--
is run:
(1) -> sieve 3332
>> System error:
The function NIL is undefined.
Regards,
Bill Page.
Bill Page
>
> The result is that the following patch to daase.lisp:
>
> http://fricas.svn.sourceforge.net/viewvc/fricas/trunk/src/interp/daase.lisp?r1=336&r2=335&pathrev=336
>
> is what causes the breakage. The reason does not at all see obvious to
> me. Can anyone see why this patch would cause this error when a
> function compiled with Aldor:
>
Ok now very proud of myself, I collect yet another reason "why I hate lisp" ;-)
I see what went wrong. In lines 1690 and 1701 the call to
(|CCall| (eval getter-name))
was unintentionally omitted during the "clean-up" related to removing
support for CCL - probably due to a mistake in the scope of the #:CCL
( ... ) clause. I am unclear on exactly what this function call does,
but adding this function call back in, corrects the problem. This
might actually affect more than just the Aldor interface.
Waldek, do you agree? Would you like me to commit this change?
Regards,
Bill Page.
Ralf Hemmecke
>
> (|CCall| (eval getter-name))
>
> was unintentionally omitted during the "clean-up" related to removing
> support for CCL
Bill, I am amazed of your effort to get this resolved. Big thank you.
Waldek, could you commit Bill's patch?
Ralf
Martin Rubey
> On Wed, Aug 6, 2008 at 10:20 PM, Bill Page wrote:
> >
> > The result is that the following patch to daase.lisp:
> >
> > http://fricas.svn.sourceforge.net/viewvc/fricas/trunk/src/interp/daase.lisp?r1=336&r2=335&pathrev=336
> >
> > is what causes the breakage. The reason does not at all see obvious to
> > me. Can anyone see why this patch would cause this error when a
> > function compiled with Aldor:
> >
>
> Ok now very proud of myself, I collect yet another reason "why I hate lisp"
> ;-)
What does this have to do with lisp? I remember that I was sitting with a
friend for a long time in front of a turbo pascal program, that misbehaved (did
not fail!) because of a forgotten semicolon...
> I see what went wrong. In lines 1690 and 1701 the call to
>
> (|CCall| (eval getter-name))
>
> was unintentionally omitted during the "clean-up" related to removing
> support for CCL - probably due to a mistake in the scope of the #:CCL
> ( ... ) clause. I am unclear on exactly what this function call does,
> but adding this function call back in, corrects the problem. This
> might actually affect more than just the Aldor interface.
>
> Waldek, do you agree? Would you like me to commit this change?
I don't know what the function does either, but it seems quite obvious that it
should not be removed...
Apart from that, I think that Waldek's effort to remove unused code does make
sense, even though it is bound to introduce bugs at times.
It is much easier to understand (especially lisp) code, if you can be sure that
all present code is used. Unused lisp code is, in my opinion, highly
undesirable, because you can never know: if a function name never appears in
code except when defun'd, it may still be called since the name could be
constructed somewhere and the result is called. Actually, that happens in the
SPAD compiler...
Martin
Bill Page
>
> Bill Page writes:
>
>> On Wed, Aug 6, 2008 at 10:20 PM, Bill Page wrote:
>> Ok now very proud of myself, I collect yet another reason "why I hate lisp"
>> ;-)
>
> What does this have to do with lisp?
Parens combined with preprocessor conditionals!
> I remember that I was sitting with a friend for a long time in front of a
> turbo pascal program, that misbehaved (did not fail!) because of a
> forgotten semicolon...
I hate semicolons too. :-)
>
>> I see what went wrong. In lines 1690 and 1701 the call to
>>
>> (|CCall| (eval getter-name))
>>
>> was unintentionally omitted during the "clean-up" related to removing
>> support for CCL - probably due to a mistake in the scope of the #:CCL
>> ( ... ) clause. I am unclear on exactly what this function call does,
>> but adding this function call back in, corrects the problem. This
>> might actually affect more than just the Aldor interface.
>>
>> Waldek, do you agree? Would you like me to commit this change?
>
> I don't know what the function does either, but it seems quite obvious that
> it should not be removed...
>
> Apart from that, I think that Waldek's effort to remove unused code does
> make sense, even though it is bound to introduce bugs at times.
>
I agree.
> It is much easier to understand (especially lisp) code, if you can be sure
> that all present code is used. Unused lisp code is, in my opinion, highly
> undesirable, because you can never know: if a function name never appears
> in code except when defun'd, it may still be called since the name could be
> constructed somewhere and the result is called. Actually, that happens in
> the SPAD compiler...
>
I am not so sure about "understand" but if you said "test", then I
think that is certainly true. This is a strong argument in favor of
unit testing which is almost complete absent in Axiom and Aldor. :-(
Regards,
Bill Page.
Ralf Hemmecke
> unit testing which is almost complete absent in Axiom and Aldor. :-(
http://www.risc.uni-linz.ac.at/software/aldor/aldorunit
Ralf
Martin Rubey
Also for FriCAS there is an adequate testing package now. Well, at least I am
quite happy with it. See matcat.spad.pamphlet, table.spad.pamphlet and
bugs200*.input.pamphlet for examples.
Note that the tests in bugs200*.input.pamphlet are regression tests which
(should) get added every time a bug is identified, while the tests in the
algebra should be unit tests, testing and exemplifying each function. Since my
time is limited, I only added tests whenever I modified a function.
THe SAGE team is doing a very very good job there, actually.
Martin
Bill Page
>
> Ralf Hemmecke <ra...@hemmecke.de> writes:
>
>> > This is a strong argument in favor of
>> > unit testing which is almost complete absent in Axiom and Aldor. :-(
>>
>> http://www.risc.uni-linz.ac.at/software/aldor/aldorunit
>
> Also for FriCAS there is an adequate testing package now. Well, at least
> I am quite happy with it. See matcat.spad.pamphlet, table.spad.pamphlet
> and bugs200*.input.pamphlet for examples.
>
Yes, in spite of thes *tools*, as I said actual *unit* testing is
still almost completely absent in Axiom and Aldor.
> Note that the tests in bugs200*.input.pamphlet are regression tests
> which (should) get added every time a bug is identified, while the tests in
> the algebra should be unit tests, testing and exemplifying each function.
> Since my time is limited, I only added tests whenever I modified a function.
>
Regression testing is a somewhat different subject - also important.
> THe SAGE team is doing a very very good job there, actually.
>
I think they are doing a fantastic job with testing! They are better
than any other computer algebra system that exists today - both
commercial and free.
Regards,
Bill Page.
Waldek Hebisch
> Ok now very proud of myself, I collect yet another reason "why I hate lisp" ;-)
>
> I see what went wrong. In lines 1690 and 1701 the call to
>
> (|CCall| (eval getter-name))
>
> was unintentionally omitted during the "clean-up" related to removing
> support for CCL - probably due to a mistake in the scope of the #:CCL
> ( ... ) clause. I am unclear on exactly what this function call does,
> but adding this function call back in, corrects the problem. This
> might actually affect more than just the Aldor interface.
>
> Waldek, do you agree? Would you like me to commit this change?
>
Good catch, thanks Bill. Both functions are really used only by Aldor
interface -- they are part of magic to correctly (auto)load and
initialize Aldor code.
I the last three weeks I had no internet access, so I could not
comment on this. I have commited the patch now to avoid further
delay.
--
Waldek Hebisch
heb...@math.uni.wroc.pl