Change to Aldor support files.
Waldek Hebisch
Could you test the attached patch. More precisely, please
apply the patch to the trunk and remove src/interp/sys-pkg.lisp and
src/interp/axext_l.lisp.
After recent changes sys-pkg.lisp is only used for Aldor
support and eliminating it simplifies Makefile logic.
The patch also make depsys smaller -- it no longer
contains 'foam_l' and 'axext_l' (actually this is step
towards completely removing depsys).
In the past similar change broke Aldor compatibility. I hope
that this time it will work, but do not want to apply it
without testing with Aldor.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Bill Page
I applied your patch to Ralf's git source and re-built FriCAS and the
Aldor interface with no problems. The interface appears to function
normally.
Regards,
Bill Page.
Ralf Hemmecke
> Could you test the attached patch. More precisely, please
> apply the patch to the trunk and remove src/interp/sys-pkg.lisp and
> src/interp/axext_l.lisp.
I've checked
https://github.com/hemmecke/fricas/commit/82136e36571483357a9017fffefac99359189af4
which is exactly your patch and the two files above removed.
Works fine with "SBCL 1.0.50.0.debian" on an Ubuntu 11.10 (64bit).
However, since sys-pkg.lisp influenced only the ECL build, I've
installed ECL 10.3.1 (which comes with Ubuntu) and tried to compile.
Since it failed rather early, I've removed -j8 from the make options.
You can find the log temporarily at
See also below for the last few lines of the log.
> After recent changes sys-pkg.lisp is only used for Aldor
> support and eliminating it simplifies Makefile logic.
Not that I would need ecl at the moment, but wasn't Sage using ecl?
So not building with ecl would break the fricas sage interface. I
haven't yet tried to figure out how to run sbcl-fricas from within Sage.
Should be doable, but anyway, I'm more interested in using sagenb as a
notebook interface to fricas. (There should be no need for ecl in this
case.)
Anyway, I had the impression that fricas is trying to build on as many
lisp flavours as possible.
Waldek, do you know from the log what could be the reason for the
ecl-fricas build problem. Otherwise I'll try to start a git-bisect to
find the prolematic commit.
Anyone knows a version where fricas builds with ecl (please include
version of ecl).
> The patch also make depsys smaller -- it no longer
> contains 'foam_l' and 'axext_l' (actually this is step
> towards completely removing depsys).
That sounds great. The less different images, the better. ;-)
Ralf
---------------------------------------------------------------------
;;; Loading #P"/usr/lib/ecl-10.3.1/cmp.fas"
;;; Loading #P"/usr/lib/ecl-10.3.1/sysfun.lsp"
Starting interpsys
The function (SETF BOOT::SYMBOL-VALUES) is undefined.
No restarts available.
Broken at SI:BYTECODES. [Evaluation of: (PROGN (DEFPARAMETER
BOOT::*YEARWEEK* "Sunday January 8, 2012 at 12:32:22 ") (DEFPARAMETER
BOOT::*BUILD-VERSION* "FriCAS 82136e36571483357a9017fffefac99359189af4")
(DEFPARAMETER BOOT::TIMESTAMP
"/home/hemmecke/g/fricas-bisect/b/target/x86_64-unknown-linux/timestamp") (BOOT::INTERPSYS-ECL-IMAGE-INIT
"/home/hemmecke/g/fricas-bisect/b/target/x86_64-unknown-linux"))] In:
#<process SI:TOP-LEVEL 0000000000bb5f60>.
>>
mv: cannot stat `browse.daase': No such file or directory
mv: cannot stat `category.daase': No such file or directory
mv: cannot stat `compress.daase': No such file or directory
mv: cannot stat `interp.daase': No such file or directory
mv: cannot stat `operation.daase': No such file or directory
make[3]: *** [stamp-db] Error 1
make[3]: Leaving directory
`/home/hemmecke/v/git/fricas-bisect/b/src/algebra'
make[2]: *** [all-ax] Error 2
make[2]: Leaving directory
`/home/hemmecke/v/git/fricas-bisect/b/src/algebra'
make[1]: *** [all-algebra] Error 2
make[1]: Leaving directory `/home/hemmecke/v/git/fricas-bisect/b/src'
make: *** [all-src] Error 2
Ralf Hemmecke
Ubuntu 11.10, 64bit
fricas r1273 + Waldek's aldor support patch and axext_l.lisp,
sys-pkg.lisp removed.
http://groups.google.com/group/fricas-devel/browse_thread/thread/f45c509c8f8cca04
gcl --version # ubuntu package
GCL (GNU Common Lisp) 2.6.7 CLtL1 Sep 17 2011 21:52:38
>clisp --version # ubuntu package
GNU CLISP 2.49 (2010-07-07) (built on allspice.buildd [127.0.1.1])
>ecl --version #ubuntu package
ECL 10.3.1
sbcl --version #ubuntu package
SBCL 1.0.50.0.debian
(Clozure CL) Installed from
http://svn.clozure.com/publicsvn/openmcl/release/1.7/linuxx86/ccl
ccl --version
Version 1.7-r14925M (LinuxX8664)
compilation of gcl clisp ccl ecl sbcl
fricas good good good bad good
libaxiom.al bad good good --- good
compile simple.as --- good good --- good
run f() --- bad bad --- good
In case of clisp I don't actually know whether the compilation of
simple.as went OK, but at least AXIOMsys did not seem to complain.
For ccl, I've checked
aldor -O -Fasy -Fao -Flsp -laxiom -Mno-ALDOR_W_WillObsolete -DAxiom -Y
$AXIOM/algebra -I $AXIOM/algebra simple.as
echo $?
0
==================
(1) -> Compiling FriCAS source code from file
/home/hemmecke/v/git/fricas-bisect/b/simple.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.
The )library system command was not called after compilation.
(1) -> There are no library operations named f
Use HyperDoc Browse or issue
)what op f
to learn if there is any operation containing " f " in its name.
Cannot find a no-argument definition or library operation named f .
========================
-- simple.as:
#include "axiom"
#pile
dd1: with
f: ()->Integer
== add
f():Integer == 1
=======================
The aldor-interface only seems to work with sbcl.
Ralf
PS: The INSTALL file file says that "Clozure CL 1.7 apparently
miscompiles FriCAS." How does this manifest?
With Clozure CL and r1273 same results as with applied patches from Waldek.
PS2: Interesting that it needs less than 7 min to build
fricas+libaxiom.al with sbcl but 30 min with ccl (both with make -j8).
Waldek Hebisch
>
> Hi Waldek,
>
> > Could you test the attached patch. More precisely, please
> > apply the patch to the trunk and remove src/interp/sys-pkg.lisp and
> > src/interp/axext_l.lisp.
>
> I've checked
> https://github.com/hemmecke/fricas/commit/82136e36571483357a9017fffefac99359189af4
> which is exactly your patch and the two files above removed.
>
> Works fine with "SBCL 1.0.50.0.debian" on an Ubuntu 11.10 (64bit).
>
> However, since sys-pkg.lisp influenced only the ECL build, I've
> installed ECL 10.3.1 (which comes with Ubuntu) and tried to compile.
> Since it failed rather early, I've removed -j8 from the make options.
>
> You can find the log temporarily at
>
> http://www.risc.jku.at/people/hemmecke/tmp/82136e36571483357a9017fffefac99359189af4_2012-01-08_12-31-38.fricas.log
>
> See also below for the last few lines of the log.
> The function (SETF BOOT::SYMBOL-VALUES) is undefined.
> No restarts available.
I see, this was a typo in FriCAS source. Should be fixed in
the trunk.
> Anyone knows a version where fricas builds with ecl (please include
> version of ecl).
>
I have tested with recent CVS. I think that 11.1.1 release is
not affected by that typo (however, all recent CVS checkout
claims to be 11.1.1). For long time I have not tested with
10.3.1 -- I have mostly used later versions and sometimes
earlier ones.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Waldek Hebisch
There are few testsute failures, one when using RealClosure,
another with plotting.
> With Clozure CL and r1273 same results as with applied patches from Waldek.
So the failure is not a new problem?
> PS2: Interesting that it needs less than 7 min to build
> fricas+libaxiom.al with sbcl but 30 min with ccl (both with make -j8).
Strange. On my machine build using sbcl takes about 7 min,
while build using Closure Cl about 10 min. Testsute
when using Closure Cl 1.7 takes only few percent more
time than using sbcl.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
>
> So the failure is not a new problem?
Exactly. I can compile just fine, but calling f() does neither work with
nor without your patch.
>> PS2: Interesting that it needs less than 7 min to build
>> fricas+libaxiom.al with sbcl but 30 min with ccl (both with make -j8).
> Strange. On my machine build using sbcl takes about 7 min,
> while build using Closure Cl about 10 min. Testsute
> when using Closure Cl 1.7 takes only few percent more
> time than using sbcl.
This is what "time make -j8 > make.log 2>&1" reported.
real 26m50.752s
user 18m1.080s
sys 1m14.949s
I've compiled libaxiom.al after that and that took
real 3m11.336s
user 8m59.170s
sys 0m53.251s
BTW, what is the proposed way of running the testsuite?
I'd propose to add something like "make check" to the top-level Makefile.in.
Ralf
Waldek Hebisch
>
> >> With Clozure CL and r1273 same results as with applied patches from Waldek.
> >
> > So the failure is not a new problem?
>
> Exactly. I can compile just fine, but calling f() does neither work with
> nor without your patch.
I am not sure if Aldor interface was ported to Clozure CL.
IIRC Martin Rubey used Aldor interface with ecl and probably
also with clisp. And of course it used to work with gcl.
> >> PS2: Interesting that it needs less than 7 min to build
> >> fricas+libaxiom.al with sbcl but 30 min with ccl (both with make -j8).
>
> > Strange. On my machine build using sbcl takes about 7 min,
> > while build using Closure Cl about 10 min. Testsute
> > when using Closure Cl 1.7 takes only few percent more
> > time than using sbcl.
>
> This is what "time make -j8 > make.log 2>&1" reported.
>
> real 26m50.752s
> user 18m1.080s
> sys 1m14.949s
>
user and sys time are sightly smaller than on my machine,
but real time is much bigger. It seems that Closure Cl
must be waiting for something, maybe it access files on
NFS?
> I've compiled libaxiom.al after that and that took
>
> real 3m11.336s
> user 8m59.170s
> sys 0m53.251s
>
> BTW, what is the proposed way of running the testsuite?
Curretly it is 'make all-input'
> I'd propose to add something like "make check" to the top-level Makefile.in.
Yes, I would like to add 'make check'. However, I do not think
we should run all things in 'src/input', for example 'marcbench'
is more a benchmark than a test, and 'mapleok' and 'r21bugsbig'
are also not usual tests. Actually, people want 'make check'
to give easy to interpret result like yes/no or number of
failing tests, so I think about running just tests handled
by unit testing machinery and add some summary feature.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
>> user 18m1.080s
>> sys 1m14.949s
> user and sys time are sightly smaller than on my machine,
> but real time is much bigger. It seems that Closure Cl
> must be waiting for something, maybe it access files on
> NFS?
Certainly not. That's a laptop and has no access to NFS. Everything done
on the local harddisk (no SSD). If you have an idea where to monitor
what caused that long time, I'd be very grateful.
> Yes, I would like to add 'make check'. However, I do not think
> we should run all things in 'src/input', for example 'marcbench'
> is more a benchmark than a test, and 'mapleok' and 'r21bugsbig'
> are also not usual tests. Actually, people want 'make check'
> to give easy to interpret result like yes/no or number of
> failing tests, so I think about running just tests handled
> by unit testing machinery and add some summary feature.
As you know, I've once started another test machinery.
http://groups.google.com/group/fricas-devel/browse_thread/thread/b553b809698a9bd2
I haven't looked at it for a while, but I still want autotools for all
of fricas. I know that automake doesn't help much with the lisp stuff,
but it can generate all the boilerplate for testing.
Meanwhile I'd like to setup a local environment where I take more care
on different lisps and always running the tests. I more or less want to
automate all this.
Finding the place where the aldor-interface broke was good to learn
about git bisect, but eventually, I'd like to get automatically notified
when it (or any other part of fricas) break again.
Ralf
Waldek Hebisch
>
> >> With Clozure CL and r1273 same results as with applied patches from Waldek.
> >
> > So the failure is not a new problem?
>
> Exactly. I can compile just fine, but calling f() does neither work with
> nor without your patch.
>
OK. It would be better if Aldor interface worked with all supported
Lisps, but it seems that the my patch does not make situation
worse so I commited it now.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
> Lisps, but it seems that the my patch does not make situation
> worse so I commited it now.
Fine with me. SBCL seems to be my favourite, anyway. I will try to get
things also working for other lisps flavours, but I see this only with
respect to perhaps finding some hidden bugs in the fricas sources.
Otherwise, I would be happier if there were people who complained (i.e.
sending proper bug report) about non-working aldor interface for certain
lisps.
I'll look a bit into getting ecl working but otherwise wasting time with
making something work that nobody is interested in is not my objective.
Ralf
Bill Page
>
> Fine with me. SBCL seems to be my favourite, anyway. I will try to get
> things also working for other lisps flavours, but I see this only with
> respect to perhaps finding some hidden bugs in the fricas sources.
>
I only use SBCL with FriCAS now. It works fine also when callling
FriCAS from Sage. The only advantage of ecl is that it is included
with Sage and allows quick install of FriCAS as a Sage package without
any knowledge of how to build FriCAS. But I have no idea how many
people, besides Ralf and me, care about FriCAS and Sage.
> Otherwise, I would be happier if there were people who complained (i.e.
> sending proper bug report) about non-working aldor interface for certain
> lisps.
>
Actually it is pretty hard to say even how many FriCAS users actually
use Aldor, besides Ralf and me ... but my impression is that it must
be quite small.
> I'll look a bit into getting ecl working but otherwise wasting time with
> making something work that nobody is interested in is not my objective.
>
That seems correct to me.
Regards,
Bill Page.
Ralf Hemmecke
> use Aldor, besides Ralf and me ... but my impression is that it must
> be quite small.
Of course, that number is small. Maybe less than 2. ;-) But with the
issues that popped up in jet.spad.pamphlet, I think even with nobody
using Aldor, it might be an advantage for finding some issues inside the
Algebra library.
Ralf
Waldek Hebisch
>
> >> real 26m50.752s
> >> user 18m1.080s
> >> sys 1m14.949s
>
> > user and sys time are sightly smaller than on my machine,
> > but real time is much bigger. It seems that Closure Cl
> > must be waiting for something, maybe it access files on
> > NFS?
>
> Certainly not. That's a laptop and has no access to NFS. Everything done
> on the local harddisk (no SSD). If you have an idea where to monitor
> what caused that long time, I'd be very grateful.
Well, you can try:
stat src/algebra/stamp* stamp
That will tell you when various stamp files were created, so
how much time different stages take. That may find a suspect.
Another possiblity is 'oprofile' -- it tells you which programs
take time, so you may spot some unexpected activity.
BTW: I assume that you redirect output to a file. Otherwise
scrolling in terminal can eat quite a lot of CPU time
(which shows in system load, but since terminal is speparate
from build it does not show in report from time).
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
Intel(R) Core(TM) i7-2720QM CPU @ 2.20GHz
time make -j8 > make.log 2>&1
fricas r1281
real 22m48.962s
user 64m39.758s
sys 7m38.869s
libaxiom.al
real 6m21.827s
user 37m42.145s
sys 4m12.572s
-- simple.as:
#include "axiom"
#pile
dd1: with
f: ()->Integer
== add
f():Integer == 1
compiles fine and f() correctly returns 1.
So ECL is back in the good list.
compilation of gcl clisp ccl ecl sbcl
fricas good good good good good
libaxiom.al bad good good good good
compile simple.as --- good good good good
run f() --- bad bad good good
Ralf
Dima Pasechnik
[....]
;;; Loading "/tmp/fricas/src/lisp/fricas-lisp.lisp"
#P"/tmp/fricas/src/lisp/fricas-lisp.lisp"
>
#<"FRICAS-LISP" package>
FRICAS-LISP>
;;;
;;; Compiling fricas-package.lisp.
;;; OPTIMIZE levels: Safety=1, Space=0, Speed=3, Debug=0
;;;
;;; End of Pass 1.
;;; Internal error:
;;; ** Unable to find include directory
NIL
[...]
Waldek Hebisch
>
> Currently fricas optional package (fricas 1.0.9, quite old) on Sage does
> not install; probably due to Sage having ECL 11.1.1.
> Actually, fricas from svn also does not build with ECL 11.1.1.
> One gets lisp errors, as follows:
>
This message stayed about 10 days in mail queue. IIUC the problem
(at least with current svn) is now resolved.
--
Waldek Hebisch
heb...@math.uni.wroc.pl