Ralf Hemmecke wrote:
> Yep. The attached patch fixes the issue with Matrix/TwoDimensionalArray
> and also makes the aldor-interface work again.
>
> Waldek, I've not checked regressioin yet, but I don't expect any problem.
>
Looks OK. Please commit after tests.
--
Or is it because matrix was called? Should it be more like this?
-- Distance weights between nodes.
weightedDistanceMatrix(s:%):TwoDimensionalArray WEIGHT ==
arr := new(#(getVertices s),#(getVertices s),
0)$TwoDimensionalArray(WEIGHT)
for u in 1..#(getVertices s) repeat
for
On Thursday 16 Feb 2012 08:34:03 Martin Baker wrote:
> On Thursday 16 Feb 2012 08:05:00 Ralf Hemmecke wrote:
> > cp: cannot stat `WGRPH.NRLIB/WGRPH.fasl': No such file or directory
> > make[4]: ***
> > [/home/hemmecke/g/fricas-bisect/b/target/x86_64-unknown-linux/algebra/WGR
> > PH .fasl] Error 1
>
On Thursday 16 Feb 2012 08:05:00 Ralf Hemmecke wrote:
> cp: cannot stat `WGRPH.NRLIB/WGRPH.fasl': No such file or directory
> make[4]: ***
> [/home/hemmecke/g/fricas-bisect/b/target/x86_64-unknown-linux/algebra/WGRPH
> .fasl] Error 1
> make[4]: Leaving directory
> `/home/hemmecke/v/git/fricas-bisec
On 10/19/2009 05:32 PM, Bill Page wrote:
> Ralf,
>
> Apparently the Aldor interface build uses lisp trace and the changes
> discussed here on another thread about preventing infinite loops and
> limiting the output of the )trace command break this process. Have I
> understood correctly that the o
> The attached patch modifies configure.ac so that Aldor
> interface will be built only when '--enable-aldor' is
> given.
OK. Commit.
Ralf
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra
> OK to commit. Concerning 'configure': I can regenerate 'configure'
> using autoconf 2.61 and commit the patch.
Ooops, I think, I've forgotten to update the ChangeLog. I'll post a new
patch on top of r676 without configure but with ChangeLog shortly...
Ralf
--~--~-~--~~--
Ralf Hemmecke wrote:
>
> Hi Waldek,
>
> also Bill has managed to compile with my patch
>
> http://sage.math.washington.edu/home/hemmecke/pub/fricas-aldor-interface.patch
>
> Do you allow me to commit?
> There is only one problem, you are using autoconf 2.61 while I only have
> 2.63 available.
On Mon, Sep 7, 2009 at 4:02 PM, Ralf Hemmecke wrote:
>
>> $ ./sage -f fricas-1.0.7.spkg
>>
>> Produces the error: " undefined reference to `log' ". (about 15 minutes)
>>
>> After the failure, follow the instructions printed by Sage to enter
>> the Sage "shell" - the environment in which Sage and a
> $ ./sage -f fricas-1.0.7.spkg
>
> Produces the error: " undefined reference to `log' ". (about 15 minutes)
>
> After the failure, follow the instructions printed by Sage to enter
> the Sage "shell" - the environment in which Sage and all it's spkg's
> run. As indicated 'cd' to the fricas-1.0.7
Ralf,
On Fri, Sep 4, 2009 at 5:32 PM, Ralf Hemmecke wrote:
>
> So, I've done
>
> sage -i -s http://sage.math.washington.edu/home/ghitza/ecl-9.8.4.spkg
>
> and then again
>
> sage -f fricas-1.0.7.spkg
>
> But, Bill, different from your error message
>
>> Produces the error: " undefined reference t
So, I've done
sage -i -s http://sage.math.washington.edu/home/ghitza/ecl-9.8.4.spkg
and then again
sage -f fricas-1.0.7.spkg
But, Bill, different from your error message
> Produces the error: " undefined reference to `log' ". (about 15 minutes)
(which appeared after about 45 min --- interest
Ralf,
On Thu, Sep 3, 2009 at 5:32 PM, Ralf Hemmecke wrote:
>
> On 09/03/2009 02:48 PM, Bill Page wrote:
>> I am sorry, I don't the logs to send but if you have any problems with
>> the instructions below, then I can reproduce and send them later.
>>
>> Assuming that you already have Aldor and Sag
Hi Bill,
On 09/03/2009 02:48 PM, Bill Page wrote:
> Ralf,
>
> I am sorry, I don't the logs to send but if you have any problems with
> the instructions below, then I can reproduce and send them later.
>
> Assuming that you already have Aldor and Sage installed, the commends:
>
> $ cd ~/sage-4.
Ralf,
I am sorry, I don't the logs to send but if you have any problems with
the instructions below, then I can reproduce and send them later.
Assuming that you already have Aldor and Sage installed, the commends:
$ cd ~/sage-4.1.1
$ wget http://www.mediafire.com/file/im5zd201mh0/fricas-1.0.7.p
> But after including '-lm' it fails again with the following error:
Bill, could you send me the exact list of commands to arrive at this
error. Maybe you even have the full log of this 'make'.
Are you sure that you have the files lang.as etc. from the Aldor.org
server? Actually these files c
Ralf,
I just completed a full compile of FriCAS rev. 666 from source with
ECL 9.8.4 including the Aldor interface. It finished with no problems
and seems to run fine.
So what is failing at the moment seems to be building the Aldor
interface from a *cached lisp* distribution created with:
../fri
Bill Page writes:
> On Mon, Aug 31, 2009 at 12:26 PM, Aleksej Saushev wrote:
>> I maintain FriCAS package and use mostly ECL.
>>
>
> What version(s) have ECL have you used?
9.8.4 is the last one.
> What operating system: Debian?, SuSE?, Windows?
My primary platforms are NetBSD and FreeBSD, ot
I wrote:
>
> Bill Page wrote:
> >
> > I think Waldek regularly builds FriCAS using ECL. I hope he will comment.
> >
>
> ATM I am not up to date concerning ECL.
I have now tried ECL-9.8.4. On 64-bit Fedora 9 FriCAS revision 666
builds fine using this version of ECL. There are a few extra
test
Bill Page wrote:
>
> I think Waldek regularly builds FriCAS using ECL. I hope he will comment.
>
ATM I am not up to date concerning ECL. The newset ECL is 9.8.4.
I did not try this version, but Juan Jose Garcia-Ripoll
(the ECL developer) tried and FriCAS builds fine. This was
ECL 9.8.4 on 64 b
On Mon, Aug 31, 2009 at 12:26 PM, Aleksej Saushev wrote:
>
> Ralf Hemmecke writes:
>
>>> I am sure that the Aldor-interface used to build with GCL. But rather
>>> than invest time to continue to support it maybe it would be better to
>>> try to make sure that the Aldor interface will build with EC
Ralf Hemmecke writes:
>> I am sure that the Aldor-interface used to build with GCL. But rather
>> than invest time to continue to support it maybe it would be better to
>> try to make sure that the Aldor interface will build with ECL.
>
> OK, I'll look at that as soon as possible. Which ECL vers
On Mon, Aug 31, 2009 at 11:01 AM, Ralf Hemmecke wrote:
>
>> I am sure that the Aldor-interface used to build with GCL. But rather
>> than invest time to continue to support it maybe it would be better to
>> try to make sure that the Aldor interface will build with ECL.
>
> OK, I'll look at that as
> I am sure that the Aldor-interface used to build with GCL. But rather
> than invest time to continue to support it maybe it would be better to
> try to make sure that the Aldor interface will build with ECL.
OK, I'll look at that as soon as possible. Which ECL version should I take?
Didn't I o
Ralf,
On Mon, Aug 31, 2009 at 6:10 AM, you wrote:
>
> Hi Bill,
>
> I've tried to build FriCAS with Aldor with GCL and failed on Ubuntu
> 9.04. I don't know about the status of GCL and don't even know whether
> I should invest time to make the Aldor-Interface working also with GCL?
> Isn't SBCL be
Hi Bill,
I've tried to build FriCAS with Aldor with GCL and failed on Ubuntu
9.04. I don't know about the status of GCL and don't even know whether I
should invest time to make the Aldor-Interface working also with GCL?
Isn't SBCL better?
Ralf
On 08/28/2009 08:46 PM, Bill Page wrote:
> Is an
Franz,
Thanks! I can confirm that the Aldor interface builds properly using
wsp...@debian:~$ sbcl
This is SBCL 1.0.18.debian, an implementation of ANSI Common Lisp.
---
Installed via apt-get from the standard Debian Lenny repositories.
Conclusion: Don't use the Debian Lenny binary distributi
On Fri, Aug 28, 2009 at 06:18:46PM -0400, Bill Page wrote:
> What flavor and version of Lisp are you using?
sbcl 1.0.13 and 1.0.20
regards,
Franz
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"FriCAS - computer al
Franz,
What flavor and version of Lisp are you using?
On Fri, Aug 28, 2009 at 4:57 PM, you wrote:
>
> On Fri, Aug 28, 2009 at 02:46:55PM -0400, Bill Page wrote:
>> Is anyone able to build the Aldor interface with a recent revision of FriCAS?
> yes, doing the hash patch for 64bit it works up to r
On Fri, Aug 28, 2009 at 02:46:55PM -0400, Bill Page wrote:
> Is anyone able to build the Aldor interface with a recent revision of FriCAS?
yes, doing the hash patch for 64bit it works up to rev 665 at least.
Both debian etch and lenny on amd64 work for me with aldor 1.1.0.
regards,
Franz
--~--~-
Dear Mike, dear Stephen,
is there be some quick way of solving the problem of having to download
the aldor files
https://svn.origo.ethz.ch/algebraist/trunk/aldor/lib/libax0/axiom.as
https://svn.origo.ethz.ch/algebraist/trunk/aldor/lib/libax0/axextend.as
https://svn.origo.ethz.ch/algebraist/trun
Ralf Hemmecke wrote:
>
> Hello,
>
> here is a patch that should allow to download the aldor interface files
> at configure time.
>
> Please tell me whether you like it or not. If it is OK, I will modify
> src/aldor/Makefile.in to work with that patch, i.e. assume that the
> aldor files are a
On 09/13/2008 04:16 PM, Martin Rubey wrote:
> Ralf Hemmecke <[EMAIL PROTECTED]> writes:
>
> Second: sbcl and especially ecl like it much better if you compile the lsp
> files generated with the aldor compiler
What does that mean?
>>> ecl complains about "too large jump" in aldor-comb
Ralf Hemmecke <[EMAIL PROTECTED]> writes:
> >>> Second: sbcl and especially ecl like it much better if you compile the lsp
> >>> files generated with the aldor compiler
> >> What does that mean?
> >
> > ecl complains about "too large jump" in aldor-combinat, unless you compile
> > the
> > files
>>> Second: sbcl and especially ecl like it much better if you compile the lsp
>>> files generated with the aldor compiler
>> What does that mean?
>
> ecl complains about "too large jump" in aldor-combinat, unless you compile the
> files. sbcl is *much* faster on compiled files.
Does that just m
Ralf Hemmecke <[EMAIL PROTECTED]> writes:
> > I dared to merge the aldor interface - along with the modifications to
> > foam_l.lisp we already talked about and some trivial modifications to the
> > makefiles to make it work with ecl.
> >
> > Ralf, I hope you don't mind, I just couldn't wait any
On 09/04/2008 10:15 PM, Martin Rubey wrote:
> Dear all, especially Ralf!
>
> Waldek Hebisch <[EMAIL PROTECTED]> writes:
>
>> There will be _some_ interaction (also with other changes). We will need to
>> handle it sooner or later. Sooner is better because we still have some time
>> to next rel
Waldek Hebisch <[EMAIL PROTECTED]> writes:
> > > Hopefully this fixes Aldor problem, but I can not test with Aldor now.
> >
> > Unfortunately, it doesn't seem to. Although, there is a slight chance that
> > it does, because I missed boo-nilcat.spad and coerce.spad.pamphlet.
> >
> > It fails al
Martin Rubey wrote:
>
> Waldek Hebisch <[EMAIL PROTECTED]> writes:
>
> > I wrote:
> > > If you agree that
> > >
> > > Foo(): Category == with ()
> > >
> > > is the right syntax for empty category, then the following
> > > patch has good chance of working.
> >
> > Now complete patch which comp
Waldek Hebisch <[EMAIL PROTECTED]> writes:
> I wrote:
> > If you agree that
> >
> > Foo(): Category == with ()
> >
> > is the right syntax for empty category, then the following
> > patch has good chance of working.
>
> Now complete patch which completely eliminates 'ATTRIBUTE |nil|'
> Passed
On Mon, Sep 8, 2008 at 6:03 PM, Waldek Hebisch wrote:
>
> Bill Page wrote:
>>
>> Or look at it this way: Let C be a set of categories. The set of
>> domains that satisfies Join(C) is the intersection taken over sets
>> of domains that satisfy each of the categories in C. If C is the
>> empty set,
I wrote:
> If you agree that
>
> Foo(): Category == with ()
>
> is the right syntax for empty category, then the following
> patch has good chance of working.
Now complete patch which completely eliminates 'ATTRIBUTE |nil|'
Passed normal test. Hopefully this fixes Aldor problem, but
I can not
Bill Page wrote:
>
> On Sun, Sep 7, 2008 at 11:46 PM, Waldek Hebisch wrote:
> >
> > If you say that 'Dom has Cat' Dom must satisfy Cat, but may satisfy
> > more. In other words 'Dom has Join()' is valid for for any domain.
> >
>
> I agree that it is valid. I am only arguing that it must return
On Sun, Sep 7, 2008 at 11:46 PM, Waldek Hebisch wrote:
>
> If you say that 'Dom has Cat' Dom must satisfy Cat, but may satisfy
> more. In other words 'Dom has Join()' is valid for for any domain.
>
I agree that it is valid. I am only arguing that it must return False
for all domains.
>> Join(..
Martin Rubey wrote:
>
> Waldek Hebisch <[EMAIL PROTECTED]> writes:
>
> > If you do
> >
> > )lisp (setf |$PrintOnly| t)
>
> great!
>
> > you will see output from the parser. Empty category gives (besides
> > junk about loading):
> >
> > "Foo(): Category == with nil " =>
> > (DEF (|Foo|
[ Charset ISO-8859-1 unsupported, converting... ]
>
> On Sun, Sep 7, 2008 at 7:16 PM, Waldek Hebisch wrote:
> >
> > Bill Page wrote:
> > ...
> >> But domains do not belong to categories except by explicit declaration
> >> with the special exception of Type.
> >>
> >
> > Yes, "empty category" is c
On Sun, Sep 7, 2008 at 7:16 PM, Waldek Hebisch wrote:
>
> Bill Page wrote:
> ...
>> But domains do not belong to categories except by explicit declaration
>> with the special exception of Type.
>>
>
> Yes, "empty category" is category with no exports.
>
>> I do not think that Join() could be equal
Bill Page wrote:
>
> On Sun, Sep 7, 2008 at 4:51 PM, Waldek Hebisch wrote:
> >
> > I wrote:
> >>
> >> Well, I agree that we should have better syntax for empty
> >> categories.
> >>
> >> I would prefer one of the following:
> >>
> >> Foo(): Category == with ()
> >>
> >> or
> >>
> >> Foo(): Catego
On Sun, Sep 7, 2008 at 4:51 PM, Waldek Hebisch wrote:
>
> I wrote:
>>
>> Well, I agree that we should have better syntax for empty
>> categories.
>>
>> I would prefer one of the following:
>>
>> Foo(): Category == with ()
>>
>> or
>>
>> Foo(): Category == Join()
>>
>> The second works in the parse
I wrote:
>
> Well, I agree that we should have better syntax for empty categories.
>
> I would prefer one of the following:
>
> Foo(): Category == with ()
>
> or
>
> Foo(): Category == Join()
>
> The second works in the parser, but crashes later.
>
Actually, looking at semantics the second fo
Martin Rubey wrote:
>
> Waldek Hebisch <[EMAIL PROTECTED]> writes:
>
> > If you do
> >
> > )lisp (setf |$PrintOnly| t)
>
> great!
>
> > you will see output from the parser. Empty category gives (besides
> > junk about loading):
> >
> > "Foo(): Category == with nil " =>
> > (DEF (|Foo|
Martin Rubey wrote:
>
> Martin Rubey <[EMAIL PROTECTED]> writes:
>
> > Waldek Hebisch <[EMAIL PROTECTED]> writes:
> >
> > > 3) try to change CONSTRUCTORCATEGORY to '(|Join| (CATEGORY |package|))'
> > >I am not sure if this has some other bad consequences, but if
> > >that works it would
Waldek Hebisch <[EMAIL PROTECTED]> writes:
> If you do
>
> )lisp (setf |$PrintOnly| t)
great!
> you will see output from the parser. Empty category gives (besides
> junk about loading):
>
> "Foo(): Category == with nil " =>
> (DEF (|Foo|) ((|Category|)) (NIL) (CATEGORY |package| (ATTRI
Martin Rubey <[EMAIL PROTECTED]> writes:
> Martin Rubey <[EMAIL PROTECTED]> writes:
>
> > Waldek Hebisch <[EMAIL PROTECTED]> writes:
> >
> > > 3) try to change CONSTRUCTORCATEGORY to '(|Join| (CATEGORY |package|))'
> > >I am not sure if this has some other bad consequences, but if
> > >
Martin Rubey wrote:
>
> Waldek Hebisch <[EMAIL PROTECTED]> writes:
>
> > 3) try to change CONSTRUCTORCATEGORY to '(|Join| (CATEGORY |package|))'
> >I am not sure if this has some other bad consequences, but if
> >that works it would be the best solution.
>
> I have no idea where CONSTRU
Martin Rubey <[EMAIL PROTECTED]> writes:
> Waldek Hebisch <[EMAIL PROTECTED]> writes:
>
> > 3) try to change CONSTRUCTORCATEGORY to '(|Join| (CATEGORY |package|))'
> >I am not sure if this has some other bad consequences, but if
> >that works it would be the best solution.
>
> I have no
Waldek Hebisch <[EMAIL PROTECTED]> writes:
> 3) try to change CONSTRUCTORCATEGORY to '(|Join| (CATEGORY |package|))'
>I am not sure if this has some other bad consequences, but if
>that works it would be the best solution.
I have no idea where CONSTRUCTORCATEGORY is set. I see setdataba
Martin Rubey wrote:
>
> Dear Waldek,
>
> the latest revision fails to build the aldor interface (both gcl and sbcl
> fail). I'm unable to check right now...would be great if you could. Below
> the
> tail:
>
> Martin
>
> aldor -Wname=axiom -Mno-abbrev -Mpreview -Y al -L AxiomLib=axiom_ATCS
Dear all, especially Ralf!
Waldek Hebisch <[EMAIL PROTECTED]> writes:
> There will be _some_ interaction (also with other changes). We will need to
> handle it sooner or later. Sooner is better because we still have some time
> to next release.
I dared to merge the aldor interface - along wit
Martin Rubey wrote:
>
> Waldek Hebisch <[EMAIL PROTECTED]> writes:
>
> > I will spent next few days off-line, please go on with the merge without
> > waiting for me.
>
> I just realized one thing: it might be that converting the attributes to
> Categories affects the aldor interface.
>
> Shoul
Waldek Hebisch <[EMAIL PROTECTED]> writes:
> I will spent next few days off-line, please go on with the merge without
> waiting for me.
I just realized one thing: it might be that converting the attributes to
Categories affects the aldor interface.
Should we still merge now?
Martin
--~--~---
Martin Rubey wrote:
>
> A propos moving forward: I'd like to merge the aldor interface done by Ralf
> into trunk. With the patch below against the latest revision of the
> aldor-interface branch, I and Franz Lehner were able to build it successfully
> on linux with
>
> gcl, ecl and sbcl 32 bit,
62 matches
Mail list logo
