[sage-devel] Re: Project

[mabshoff]

On Apr 22, 7:36 am, "Bill Page" <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 21, 2008 at 9:03 AM, William Stein wrote:

Hello folks,

> > ...
> >  In the defense of GCL, *most* components of Sage were a mess

gcl is in way more of a mess than any other component in Sage I can
imagine. But then I wasn't around in the early days of Sage ;)

> >  like above when I/you/whoever first tried to add them to Sage.
> >  I personally haven't tried much using cvs GCL only, partly because
> >  it scares me to use cvs for a deployed quality product.  Since cvs
> >  might be broken one day, not the next, etc., and one has no clue
> >  if the code has been tested or not or what.  The last released
> >  version is from 2005, and it's clear the website is just dead (maybe
> >  somebody lost the password?!)  I mean, it just looks a little silly
> >  for the website (http://www.gnu.org/software/gcl/) to start with:
> >    NEW! (20050810) GCL 2.6.7 is released. The release notes can
> >       be found  here.
> > ...
> > The GCL-devel mailing list has on average about 5-6 messages
> > a month during the last couple of months, except for a bunch of
> > messages in January about people trying to build GCL from cvs.
>
> No doubt about it - GCL does not have sufficient resources for
> maintenance and has been somewhat neglected of late. As you say: It is
> not a situation that you find entirely uncommon among the packages
> that have been added to Sage in the past. Necessity is what drives
> most of this kind of work.
>
> >  I've made a gcl Sage optional spkg:
>
> >    http://sage.math.washington.edu/home/was/tmp/gcl/gcl-20080421.spkg
>
> >  It's just GCL-from-cvs + a simple spkg-install.  I have never got it to
> >  build on any system.   It's a pretty big spkg, since it appears to
> >  include the entire gas assembler, some version of GMP, etc.  Try
> >  it out and see if it *doesn't* work for you too :-)
>
> >    wgethttp://sage.math.washington.edu/home/was/tmp/gcl/gcl-20080421.spkg
> >    sage -i gcl-20080421.spkg
>
> Thanks. It doesn't work for me either. :-(
>
> You are right that the source is bloated by a bunch of code that it
> does not use. As I understand it gcl needs only a small part of
> binutils - depending on the build options for a particular system.
>
> Is this source from cvs head at:
>
>  http://savannah.gnu.org/projects/gcl/
>
> as of today?

Yes.

> This version of GCL fails on my Solaris x86 system with the following
> obscure error message:
>
> gcc -c -fsigned-char -pipe -Wall  -O3 -fomit-frame-pointer  
> -I/export/home0/wspa
> ge/gcl-sage/gcl-20080421/src/o -I../h -I../gcl-tk cmpaux.c
> cmpaux.c: In function `object_to_fcomplex':
> cmpaux.c:329: error: `_Imaginary_I' undeclared (first use in this function)
> cmpaux.c:329: error: (Each undeclared identifier is reported only once
> cmpaux.c:329: error: for each function it appears in.)
> cmpaux.c: In function `object_to_dcomplex':
> cmpaux.c:366: error: `_Imaginary_I' undeclared (first use in this function)
> gmake[1]: *** [cmpaux.o] Error 1
> rm list.c
> gmake[1]: Leaving directory `/export/home0/wspage/gcl-sage/gcl-20080421/src/o'
> gmake: *** [unixport/saved_pre_gcl] Error 2

That is an issue most likely with complex.h - IIRC _Imaginary_I is
part of the Sun's libc or libm - I would need to check.

> ---
>
> At 'http://cvs.savannah.gnu.org/viewvc/gcl/?root=gcl'I see changes as
> recent as 3 months ago. The last time I built GCL from head was about
> 10 months ago.

I tried 8 months or so ago and then roughly 4 months or so ago, both
times with disastrous results.

> The most recent branch 'Version_2_6_8pre' is what we normally use to
> build Axiom. There is a change about 4 months old. If I recall
> correctly 'Version_2_6_8pre' actually corresponds to the version
> distributed on Debian and would probably be the most likely to be
> stable on the largest number of platforms.

At least testing ships CVS head. And not to be too picky here: The
last tarball from the website predates OSX 10.5 and also Solaris 10,
so maybe it is time to cut another bug fix release since everybody
seems to be using 2.6.8CVS anyway. But when I build stable releases I
do not poke around in the CVS repo. Asking could have helped, but if
nobody bothered to update the website in three years anyway what is
the point? 2.6.7 actually also miserably fails on Solaris 9 for me,
and that has been out for a while before 2.6.7.

> >  Bill Page -- I would be interested in any comments you might have.
> >  For example, is the fact that GCL doesn't build for us anywhere,
> &

[sage-devel] Sage 3.0 is out

[mabshoff]

Hello folks,

Sage 3.0 has been released on April 21st, 2008. It is available at

   http://sagemath.org/download.html

* About Sage (http://www.sagemath.org)

Sage is developed by volunteers and combines 71 open source packages.
It is available for download from sagemath.org and its mirrors in
source or binary form. If you have any questions and/or problems
please report them to the google groups sage-devel or sage-support.
You can also drop by in #sage-devel or #sage-support in freenode.

-

This is the "Sources only" release. We are building binaries right now
and once those are done we will officially announce in roughly a day.
Upgrades should work will small problems in the scripts repo - we will
fix those hopefully by morning. If you had features integrated please
add them to

http://wiki.sagemath.org/sage-3.0

I just check and Carl Witty did his job, so maybe you should get to
work ;)

Cheers,

Michael Abshoff (Release Chair), William Stein

Merged in final:

#2979: Michael Abshoff, Andrzej Giniewicz: force "-O0" for
   clisp with gcc 4.3
#2987: Tim Abbott: Debian build support for zn_poly
#2988: William Stein: notebook -- issues with the CSS for the
   print display
#2989: William Stein: notebook -- issue with how the notebook
   is run that breaks it sometimes; also fix a typo in pid.
#2990: William Stein: sage-3.0.rc1: calculus/functions.py
   segfault on debian64 xeon vmware image
#2991: William Stein: fix dsage testdoc problem
#2994: Michael Abshoff: polybori.spkg - fix permission issue
   of the headers

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] East Coast Computer Algebra Day

[TimDaly]

On Saturday, May 10, the next East Coast Computer Algebra Day is being
held.
The contributors to Sage might find it an interesting meeting.


I know that Sage sent a student last year.

Tim
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Project

[Bill Page]

On Mon, Apr 21, 2008 at 9:03 AM, William Stein wrote:
> ...
>  In the defense of GCL, *most* components of Sage were a mess
>  like above when I/you/whoever first tried to add them to Sage.
>  I personally haven't tried much using cvs GCL only, partly because
>  it scares me to use cvs for a deployed quality product.  Since cvs
>  might be broken one day, not the next, etc., and one has no clue
>  if the code has been tested or not or what.  The last released
>  version is from 2005, and it's clear the website is just dead (maybe
>  somebody lost the password?!)  I mean, it just looks a little silly
>  for the website (http://www.gnu.org/software/gcl/) to start with:
>NEW! (20050810) GCL 2.6.7 is released. The release notes can
>   be found  here.
> ...
> The GCL-devel mailing list has on average about 5-6 messages
> a month during the last couple of months, except for a bunch of
> messages in January about people trying to build GCL from cvs.
>

No doubt about it - GCL does not have sufficient resources for
maintenance and has been somewhat neglected of late. As you say: It is
not a situation that you find entirely uncommon among the packages
that have been added to Sage in the past. Necessity is what drives
most of this kind of work.

>  I've made a gcl Sage optional spkg:
>
>http://sage.math.washington.edu/home/was/tmp/gcl/gcl-20080421.spkg
>
>  It's just GCL-from-cvs + a simple spkg-install.  I have never got it to
>  build on any system.   It's a pretty big spkg, since it appears to
>  include the entire gas assembler, some version of GMP, etc.  Try
>  it out and see if it *doesn't* work for you too :-)
>
>wget http://sage.math.washington.edu/home/was/tmp/gcl/gcl-20080421.spkg
>sage -i gcl-20080421.spkg
>

Thanks. It doesn't work for me either. :-(

You are right that the source is bloated by a bunch of code that it
does not use. As I understand it gcl needs only a small part of
binutils - depending on the build options for a particular system.

Is this source from cvs head at:

  http://savannah.gnu.org/projects/gcl/

as of today?

This version of GCL fails on my Solaris x86 system with the following
obscure error message:

gcc -c -fsigned-char -pipe -Wall  -O3 -fomit-frame-pointer  -I/export/home0/wspa
ge/gcl-sage/gcl-20080421/src/o -I../h -I../gcl-tk cmpaux.c
cmpaux.c: In function `object_to_fcomplex':
cmpaux.c:329: error: `_Imaginary_I' undeclared (first use in this function)
cmpaux.c:329: error: (Each undeclared identifier is reported only once
cmpaux.c:329: error: for each function it appears in.)
cmpaux.c: In function `object_to_dcomplex':
cmpaux.c:366: error: `_Imaginary_I' undeclared (first use in this function)
gmake[1]: *** [cmpaux.o] Error 1
rm list.c
gmake[1]: Leaving directory `/export/home0/wspage/gcl-sage/gcl-20080421/src/o'
gmake: *** [unixport/saved_pre_gcl] Error 2

---

At 'http://cvs.savannah.gnu.org/viewvc/gcl/?root=gcl' I see changes as
recent as 3 months ago. The last time I built GCL from head was about
10 months ago.

The most recent branch 'Version_2_6_8pre' is what we normally use to
build Axiom. There is a change about 4 months old. If I recall
correctly 'Version_2_6_8pre' actually corresponds to the version
distributed on Debian and would probably be the most likely to be
stable on the largest number of platforms.

>  Bill Page -- I would be interested in any comments you might have.
>  For example, is the fact that GCL doesn't build for us anywhere,
>  something that you think we'll get passed by just trying harder?
>  Or is it going to be really really hard.
>

The fact that it doesn't build for you anywhere is definitely strange.
I would give it a try again with

  $ cvs -z3 -d:pserver:[EMAIL PROTECTED]:/sources/gcl co
-r Version_2_6_8pre gcl

I do expect that (with the right help) you will be able to build gcl
everywhere that you build Sage. Instead of just trying harder I think
it is very appropriate to ask for help. Only if there is no help
forthcoming, perhaps I would agree that the problems might be of a
kind that you will not be able to get passed just by "trying harder".
I expect that like me, you would find the learning curve for the GCL
source code very high.

--

Now since you asked, maybe I should take a deep breath and try to
explain my personal views on this subject...

I am in fact fully sympathetic with the expressed desire to eliminate
Lisp from Sage. As you may know, I am also in favor of eliminating
Lisp from Axiom! I believe that was the direction in which Axiom was
headed when it was last sold as commercial software and would have
very much preferred it if that development had continued. The Aldor
compiler (written in C) was positioned to replace the exising library
compiler for Axiom. Aldor could be tar

[sage-devel] Re: Disable ENABLE_PADLOCK_SUPPORT?

[Rob Goedman]

It was released Aug last year?

It's GCC 4.2 Developer Preview 1 (from the Developer Connection |  
Member Site - http://connect.apple.com/ ).

It adds gcc-4.2 to gcc-4.0 included in Xcode.

Rob


On Apr 21, 2008, at 5:05 PM, William Stein wrote:

>
> On Mon, Apr 21, 2008 at 11:54 AM, Rob Goedman <[EMAIL PROTECTED]> wrote:
>>
>> This is XCode 3.0 with the updated gcc suite from the Apple developer
>> site. It sure seems to compile an awful lot before hitting this.
>
> How does one get the "updated gcc suite from the Apple Developer  
> site"?
> I just found http://developer.apple.com/tools/download/
> I absolutely can't find gcc-4.2.1 anywhere on the apple website,
> and it's definitely not included in XCode 3.0 as far as I can tell.
>
> Thanks.


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Project

[David Joyner]

Thank you very much for agreeing to work on this Michael.
Way down the road, thin will be a big deal i think.

On Mon, Apr 21, 2008 at 8:45 PM, mabshoff
<[EMAIL PROTECTED]> wrote:
>
>  William suggested I forward/post the stuff I wrote on fricas-devel
>  over there, too. Since his wish is my command ;) here we go:
>
>  On Apr 21, 9:46 pm, Robert Dodier <[EMAIL PROTECTED]> wrote:
>
>  > On Apr 20, 9:29 am, "William Stein" <[EMAIL PROTECTED]> wrote:
>
>  Hello folks,
>
>
>  > > c) ecls: the ray of hope? Bug Maxima can't be build on top of it due
>  > > to same issues with save and load image.
>
>  > Well, if there is any interest in resolving the problems,
>  > let's join forces then. I got Maxima compiled by ECLS some
>  > months ago; there were some problems but if there is enough
>  > interest, I would be willing to try again.
>
>  This is excellent news. As I wrote in this thread over on sage-devel I
>  am willing to put some serious time into getting ecls to build on
>  Sage's current and future supported platforms as well do serious
>  testing that Maxima works on top of it. And it certainly sounds like
>  FriCAS would not mind ecls being in Sage per default instead of clisp
>  since the clisp we shop seems to be too broken to support FriCAS.
>
>
>  > > The current plan is to rewrite symbolic manipulation in
>  > > Cython using lots of tricks so it will be very
>  > > fast, flexible, and not depend on Maxima at all.
>
>  > I have an agenda to push here, so you can take this with a grain
>  > of salt, but: Lisp was invented in part to do the kind of
>  > expression mogrification which is needed for symbolic
>  > algebra. A symbolic system written in some other language is
>  > probably going to replicate a lot of Lisp functionality.
>
>  > I am pretty sure that trying to get Maxima recompiled with
>  > some/any Lisp implementation will be easier than reinventing
>  > both Maxima and Lisp.
>
>  Well, we are looking at several problems here:
>
>  a) we use Maxima via pexpect, i.e. we dump some data into ASCII issue
>  some commands and parse the results. While that is something that
>  works well for say integrals or ODEs it is a huge performance drain on
>  arithmetic. For example: Moving some operation on permutation groups
>  form GAP+pexpect to Cython made the operation 4,000 times as fast. The
>  implementation in Cython is roughly 3 times slower than the same
>  operation in the GAP kernel, but since pexpect is out of the equation
>  the somewhat slower Cython implementation is a huge win since we have
>  not connected the GAP kernel to Sage as a library. Nobody has
>  attempted to do that, but it will likely be quite a bit of work and a
>  large effort.
>
>  b) Using Maxima in itself is not bad and the thread that started this
>  whole discussion was motivated by build issues with self hosted lisp.
>  Since Maxima is written in lisp and the only reason we ship lisp
>  currently with Sage my desire was to solve the lisp build problem and
>  Maxima would have ended up as potential road kill in the process.
>
>  c) Maxima has a lot of well debugged, well working code, but it seems
>  for many things the 4 Ms are much faster. Factorization is one
>  example, I am not quite clear how Integration compares, but my general
>  impression from alt.sci.symbolic is that it is not on par with the
>  commercial systems [feel free to correct me].
>
>  d) Sage itself wants to compete with the 4Ms, but it isn't the only
>  Open Source CAS out there, in fact it is a quite young effort and
>  William's method called for building on top of existing systems. But
>  while he went through what I call the "rapid expansion phase" it was
>  more important to get things working than to implement because doing
>  things "right" as you point out would take many, many man years of
>  effort. But now people are demanding more performance and due to (a)
>  symbolic arithmetic is being rewritten. And according to Gary [the guy
>  implementing it] it is much faster than Maxima [even accounting for
>  clisp vs. sbcl and so on]. I cannot verify the number but since he is
>  quite serious about the issue and he really, really *needs* fast
>  symbolics I have little reason to doubt him.
>
>  So, now the question is: "Why doesn't he work with the Maxima code
>  then and improve it there. Everybody would benefit [Sage & Maxima] and
>  all the higher level algorithms would likely get a boost by it." And
>  the answer is: Because he prefers not to use lisp and that is
>  something that is completely up to him. It is difficult to recruit
>  developers and most people in Sage prefer C/C++/Python/Cython over
>  list just like Maxima developers prefer lisp. Both camps are self
>  selecting, so no surprises there.
>
>  But to get back to the issue at hand: Once Maxima runs on ecls nearly
>  all the issues I have with the build side of things will likely
>  evaporate and I will put my energy toward other issues. It would
>  likely also lessen t

[sage-devel] Re: Project

[mabshoff]

William suggested I forward/post the stuff I wrote on fricas-devel
over there, too. Since his wish is my command ;) here we go:

On Apr 21, 9:46 pm, Robert Dodier <[EMAIL PROTECTED]> wrote:

> On Apr 20, 9:29 am, "William Stein" <[EMAIL PROTECTED]> wrote:

Hello folks,

> > c) ecls: the ray of hope? Bug Maxima can't be build on top of it due
> > to same issues with save and load image.

> Well, if there is any interest in resolving the problems,
> let's join forces then. I got Maxima compiled by ECLS some
> months ago; there were some problems but if there is enough
> interest, I would be willing to try again.

This is excellent news. As I wrote in this thread over on sage-devel I
am willing to put some serious time into getting ecls to build on
Sage's current and future supported platforms as well do serious
testing that Maxima works on top of it. And it certainly sounds like
FriCAS would not mind ecls being in Sage per default instead of clisp
since the clisp we shop seems to be too broken to support FriCAS.

> > The current plan is to rewrite symbolic manipulation in
> > Cython using lots of tricks so it will be very
> > fast, flexible, and not depend on Maxima at all.

> I have an agenda to push here, so you can take this with a grain
> of salt, but: Lisp was invented in part to do the kind of
> expression mogrification which is needed for symbolic
> algebra. A symbolic system written in some other language is
> probably going to replicate a lot of Lisp functionality.

> I am pretty sure that trying to get Maxima recompiled with
> some/any Lisp implementation will be easier than reinventing
> both Maxima and Lisp.

Well, we are looking at several problems here:

a) we use Maxima via pexpect, i.e. we dump some data into ASCII issue
some commands and parse the results. While that is something that
works well for say integrals or ODEs it is a huge performance drain on
arithmetic. For example: Moving some operation on permutation groups
form GAP+pexpect to Cython made the operation 4,000 times as fast. The
implementation in Cython is roughly 3 times slower than the same
operation in the GAP kernel, but since pexpect is out of the equation
the somewhat slower Cython implementation is a huge win since we have
not connected the GAP kernel to Sage as a library. Nobody has
attempted to do that, but it will likely be quite a bit of work and a
large effort.

b) Using Maxima in itself is not bad and the thread that started this
whole discussion was motivated by build issues with self hosted lisp.
Since Maxima is written in lisp and the only reason we ship lisp
currently with Sage my desire was to solve the lisp build problem and
Maxima would have ended up as potential road kill in the process.

c) Maxima has a lot of well debugged, well working code, but it seems
for many things the 4 Ms are much faster. Factorization is one
example, I am not quite clear how Integration compares, but my general
impression from alt.sci.symbolic is that it is not on par with the
commercial systems [feel free to correct me].

d) Sage itself wants to compete with the 4Ms, but it isn't the only
Open Source CAS out there, in fact it is a quite young effort and
William's method called for building on top of existing systems. But
while he went through what I call the "rapid expansion phase" it was
more important to get things working than to implement because doing
things "right" as you point out would take many, many man years of
effort. But now people are demanding more performance and due to (a)
symbolic arithmetic is being rewritten. And according to Gary [the guy
implementing it] it is much faster than Maxima [even accounting for
clisp vs. sbcl and so on]. I cannot verify the number but since he is
quite serious about the issue and he really, really *needs* fast
symbolics I have little reason to doubt him.

So, now the question is: "Why doesn't he work with the Maxima code
then and improve it there. Everybody would benefit [Sage & Maxima] and
all the higher level algorithms would likely get a boost by it." And
the answer is: Because he prefers not to use lisp and that is
something that is completely up to him. It is difficult to recruit
developers and most people in Sage prefer C/C++/Python/Cython over
list just like Maxima developers prefer lisp. Both camps are self
selecting, so no surprises there.

But to get back to the issue at hand: Once Maxima runs on ecls nearly
all the issues I have with the build side of things will likely
evaporate and I will put my energy toward other issues. It would
likely also lessen the drive to "get rid of Maxima" considerably, but
I am certain that over the next couple years more and more
functionality that Maxima provides by Sage will be implemented on top
of other systems unless Maxima gets faster. Systems inside Sage
compete and it would be naive to believe that Sage does not compete
will all its components for users as well as developers. But in the
end Sage is supposed to be inclusive and shou

[sage-devel] Re: Disable ENABLE_PADLOCK_SUPPORT?

[William Stein]

On Mon, Apr 21, 2008 at 11:54 AM, Rob Goedman <[EMAIL PROTECTED]> wrote:
>
>  This is XCode 3.0 with the updated gcc suite from the Apple developer
>  site. It sure seems to compile an awful lot before hitting this.

How does one get the "updated gcc suite from the Apple Developer site"?
I just found http://developer.apple.com/tools/download/
I absolutely can't find gcc-4.2.1 anywhere on the apple website,
and it's definitely not included in XCode 3.0 as far as I can tell.

Thanks.

>
>  I wonder how to make this work with R. R has these 100s of packages,
>  many of which need to be compiled when installed.
>
>  Right now, at least on the Mac, R-2-7 itself supports/contains 4
>  architectures ( ppc, x86 each 32 and 64 bits ) and the compilers for
>  c, c++ and fortran need to match for above package installations
>  (those that need to be compiled). Until recently there were disastrous
>  bugs in the compilers for 64 bits (and other issues with gcc4.0, e.g.
>  when fortran was involved).
>
>  Sage rc1 seems to include R-2.6.1, this week's R-2.7 release will
>  replace R-2.6.2.
>
>  I have tried gcc-4.0.1 but on my system it will hang forever (might be
>  related to the broken X11 that ships with Leopard):

I've built Sage with gcc-4.0.1 many times on many flavors of OS X...

>
>  gcc -bundle -undefined dynamic_lookup build/temp.macosx-10.3-i386-2.5/
>  Users/rob/Downloads/sage-3.0.rc1/spkg/build/python-2.5.2/src/Mac/
>  Modules/launch/_Launchmodule.o -L/Users/rob/Downloads/sage-3.0.rc1/
>  local/lib -L/usr/local/lib -o build/lib.macosx-10.3-i386-2.5/
>  _Launch.so -framework ApplicationServices
>  *** WARNING: renaming "_Launch" since importing it failed:
>  dlopen(build/lib.macosx-10.3-i386-2.5/_Launch.so, 2): Symbol not
>  found: __cg_png_create_info_struct
>Referenced from: /System/Library/Frameworks/
>  ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/
>  Versions/A/ImageIO
>Expected in: /usr/X11R6/lib/libPng.dylib
>
>  building '_CG' extension
>  creating build/temp.macosx-10.3-i386-2.5/Users/rob/Downloads/
>  sage-3.0.rc1/spkg/build/python-2.5.2/src/Mac/Modules/cg
>  gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-
>  madd -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/Users/
>  rob/Downloads/sage-3.0.rc1/spkg/build/python-2.5.2/src/./Include -I/
>  Users/rob/Downloads/sage-3.0.rc1/spkg/build/python-2.5.2/src/./Mac/
>  Include -I/Users/rob/Downloads/sage-3.0.rc1/local/include -I. -
>  IInclude -I./Include -I/usr/local/include -I/Users/rob/Downloads/
>  sage-3.0.rc1/spkg/build/python-2.5.2/src/Include -I/Users/rob/
>  Downloads/sage-3.0.rc1/spkg/build/python-2.5.2/src -c /Users/rob/
>  Downloads/sage-3.0.rc1/spkg/build/python-2.5.2/src/Mac/Modules/cg/
>  _CGmodule.c -o build/temp.macosx-10.3-i386-2.5/Users/rob/Downloads/
>  sage-3.0.rc1/spkg/build/python-2.5.2/src/Mac/Modules/cg/_CGmodule.o -
>  Wno-deprecated-declarations
>  gcc -bundle -undefined dynamic_lookup build/temp.macosx-10.3-i386-2.5/
>  Users/rob/Downloads/sage-3.0.rc1/spkg/build/python-2.5.2/src/Mac/
>  Modules/cg/_CGmodule.o -L/Users/rob/Downloads/sage-3.0.rc1/local/lib -
>  L/usr/local/lib -o build/lib.macosx-10.3-i386-2.5/_CG.so -framework
>  ApplicationServices
>
>  and it will never finish this step.
>
>  My hope is that I can literally use either R.app to work with R and
>  its libraries and Sage notebooks using the same version of R and
>  libraries. Maybe the way Sage works with Mathematica?

Yes, that is certainly going to be possible with Sage-3.0.  It is one
of the main new features.

>
>  As MIchael suggested, 3.0.1 stuff!
>
>  Rob
>
>
>
>
>  On Apr 21, 2008, at 9:54 AM, William Stein wrote:
>
>  >
>  > On Mon, Apr 21, 2008 at 9:31 AM, Rob Goedman <[EMAIL PROTECTED]> wrote:
>  >> Hi,
>  >>
>  >> Brand new to Sage builds!
>  >>
>  >> On Mac OS 10.5.2, with:
>  >>
>  >> Robs-Intel:sage-3.0.rc0 rob$ gcc -v
>  >> Using built-in specs.
>  >> Target: i686-apple-darwin9
>  >> Configured with: /var/tmp/gcc_42/gcc_42-5531~1/src/configure --
>  >> disable-
>  >> checking -enable-werror --prefix=/usr --mandir=/usr/share/man --
>  >> enable-
>  >> languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/
>  >> s/
>  >> $/-4.2/ --with-gxx-include-dir=/usr/include/c++/4.0.0 --with-
>  >> slibdir=/
>  >> usr/lib --build=i686-apple-darwin9 --host=i686-apple-darwin9 --
>  >> target=i686-apple-darwin9
>  >> Thread model: posix
>  >> gcc version 4.2.1 (Apple Inc. build 5531)
>  > ^^^
>  >
>  > Which version of XCode is this?  When did you get it?
>  > I'm sure your problem is that we haven't ported Sage to work
>  > with Apple's heavily hacked GCC-4.2.1.
>  >
>  > I've been building all my OS X code on all platforms using
>  > Apples GCC-4.0.1.   I wasn't aware that they released GCC-4.2.1.
>  > My guess is that numerous things will have to be fixed to get
>  > Sage to build against APPLE-GCC-4.2.1.  Your best bet
>  > is to install a binary or install an old

[sage-devel] Re: How to use alternate gfortran-4.3

[mabshoff]

On Apr 22, 12:05 am, "Gonzalo Tornaria" <[EMAIL PROTECTED]>
wrote:
> On 4/21/08, mabshoff <[EMAIL PROTECTED]> wrote:
>
>
>
> >  > export CC=gcc-4.3
> >  > export CXX=g++-4.3
>
> > I am not sure this will work all the time since sometimes we overwrite
> >  CC or CXX. I would suggest you put the 4.3 gcc and g++ somewhere in
> >  $PATH before gcc and g++ - Sage will then use them automatically.
>
> Ok, I've switched to
>
> export PATH=~/sage/bin:$PATH
> export CC=gcc-4.3
> export CXX=g++-4.3
> export SAGE_FORTRAN=~/sage/bin/gfortran
> export SAGE_FORTRAN_LIB=~/sage/lib/libgfortran.so

Ok, let us know how it works ;)

> (with gcc, g++, gfortran symlinks in ~/sage/bin, and a libgfortran.so
> symlink in ~/sage/lib). Maybe I'll have a look at the install.log
> later to see which packages honor the env variables and which don't.
> (maybe I should link gcc to /bin/false to reallly test this... ;-) )
>
> > ATLAS only links to libgfortran.so for some reason, so either link it
> >  against that name or copy it somewhere as libgfortran.so and point
> >  SAGE_FORTRAN_LIB to it. Another alternative is to start the build and
> >  then copy libgfortran.so.3 into SAGE_LOCAL/lib as libgfortran.so
> >  before ATLAS get going.

I already treat the case of libgfortran.so.1 special since that is the
default on RHEL5/Itanium. It would be easy to add the special case
libgfortran.so.3 assuming it is relative to gfortran, i.e. in ../lib/
libgfortran.so.3

> Please consider the following patch for the readme (don't credit me, I
> just reworded what you just said :-) ).
>
> --- sage-3.0.rc0/README.txt     2008-04-19 04:32:24.0 -0300
> +++ sage-3.0.rc1/README.txt     2008-04-21 18:58:39.0 -0300
> @@ -67,6 +67,14 @@
>            export SAGE_FORTRAN=/exact/path/to/gfortran
>            export SAGE_FORTRAN_LIB=/path/to/fortran/libs/libgfortran.so
>
> +      Note that ATLAS only links to libgfortran.so for some reason.
> +      If your system-wide library has a different filename (e.g.
> +      libgfortran.so.3), either link it against that name or copy it
> +      somewhere as libgfortran.so and point SAGE_FORTRAN_LIB to it.
> +      Another alternative is to start the build and then copy
> +      libgfortran.so.3 into SAGE_LOCAL/lib as libgfortran.so before
> +      ATLAS get going.
> +
>  UNSUPPORTED, BUT HIGH PRIORITY TO SUPPORT SOON:
>         sparc           Solaris 9, Solaris 10
>         x86_64          Solaris 10

Sure. I will put it on my list.

> > Well, many people seem to disagree with you ;) - some times you should
> >  be able to set some env variable to point it to gfortran-4.3. I think
> >  in the vast majority of cases configure checks for some Fortran
> >  compiler ever though they do not compile any Fortran code. Sigh  ...
> >  autohell ;)
>
> Yes, yes... but I don't know what is the analogue env variable of CC
> and CXX for fortran. Is there one?

Not that I know off. It seems that there isn't one that is universally
accepted.

> Gonzalo

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.rc1 released!

[Andrzej Giniewicz]

One test failed on standard rc1+clisp...p15, running 32 bit Arch linux
with GCC 4.3, /proc/cpuinfo below and doctest below it.

cheers,
Andrzej.

cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 10
model name  : AMD Athlon(tm) XP 2600+
stepping: 0
cpu MHz : 2091.115
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up ts
bogomips: 4186.88
clflush size: 32

and only test that failed:

sage -t  devel/sage-main/sage/rings/complex_double.pyx
**
File "/opt/sage-3.0.rc1/tmp/complex_double.py", line 1659:
sage: z^2 - z + 1
Expected:
2.22044604925e-16 + ...e-16*I
Got:
2.22044604925e-16
**
1 items had failures:
   1 of   7 in __main__.example_93
***Test Failed*** 1 failures.
For whitespace errors, see the file /opt/sage-3.0.rc1/
tmp/.doctest_complex_double.py
 [4.1 s]
exit code: 1024

--
The following tests failed:


sage -t  devel/sage-main/sage/rings/complex_double.pyx
Total time for all tests: 4.1 seconds


On 21 Kwi, 23:56, "John Cremona" <[EMAIL PROTECTED]> wrote:
> On my 32-bit kubuntu machine all is well with rc1:
>
> All tests passed!
> Total time for all tests: 3933.1 seconds
>
> John
>
> 2008/4/21 mabshoff <[EMAIL PROTECTED]>:
>
>
>
> >  On Apr 21, 11:14 pm, "John Cremona" <[EMAIL PROTECTED]> wrote:
> >  > 2008/4/21 William Stein <[EMAIL PROTECTED]>:
> >  
>
> > > >  Both of the failures you guys report -- in twist.py and testdoc.py 
> > > > involve
> >  > >  opening a network port, doing some tests that things are working,
> >  > >  then closing it. I think closing just takes a while with ports, 
> > perhaps,
> >  > >  and that might be relevant.I think if we make the ports in the 
> > tests
> >  > >  more spread out that could help.
>
> >  Hi John,
>
> >  > That makes sense.  Would it be better not to report such test failures
> >  > which pass on a second try?
>
> >  with any doctest failure you should mention if it is reproducible or
> >  not. In this case it seems that twisted or whoever closes the port
> >  might do so in an unclean way, i.e. the kernel considers the port
> >  still open and will only release it after some timeout. Knowing
> >  nothing about the internals of twisted I wouldn't know how to fix it,
> >  so somebody else should dig ;)
>
> >  > John
>
> >  Cheers,
>
> >  Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Project

[mabshoff]

On Apr 21, 11:48 pm, Robert Dodier <[EMAIL PROTECTED]> wrote:
> On Apr 20, 5:55 pm, mabshoff <[EMAIL PROTECTED]

Hi Robert,

> dortmund.de> wrote:
> > I forgot one important argument here: With ecls you can embed the lisp
> > interpreter into an external library, hence we would be able to use
> > Maxima as a library instead of using the inefficient pexpect
> > interface. I am not sure how much work this would be, but if I were a
> > Maxima coder I would certainly look into that possibility since it
> > opens a whole lot of possibilities for Maxima IMHO - totally
> > independent of Maxima's role in Sage.
>
> Aside from just getting stuff linked together (plenty of trouble
> to start with),

Sure, that is an issue, but you can't fail if you don't try ;)

> the more difficult problem is that Maxima is written
> with a pervasive assumption that there is someone at the console,
> e.g you ask for an integral or a limit and Maxima comes back with
> a question about some parameter. That make interaction with
> another program very difficult (as I think you know already).

Yes, I never had to deal with it via the pexpect interface in Sage,
but others certainly have.

> I have attempted to resolve this by converting questions into
> conditional expressions e.g. "Is x positive, negative, or zero?"
> => if x > 0 then ... elseif x < 0 then ... else 
> It sort of works but there are difficulties. If anyone wants to
> work on it with me, I'd be glad to have the help.

I cannot pledge anybody else's time here and I don't see any time for
myself opening up soon to work on this end of the problem. But I read
your message on fricas-devel about ecls support for Maxima and I am
certainly willing to help make that happen and test ecls build and
building Maxima on top of ecls on a wide range of platforms. I am also
willing to work on ecls itself and fix potential portability issues.
On top of that once ecls+Maxima "works" I will also likely lead the
push to get that combo merged into Sage. There are some other issues
you mention in your email to fricas-devel, but I will answer them over
there.

> Robert Dodier
> Maxima developer

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: How to use alternate gfortran-4.3

[Gonzalo Tornaria]

On 4/21/08, mabshoff <[EMAIL PROTECTED]> wrote:
>
>  > export CC=gcc-4.3
>  > export CXX=g++-4.3
>
>
> I am not sure this will work all the time since sometimes we overwrite
>  CC or CXX. I would suggest you put the 4.3 gcc and g++ somewhere in
>  $PATH before gcc and g++ - Sage will then use them automatically.

Ok, I've switched to

export PATH=~/sage/bin:$PATH
export CC=gcc-4.3
export CXX=g++-4.3
export SAGE_FORTRAN=~/sage/bin/gfortran
export SAGE_FORTRAN_LIB=~/sage/lib/libgfortran.so

(with gcc, g++, gfortran symlinks in ~/sage/bin, and a libgfortran.so
symlink in ~/sage/lib). Maybe I'll have a look at the install.log
later to see which packages honor the env variables and which don't.
(maybe I should link gcc to /bin/false to reallly test this... ;-) )


> ATLAS only links to libgfortran.so for some reason, so either link it
>  against that name or copy it somewhere as libgfortran.so and point
>  SAGE_FORTRAN_LIB to it. Another alternative is to start the build and
>  then copy libgfortran.so.3 into SAGE_LOCAL/lib as libgfortran.so
>  before ATLAS get going.

Please consider the following patch for the readme (don't credit me, I
just reworded what you just said :-) ).

--- sage-3.0.rc0/README.txt 2008-04-19 04:32:24.0 -0300
+++ sage-3.0.rc1/README.txt 2008-04-21 18:58:39.0 -0300
@@ -67,6 +67,14 @@
   export SAGE_FORTRAN=/exact/path/to/gfortran
   export SAGE_FORTRAN_LIB=/path/to/fortran/libs/libgfortran.so

+  Note that ATLAS only links to libgfortran.so for some reason.
+  If your system-wide library has a different filename (e.g.
+  libgfortran.so.3), either link it against that name or copy it
+  somewhere as libgfortran.so and point SAGE_FORTRAN_LIB to it.
+  Another alternative is to start the build and then copy
+  libgfortran.so.3 into SAGE_LOCAL/lib as libgfortran.so before
+  ATLAS get going.
+
 UNSUPPORTED, BUT HIGH PRIORITY TO SUPPORT SOON:
sparc   Solaris 9, Solaris 10
x86_64  Solaris 10


> Well, many people seem to disagree with you ;) - some times you should
>  be able to set some env variable to point it to gfortran-4.3. I think
>  in the vast majority of cases configure checks for some Fortran
>  compiler ever though they do not compile any Fortran code. Sigh  ...
>  autohell ;)

Yes, yes... but I don't know what is the analogue env variable of CC
and CXX for fortran. Is there one?

Gonzalo

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.rc1 released!

[John Cremona]

On my 32-bit kubuntu machine all is well with rc1:

All tests passed!
Total time for all tests: 3933.1 seconds

John

2008/4/21 mabshoff <[EMAIL PROTECTED]>:
>
>
>
>  On Apr 21, 11:14 pm, "John Cremona" <[EMAIL PROTECTED]> wrote:
>  > 2008/4/21 William Stein <[EMAIL PROTECTED]>:
>  
>
> > >  Both of the failures you guys report -- in twist.py and testdoc.py 
> > > involve
>  > >  opening a network port, doing some tests that things are working,
>  > >  then closing it. I think closing just takes a while with ports, perhaps,
>  > >  and that might be relevant.I think if we make the ports in the tests
>  > >  more spread out that could help.
>
>  Hi John,
>
>
>  > That makes sense.  Would it be better not to report such test failures
>  > which pass on a second try?
>
>  with any doctest failure you should mention if it is reproducible or
>  not. In this case it seems that twisted or whoever closes the port
>  might do so in an unclean way, i.e. the kernel considers the port
>  still open and will only release it after some timeout. Knowing
>  nothing about the internals of twisted I wouldn't know how to fix it,
>  so somebody else should dig ;)
>
>  > John
>  >
>
>  Cheers,
>
>  Michael
>
>
>
>  >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Disable ENABLE_PADLOCK_SUPPORT?

[mabshoff]

On Apr 21, 8:54 pm, Rob Goedman <[EMAIL PROTECTED]> wrote:

Hi Rob,

> This is XCode 3.0 with the updated gcc suite from the Apple developer  
> site. It sure seems to compile an awful lot before hitting this.
>
> I wonder how to make this work with R. R has these 100s of packages,  
> many of which need to be compiled when installed.
>
> Right now, at least on the Mac, R-2-7 itself supports/contains 4  
> architectures ( ppc, x86 each 32 and 64 bits ) and the compilers for
> c, c++ and fortran need to match for above package installations  
> (those that need to be compiled). Until recently there were disastrous
> bugs in the compilers for 64 bits (and other issues with gcc4.0, e.g.  
> when fortran was involved).
>
> Sage rc1 seems to include R-2.6.1, this week's R-2.7 release will  
> replace R-2.6.2.

We plan to upgrade to R 2.7 once it is out and we do some testing.

> I have tried gcc-4.0.1 but on my system it will hang forever (might be  
> related to the broken X11 that ships with Leopard):
>
> gcc -bundle -undefined dynamic_lookup build/temp.macosx-10.3-i386-2.5/
> Users/rob/Downloads/sage-3.0.rc1/spkg/build/python-2.5.2/src/Mac/
> Modules/launch/_Launchmodule.o -L/Users/rob/Downloads/sage-3.0.rc1/
> local/lib -L/usr/local/lib -o build/lib.macosx-10.3-i386-2.5/
> _Launch.so -framework ApplicationServices
> *** WARNING: renaming "_Launch" since importing it failed:  
> dlopen(build/lib.macosx-10.3-i386-2.5/_Launch.so, 2): Symbol not  
> found: __cg_png_create_info_struct
>    Referenced from: /System/Library/Frameworks/
> ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/
> Versions/A/ImageIO
>    Expected in: /usr/X11R6/lib/libPng.dylib
>
> building '_CG' extension
> creating build/temp.macosx-10.3-i386-2.5/Users/rob/Downloads/
> sage-3.0.rc1/spkg/build/python-2.5.2/src/Mac/Modules/cg
> gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-
> madd -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/Users/
> rob/Downloads/sage-3.0.rc1/spkg/build/python-2.5.2/src/./Include -I/
> Users/rob/Downloads/sage-3.0.rc1/spkg/build/python-2.5.2/src/./Mac/
> Include -I/Users/rob/Downloads/sage-3.0.rc1/local/include -I. -
> IInclude -I./Include -I/usr/local/include -I/Users/rob/Downloads/
> sage-3.0.rc1/spkg/build/python-2.5.2/src/Include -I/Users/rob/
> Downloads/sage-3.0.rc1/spkg/build/python-2.5.2/src -c /Users/rob/
> Downloads/sage-3.0.rc1/spkg/build/python-2.5.2/src/Mac/Modules/cg/
> _CGmodule.c -o build/temp.macosx-10.3-i386-2.5/Users/rob/Downloads/
> sage-3.0.rc1/spkg/build/python-2.5.2/src/Mac/Modules/cg/_CGmodule.o -
> Wno-deprecated-declarations
> gcc -bundle -undefined dynamic_lookup build/temp.macosx-10.3-i386-2.5/
> Users/rob/Downloads/sage-3.0.rc1/spkg/build/python-2.5.2/src/Mac/
> Modules/cg/_CGmodule.o -L/Users/rob/Downloads/sage-3.0.rc1/local/lib -
> L/usr/local/lib -o build/lib.macosx-10.3-i386-2.5/_CG.so -framework  
> ApplicationServices

The issue seems to be with libPng. We plan to teach R to use the
version we are compiling ourselves in Sage since Apple's libPng leaves
much to be desired, i.e. a header file for example ;)

> and it will never finish this step.
>
> My hope is that I can literally use either R.app to work with R and  
> its libraries and Sage notebooks using the same version of R and  
> libraries. Maybe the way Sage works with Mathematica?
>
> As MIchael suggested, 3.0.1 stuff!

I will hopefully have time to install the new & updated toolchain
soon. The pad lock issue OSX should be fixed in the spkg at

http://sage.math.washington.edu/home/mabshoff/SPKG/libgcrypt-1.4.0.p2.spkg

This is now tracked at http://trac.sagemath.org/sage_trac/ticket/2993
> Rob

Rob: if you could verify that it fixes the issue it will be in 3.0.1.
We disabled padlock support on non-OSX. It seems that some version of
gcc 4.2 are slightly stupid and make configure believe that padlock
support is available on non-Via CPUs. Go figure.

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Project

[Robert Dodier]

On Apr 20, 5:55 pm, mabshoff <[EMAIL PROTECTED]
dortmund.de> wrote:

> I forgot one important argument here: With ecls you can embed the lisp
> interpreter into an external library, hence we would be able to use
> Maxima as a library instead of using the inefficient pexpect
> interface. I am not sure how much work this would be, but if I were a
> Maxima coder I would certainly look into that possibility since it
> opens a whole lot of possibilities for Maxima IMHO - totally
> independent of Maxima's role in Sage.

Aside from just getting stuff linked together (plenty of trouble
to start with), the more difficult problem is that Maxima is written
with a pervasive assumption that there is someone at the console,
e.g you ask for an integral or a limit and Maxima comes back with
a question about some parameter. That make interaction with
another program very difficult (as I think you know already).

I have attempted to resolve this by converting questions into
conditional expressions e.g. "Is x positive, negative, or zero?"
=> if x > 0 then ... elseif x < 0 then ... else 
It sort of works but there are difficulties. If anyone wants to
work on it with me, I'd be glad to have the help.

Robert Dodier
Maxima developer

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.rc1 released!

[mabshoff]

On Apr 21, 11:14 pm, "John Cremona" <[EMAIL PROTECTED]> wrote:
> 2008/4/21 William Stein <[EMAIL PROTECTED]>:

> >  Both of the failures you guys report -- in twist.py and testdoc.py involve
> >  opening a network port, doing some tests that things are working,
> >  then closing it. I think closing just takes a while with ports, perhaps,
> >  and that might be relevant.    I think if we make the ports in the tests
> >  more spread out that could help.

Hi John,

> That makes sense.  Would it be better not to report such test failures
> which pass on a second try?

with any doctest failure you should mention if it is reproducible or
not. In this case it seems that twisted or whoever closes the port
might do so in an unclean way, i.e. the kernel considers the port
still open and will only release it after some timeout. Knowing
nothing about the internals of twisted I wouldn't know how to fix it,
so somebody else should dig ;)

> John
>

Cheers,

Michael

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: How to use alternate gfortran-4.3

[mabshoff]

On Apr 21, 11:17 pm, "Gonzalo Tornaria" <[EMAIL PROTECTED]>
wrote:

Hi Gonzalo

> I am compiling with gcc-4.3, my previous build of 3.0rc0 worked fine
> (no gfortran installed in the system). However, for my build of 3.0rc1
> I tried to install using gfortran-4.3 (from debian/testing).
>
> I followed instructions in README.txt, and set:
>
> export CC=gcc-4.3
> export CXX=g++-4.3

I am not sure this will work all the time since sometimes we overwrite
CC or CXX. I would suggest you put the 4.3 gcc and g++ somewhere in
$PATH before gcc and g++ - Sage will then use them automatically.

> export SAGE_FORTRAN=/usr/bin/gfortran-4.3

Same as the above for the name. But it will likely work

> export SAGE_FORTRAN_LIB=/usr/lib/libgfortran.so.3

ATLAS only links to libgfortran.so for some reason, so either link it
against that name or copy it somewhere as libgfortran.so and point
SAGE_FORTRAN_LIB to it. Another alternative is to start the build and
then copy libgfortran.so.3 into SAGE_LOCAL/lib as libgfortran.so
before ATLAS get going.

> However, I get a "ld: cannot find -lgfortran" while building atlas-3.8.1.p1.
>
> What is the correct syntax for "SAGE_FORTRAN_LIB"?
>
> Actually: the install.log doesn't show any trace of using
> "gfortran-4.3" as a binary. NOTE: I do *not* have "gfortran" package
> installed in my system, so the log is full of "checking for
> gfortran... no". But I think gfortran should work fine as long as it
> is called by "gfortran-4.3".

Well, many people seem to disagree with you ;) - some times you should
be able to set some env variable to point it to gfortran-4.3. I think
in the vast majority of cases configure checks for some Fortran
compiler ever though they do not compile any Fortran code. Sigh  ...
autohell ;)

> Gonzalo

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.rc1 released!

[Yi Qiang]

Please keep reporting them. It should be the case that these tests
pass on the first run.

On Mon, Apr 21, 2008 at 2:14 PM, John Cremona <[EMAIL PROTECTED]> wrote:
>
>  2008/4/21 William Stein <[EMAIL PROTECTED]>:
>
>
> >
>  >  On Mon, Apr 21, 2008 at 12:49 PM, Jaap Spies <[EMAIL PROTECTED]> wrote:
>  >  >
>  >  >  mabshoff wrote:
>  >  >  >
>  >  >  > Hello folks,
>  >  >  >
>  >  >  > here goes Sage 3.0.rc1. We are down to one blocker, i.e. the "-O0"
>  >  >  > fallback for clips in case of failure. Other than that this release
>  >  >  > should build and test fine. The 3.0 release is imminent, so if you
>  >  >  > find anything you better be quick. The plan is to follow up the 3.0
>  >  >  > release with one or two bug fix releases, i.e. 3.0.1 and 3.0.2. The
>  >  >  > timing of those releases will depend on the coercion rewrite.
>  >  >  >
>  >  >  > Sources and binaries are in the usual place:
>  >  >
>  >  >  On Fedora 7, 32 bits:
>  >  >
>  >  >  --
>  >  >  The following tests failed:
>  >  >
>  >  >
>  >  >  sage -t  devel/sage/sage/server/simple/twist.py
>  >  >  Total time for all tests: 4315.7 seconds
>  >  >  Please see /home/jaap/downloads/sage-3.0.rc1/tmp/test.log for the 
> complete log from this test.
>  >  >
>  >  >  But:
>  >  >
>  >  >  [EMAIL PROTECTED] sage-3.0.rc1]$ ./sage -t  
> devel/sage/sage/server/simple/twist.py
>  >  >  sage -t  devel/sage/sage/server/simple/twist.py
>  >  >   [9.9 s]
>  >  >
>  >  >  --
>  >  >  All tests passed!
>  >  >  Total time for all tests: 10.0 seconds
>  >  >  [EMAIL PROTECTED] sage-3.0.rc1]$
>  >  >
>  >  >
>  >  >  Jaap
>  >
>  >  Hi Jaap and John,
>  >
>  >  Both of the failures you guys report -- in twist.py and testdoc.py involve
>  >  opening a network port, doing some tests that things are working,
>  >  then closing it. I think closing just takes a while with ports, perhaps,
>  >  and that might be relevant.I think if we make the ports in the tests
>  >  more spread out that could help.
>  >
>
>  That makes sense.  Would it be better not to report such test failures
>  which pass on a second try?
>
>  John
>
>
>
>  >   -- William
>  >
>  >
>  >
>  >  >
>  >
>
>  >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] How to use alternate gfortran-4.3

[Gonzalo Tornaria]

I am compiling with gcc-4.3, my previous build of 3.0rc0 worked fine
(no gfortran installed in the system). However, for my build of 3.0rc1
I tried to install using gfortran-4.3 (from debian/testing).

I followed instructions in README.txt, and set:

export CC=gcc-4.3
export CXX=g++-4.3
export SAGE_FORTRAN=/usr/bin/gfortran-4.3
export SAGE_FORTRAN_LIB=/usr/lib/libgfortran.so.3

However, I get a "ld: cannot find -lgfortran" while building atlas-3.8.1.p1.

What is the correct syntax for "SAGE_FORTRAN_LIB"?

Actually: the install.log doesn't show any trace of using
"gfortran-4.3" as a binary. NOTE: I do *not* have "gfortran" package
installed in my system, so the log is full of "checking for
gfortran... no". But I think gfortran should work fine as long as it
is called by "gfortran-4.3".

Gonzalo

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.rc1 released!

[John Cremona]

2008/4/21 William Stein <[EMAIL PROTECTED]>:
>
>  On Mon, Apr 21, 2008 at 12:49 PM, Jaap Spies <[EMAIL PROTECTED]> wrote:
>  >
>  >  mabshoff wrote:
>  >  >
>  >  > Hello folks,
>  >  >
>  >  > here goes Sage 3.0.rc1. We are down to one blocker, i.e. the "-O0"
>  >  > fallback for clips in case of failure. Other than that this release
>  >  > should build and test fine. The 3.0 release is imminent, so if you
>  >  > find anything you better be quick. The plan is to follow up the 3.0
>  >  > release with one or two bug fix releases, i.e. 3.0.1 and 3.0.2. The
>  >  > timing of those releases will depend on the coercion rewrite.
>  >  >
>  >  > Sources and binaries are in the usual place:
>  >
>  >  On Fedora 7, 32 bits:
>  >
>  >  --
>  >  The following tests failed:
>  >
>  >
>  >  sage -t  devel/sage/sage/server/simple/twist.py
>  >  Total time for all tests: 4315.7 seconds
>  >  Please see /home/jaap/downloads/sage-3.0.rc1/tmp/test.log for the 
> complete log from this test.
>  >
>  >  But:
>  >
>  >  [EMAIL PROTECTED] sage-3.0.rc1]$ ./sage -t  
> devel/sage/sage/server/simple/twist.py
>  >  sage -t  devel/sage/sage/server/simple/twist.py
>  >   [9.9 s]
>  >
>  >  --
>  >  All tests passed!
>  >  Total time for all tests: 10.0 seconds
>  >  [EMAIL PROTECTED] sage-3.0.rc1]$
>  >
>  >
>  >  Jaap
>
>  Hi Jaap and John,
>
>  Both of the failures you guys report -- in twist.py and testdoc.py involve
>  opening a network port, doing some tests that things are working,
>  then closing it. I think closing just takes a while with ports, perhaps,
>  and that might be relevant.I think if we make the ports in the tests
>  more spread out that could help.
>

That makes sense.  Would it be better not to report such test failures
which pass on a second try?

John

>   -- William
>
>
>
>  >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Project

[root]

>> Having spent a fair portion of my life porting software, I understand
>> the frustrations you feel. And having spent the bulk of my life using
>> Lisp I "get" the get-rid-of-lisp pushback. But a lot of astonishingly
>> good computer algebra exists in lisp (we won't discuss the reasons).
>> Reproducing Axiom's "million-things-of-code" in Python would be no
>> small task, especially since some of the experts are dead.
>
>Well, many things are available in non-lisp CASes and many of them are
>in Sage, so it isn't that Sage without Axiom isn't viable [not that
>you implied that]. If a sufficient number of people want Lisp to
>remain a significant player in the CAS world [and computer science in
>general] it will be so. We are not forcing you to use Python or Sage.
>This is all about what tool gets the job done for you and in your case
>it is Axiom ;)

Well, Sage doesn't actually use Axiom. William has no long term focus
except to compete with the 4Ms. Sage doesn't use GCL. And the project
is strongly motivated to elide lisp. Except for my involvement in the
Sage program committee for the Nancy conference, I don't see that I
can be of much help. Sorry for the noise.

Tim



--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.rc1 released!

[William Stein]

On Mon, Apr 21, 2008 at 12:49 PM, Jaap Spies <[EMAIL PROTECTED]> wrote:
>
>  mabshoff wrote:
>  >
>  > Hello folks,
>  >
>  > here goes Sage 3.0.rc1. We are down to one blocker, i.e. the "-O0"
>  > fallback for clips in case of failure. Other than that this release
>  > should build and test fine. The 3.0 release is imminent, so if you
>  > find anything you better be quick. The plan is to follow up the 3.0
>  > release with one or two bug fix releases, i.e. 3.0.1 and 3.0.2. The
>  > timing of those releases will depend on the coercion rewrite.
>  >
>  > Sources and binaries are in the usual place:
>
>  On Fedora 7, 32 bits:
>
>  --
>  The following tests failed:
>
>
>  sage -t  devel/sage/sage/server/simple/twist.py
>  Total time for all tests: 4315.7 seconds
>  Please see /home/jaap/downloads/sage-3.0.rc1/tmp/test.log for the complete 
> log from this test.
>
>  But:
>
>  [EMAIL PROTECTED] sage-3.0.rc1]$ ./sage -t  
> devel/sage/sage/server/simple/twist.py
>  sage -t  devel/sage/sage/server/simple/twist.py
>   [9.9 s]
>
>  --
>  All tests passed!
>  Total time for all tests: 10.0 seconds
>  [EMAIL PROTECTED] sage-3.0.rc1]$
>
>
>  Jaap

Hi Jaap and John,

Both of the failures you guys report -- in twist.py and testdoc.py involve
opening a network port, doing some tests that things are working,
then closing it. I think closing just takes a while with ports, perhaps,
and that might be relevant.I think if we make the ports in the tests
more spread out that could help.

 -- William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.rc1 released!

[John Cremona]

Built ok but one test fail on 64-bit Suse system

The following tests failed:
sage -t  devel/sage/sage/dsage/tests/testdoc.py

-- but passed when run by itself.

Still building on 32 bit kubuntu.

John

2008/4/21 mabshoff <[EMAIL PROTECTED]>:
>
>
>  Hello folks,
>
>  here goes Sage 3.0.rc1. We are down to one blocker, i.e. the "-O0"
>  fallback for clips in case of failure. Other than that this release
>  should build and test fine. The 3.0 release is imminent, so if you
>  find anything you better be quick. The plan is to follow up the 3.0
>  release with one or two bug fix releases, i.e. 3.0.1 and 3.0.2. The
>  timing of those releases will depend on the coercion rewrite.
>
>  Sources and binaries are in the usual place:
>
>  
> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0/sage-3.0.rc1.tar
>
>  
> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0/sage-3.0.rc1-sage.math-only-x86_64-Linux.tar.gz
>
>  Cheers,
>
>  Michael
>
>  Merged in rc1:
>
>  #2419: William Stein, Simon King: Gap interface and resultant
>destroy the Singular interface on some machines
>  #2553: Yi Qiang, William Stein: dsage unit tests fail on linux
>  #2928: Willem Jan Palenstijn: another p-adic extension segfault
>  #2934: William Stein: doctesting files outside of sage repo is
>completely broken
>  #2972: William Stein: libSingular related segfault in
>laurent_polynomial_ring.py
>  #2973: Michael Abshoff: RDF doctest failures on arch linux
>  #2974: Mike Hansen: interfaces/r.py doctest failures on many
>linux machines
>  #2975: William Stein: opening ports too conservative -- breaks
>on some os x systems
>  #2977: Alex Ghitza: wronskian is broken on constants
>  #2984: William Stein, Michael Abshoff: ITANIUM (RHEL 5) -- turn
>off all unaligned access messages
>  #2986: Gonzalo Tornaria: Add atlas pretuning for Pentium D/64
>bits (ARCH=P4D64SSE3)
>
>  [I removed the rest of the other tickets merged]
>  >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.rc1 released!

[Jaap Spies]

mabshoff wrote:
> 
> Hello folks,
> 
> here goes Sage 3.0.rc1. We are down to one blocker, i.e. the "-O0"
> fallback for clips in case of failure. Other than that this release
> should build and test fine. The 3.0 release is imminent, so if you
> find anything you better be quick. The plan is to follow up the 3.0
> release with one or two bug fix releases, i.e. 3.0.1 and 3.0.2. The
> timing of those releases will depend on the coercion rewrite.
> 
> Sources and binaries are in the usual place:

On Fedora 7, 32 bits:

--
The following tests failed:


 sage -t  devel/sage/sage/server/simple/twist.py
Total time for all tests: 4315.7 seconds
Please see /home/jaap/downloads/sage-3.0.rc1/tmp/test.log for the complete log 
from this test.

But:

[EMAIL PROTECTED] sage-3.0.rc1]$ ./sage -t  
devel/sage/sage/server/simple/twist.py
sage -t  devel/sage/sage/server/simple/twist.py
  [9.9 s]

--
All tests passed!
Total time for all tests: 10.0 seconds
[EMAIL PROTECTED] sage-3.0.rc1]$


Jaap


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Project

[mabshoff]

On Apr 21, 6:09 pm, root <[EMAIL PROTECTED]> wrote:



Hi Tim,

> > The GCL-devel mailing list has on average about 5-6 messages a month
> > during the last couple of months, except for a bunch of messages in
> > January about people trying to build GCL from cvs.
>
> You claim that you pass problem reports upstream but I don't see many
> Sage postings to the GCL mailing list. Camm, the GCL maintainer, has
> always been very responsive and effective in his replies. But, like
> you, he needs good, clear, effective bug reports.

Yes, I can certainly agree with you on that one. Detailed bug reports
are required to get anything fixed.

But I get paid to do a job:
 * port Sage to Solaris
 * support Sage on Linux/Itanium
 * port Sage to Windows

While I am at it I do a number of other Sage related jobs:
 * play a release manager
 * hunt down memory leaks in general
 * port Sage to FreeBSD
 * port Sage to Linux/Sparc
 * port Sage to Linux/PPC64

When I am done with the above [i.e. in the "evening" ;)] I would
really, really like to do:
 * audit Singular for memory leaks with its test suite and fix those
bugs ;)
 * get deeply into PolyBoRi and help dealing with their memory
management issues
 * compile gcc 4.4CVS  [or whatever is next] and make Sage build with
it. After fixing all the bugs push them upstream [I did many of those
with gcc 4.3 about six months ago, but only finished pushing the fixes
in 3.0]

The above three tasks are something that gives me credit with my peers
and would certainly benefit me and my reputation in the CAS community
[at least with many algebra people ;)].

Now let's contrast this with gcl:
 * gcl is a mature project, i.e. it should just work out of the box
most of the time
 * It *should* build on the vast majority of platforms that it claims
it supports. Reality: there are many, many problems - and that is with
me not being an  ass and deliberately doing something stupid on
purpose

Looking at the above lists you will hopefully understand that I have
no interest in working on gcl since doing efficient bug reporting
would require that I get familiar with the code. I would likely get
into it since I could fix many of those bugs myself. But since I have
no interest in lisp and would like to spend my time on projects where
I would I personally know the people and share common goals with I
will not do that.

To put it nicely:  gcl is  "stagnating". The last release was in 2005
[not 5 years ago like I mistakenly claimed]. If the lisp community
would be a large thriving community *I* wouldn't have to do anything
about that issue, but you would likely have had some release since
2005 and many of the problems I saw would have already been solved,
i.e. it would "just work". Am I wrong to assume that the gcl community
does not have access to a reasonably large number of non-Linux boxen?
I spend a huge amount of time on any exotic and not so exotic build
problem with Sage, hence I expect other projects to do the same thing.
If that is not the case I will not use their code and due to the
insane number of issues with clisp, gcl and so on I have drawn the
conclusion that Sage without a lisp dependency in its core [i.e. code
I am getting paid to support] would be a better Sage. That doesn't
mean that Sage will not be very accommodating to say Maxima, Axiom,
FriCAS and OpenAxiom via an optional lisp package, but as long as they
depend on lisp [forever would be my guess here] I do not see a chance
for them to stay in the core or become part of the core long term.
Prove me wrong: Get gcl to build out of the box on various Linuxes
[with gcc], Solaris 9, 10 with Sun Forte, OSX 10.4, 10.5 with XCode
[no stupid MacPorts here] and Windows with MSVC and I will be the
first guy to help you out. I see ecls potentially in that role, but as
long as it isn't supported in Maxima I see no urgent reason to spend
any work on that.

But I have dealt with the ecls maintainer, both by reporting problems
and submitting patchlets, so I know he is up to the job. He for
example already uses MSVC on Windows to build ecls, so he is far ahead
of any other Open Source lisp AFAIK. That gives me hope since his
goals and understanding of the importance to support non-gcc compilers
are very much aligned to my personal opinions.

> I think you'd feel the same frustrations with Python if you compiled
> Python from scratch for every platform. You ship "sources" but assume
> that the python language exists and is compatible, which is not likely
> to be the case when 3.0 arrives. If you can assume the python language,
> why can't you assume the lisp language? If you can't assume the lisp
> language, why can you assume the python language?

As others have pointed out already we do build Python from source.
Once Python 2.6 comes out [in parallel with Python 3K] we will migrate
first to 2.6 and then likely to 3.0 at some point. But since we build
Python we control our own destiny here.

> Having spent a fair portion of my life porting so

[sage-devel] Re: Fwd: mercurial --> plain text --> mercurial

[Robert Bradshaw]

On Apr 21, 2008, at 11:47 AM, John Cremona wrote:

> Sorry if this is a stupid question:  if you are going to make a new
> complete repository with a patched version of mercurial, does that
> mean that native mercurial installations will not work with Sage from
> now on, only Sage's "own" version?
>
> John

No, it's just a changeing the internal names (the hex string called  
nodeid) of the patches. Mercurial keeps track of what the "parent" of  
a given changset is, but sometime in the last two years of so they  
changed how they compute this hash which makes it difficult to export  
and re-import an entire repository as a string of patches. My hacked  
mercurial essentially allows one to rename all the old changesets  
according to the new method without changing the content, history, or  
timestamps of a repository.

- Robert


>
> 2008/4/21 Robert Bradshaw <[EMAIL PROTECTED]>:
>>
>>  On Apr 21, 2008, at 11:34 AM, mabshoff wrote:
>>
>>> On Apr 21, 8:24 pm, Robert Bradshaw <[EMAIL PROTECTED]>
>>> wrote:
 On Apr 21, 2008, at 11:14 AM, William Stein wrote:
>>>
>>> Hi,
>>>
>>  Yes, I could. This would mean that no pre-3.0 bundles would
>> apply to
>>  post-3.0 (short of re-basing the bundles--and the big one
>> (coercion)
>>  I could rebase myself). Patches should be just fine, and most
>> things
>>  aren't big enough to warrant bundles.
>>>
>>> The number of bundles in trac is rather small and most of those
>>> bundles either have review issues or shouldn't be bundles in the  
>>> first
>>> place [as you stated above], so applying them to a pre-3.0 tree,
>>> extracting the patch and so on should be doable.
>>
>>  Sure. The other concern is people with as-yet unsubmitted code on
>>  their own computers. One will no longer be able to pull/push. (Does
>>  the current upgrade try and do that?)
>>
>>  Maybe I could schedule doing it sometime when you're sleeping (does
>>  that ever happen? :-) 'cause it can't be done in parallel to merging
>>  very well.
>>
>>
>> Does anyone know if mercurial
>>  1.0 changed how hashing is done (yet again) or is it finally
>> stable?
>>  If so I think this would be a good thing to do.

> Well this is definitely the right *time* to do it.

 I'll do that then. Probably best to do right before the release, to
 not disrupt the development cycle (and as the actual code won't
 change (check with a diff) we won't need to be concerned about
 breaking Sage). Perhaps the other packages should be changed as  
 well.
>>>
>>> The main ones, i.e. extcode and scripts, too and I guess it would be
>>> nice to get all the hg repos in the  spkgs fixed, too.
>>
>>  Certainly.
>>
>>
>>> Does this
>>> require that we upgrade to hg 1.0 or is it fine with the release we
>>> ship? Upgrading to 1.0 should be quick and I think I will get it  
>>> done
>>> during the 3.0.1 cycle.
>>
>>  It requires a hacked version of hg I have on my computer, and not  
>> the
>>  kind of patch that would ever get merged upstream (without cleanup).
>>  I just asked the Mercurial guy who answered my original question if
>>  the hashes changed (again) in 1.0, but I got the impression last  
>> time
>>  that they have been sable for a while (just not as long as Sage has
>>  been around).
>>
>>  - Robert
>>
>>
>>
>>
>>>
>>
>
> 

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Disable ENABLE_PADLOCK_SUPPORT?

[Rob Goedman]

This is XCode 3.0 with the updated gcc suite from the Apple developer  
site. It sure seems to compile an awful lot before hitting this.

I wonder how to make this work with R. R has these 100s of packages,  
many of which need to be compiled when installed.

Right now, at least on the Mac, R-2-7 itself supports/contains 4  
architectures ( ppc, x86 each 32 and 64 bits ) and the compilers for
c, c++ and fortran need to match for above package installations  
(those that need to be compiled). Until recently there were disastrous
bugs in the compilers for 64 bits (and other issues with gcc4.0, e.g.  
when fortran was involved).

Sage rc1 seems to include R-2.6.1, this week's R-2.7 release will  
replace R-2.6.2.

I have tried gcc-4.0.1 but on my system it will hang forever (might be  
related to the broken X11 that ships with Leopard):

gcc -bundle -undefined dynamic_lookup build/temp.macosx-10.3-i386-2.5/ 
Users/rob/Downloads/sage-3.0.rc1/spkg/build/python-2.5.2/src/Mac/ 
Modules/launch/_Launchmodule.o -L/Users/rob/Downloads/sage-3.0.rc1/ 
local/lib -L/usr/local/lib -o build/lib.macosx-10.3-i386-2.5/ 
_Launch.so -framework ApplicationServices
*** WARNING: renaming "_Launch" since importing it failed:  
dlopen(build/lib.macosx-10.3-i386-2.5/_Launch.so, 2): Symbol not  
found: __cg_png_create_info_struct
   Referenced from: /System/Library/Frameworks/ 
ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/ 
Versions/A/ImageIO
   Expected in: /usr/X11R6/lib/libPng.dylib

building '_CG' extension
creating build/temp.macosx-10.3-i386-2.5/Users/rob/Downloads/ 
sage-3.0.rc1/spkg/build/python-2.5.2/src/Mac/Modules/cg
gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused- 
madd -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/Users/ 
rob/Downloads/sage-3.0.rc1/spkg/build/python-2.5.2/src/./Include -I/ 
Users/rob/Downloads/sage-3.0.rc1/spkg/build/python-2.5.2/src/./Mac/ 
Include -I/Users/rob/Downloads/sage-3.0.rc1/local/include -I. - 
IInclude -I./Include -I/usr/local/include -I/Users/rob/Downloads/ 
sage-3.0.rc1/spkg/build/python-2.5.2/src/Include -I/Users/rob/ 
Downloads/sage-3.0.rc1/spkg/build/python-2.5.2/src -c /Users/rob/ 
Downloads/sage-3.0.rc1/spkg/build/python-2.5.2/src/Mac/Modules/cg/ 
_CGmodule.c -o build/temp.macosx-10.3-i386-2.5/Users/rob/Downloads/ 
sage-3.0.rc1/spkg/build/python-2.5.2/src/Mac/Modules/cg/_CGmodule.o - 
Wno-deprecated-declarations
gcc -bundle -undefined dynamic_lookup build/temp.macosx-10.3-i386-2.5/ 
Users/rob/Downloads/sage-3.0.rc1/spkg/build/python-2.5.2/src/Mac/ 
Modules/cg/_CGmodule.o -L/Users/rob/Downloads/sage-3.0.rc1/local/lib - 
L/usr/local/lib -o build/lib.macosx-10.3-i386-2.5/_CG.so -framework  
ApplicationServices

and it will never finish this step.

My hope is that I can literally use either R.app to work with R and  
its libraries and Sage notebooks using the same version of R and  
libraries. Maybe the way Sage works with Mathematica?

As MIchael suggested, 3.0.1 stuff!

Rob


On Apr 21, 2008, at 9:54 AM, William Stein wrote:

>
> On Mon, Apr 21, 2008 at 9:31 AM, Rob Goedman <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> Brand new to Sage builds!
>>
>> On Mac OS 10.5.2, with:
>>
>> Robs-Intel:sage-3.0.rc0 rob$ gcc -v
>> Using built-in specs.
>> Target: i686-apple-darwin9
>> Configured with: /var/tmp/gcc_42/gcc_42-5531~1/src/configure -- 
>> disable-
>> checking -enable-werror --prefix=/usr --mandir=/usr/share/man -- 
>> enable-
>> languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/ 
>> s/
>> $/-4.2/ --with-gxx-include-dir=/usr/include/c++/4.0.0 --with- 
>> slibdir=/
>> usr/lib --build=i686-apple-darwin9 --host=i686-apple-darwin9 --
>> target=i686-apple-darwin9
>> Thread model: posix
>> gcc version 4.2.1 (Apple Inc. build 5531)
> ^^^
>
> Which version of XCode is this?  When did you get it?
> I'm sure your problem is that we haven't ported Sage to work
> with Apple's heavily hacked GCC-4.2.1.
>
> I've been building all my OS X code on all platforms using
> Apples GCC-4.0.1.   I wasn't aware that they released GCC-4.2.1.
> My guess is that numerous things will have to be fixed to get
> Sage to build against APPLE-GCC-4.2.1.  Your best bet
> is to install a binary or install an older XCode (with GCC-4.0.1)
> or wait until Sage supports GCC-4.2.1, which means 1-2 weeks
> (since obviously I'll upgrade and have to support the newer compiler).
>
> The compiler I use:
> bsd:~ was$ gcc -v
> Using built-in specs.
> Target: i686-apple-darwin9
> Configured with: /var/tmp/gcc/gcc-5465~16/src/configure
> --disable-checking -enable-werror --prefix=/usr --mandir=/share/man
> --enable-languages=c,objc,c++,obj-c++
> --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
> --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
> --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic
> --host=i686-apple-darwin9 --target=i686-apple-darwin9
> Thread model: posix
> gcc version 4.0.1 (Apple Inc. build 5465)
> bsd:~ 

[sage-devel] Re: Compile Error

[Walt]

On Apr 21, 12:47 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> Thanks.  That's helpful.  Unfortunately it also means at least I have
> no clue how to fix the problem.
>
> You might try just installing clisp system-wide (using your package
> management system), then tell SAge to use that by typing in SAGE_ROOT
>
>    touch spkg/installed/clisp-2.41.p14
>
> and also
>
>       touch spkg/installed/clisp-2.41.p13
>
> for good measure, then typing
>
>      make
>
> to continue the build as if clisp successfully installed.
>
> William

Hmm did this, Fedora 9 looks like it will ship with clisp 2.43, and
got an error.  clisp works fine by itself, not sure how to make sage
work properly with it.
Error:

test -d binary-clisp || mkdir binary-clisp
clisp.bin -norc -q -x '(progn (load "../lisp-utils/defsystem.lisp")
(funcall (intern (symbol-name :operate-on-system) :mk)
"maxima" :compile :verbose t))' && \
clisp.bin -norc -q -x '(progn (load "../lisp-utils/defsystem.lisp")
(funcall (intern (symbol-name :operate-on-system) :mk)
"maxima" :load :verbose t) (ext:saveinitmem "binary-clisp/
maxima.mem" :init-function (function cl-user::run)))'
/bin/sh: clisp.bin: command not found
make[3]: *** [binary-clisp/maxima.mem] Error 127
make[3]: Leaving directory `/home/zarathustra/Download/sage-3.0.rc1/
spkg/build/maxima-5.13.0.p2/src/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/zarathustra/Download/sage-3.0.rc1/
spkg/build/maxima-5.13.0.p2/src'
***
Failed to make Maxima.
***

real0m3.227s
user0m1.051s
sys 0m1.241s
sage: An error occurred while installing maxima-5.13.0.p2
Please email sage-devel http://groups.google.com/group/sage-devel
explaining the problem and send the relevant part of
of /home/zarathustra/Download/sage-3.0.rc1/install.log.  Describe your
computer, operating system, etc.
If you want to try to fix the problem, yourself *don't* just cd to
/home/zarathustra/Download/sage-3.0.rc1/spkg/build/maxima-5.13.0.p2
and type 'make'.
Instead type "/home/zarathustra/Download/sage-3.0.rc1/sage -sh"
in order to set all environment variables correctly, then cd to
/home/zarathustra/Download/sage-3.0.rc1/spkg/build/maxima-5.13.0.p2
(When you are done debugging, you can type "exit" to leave the
subshell.)
make[1]: *** [installed/maxima-5.13.0.p2] Error 1
make[1]: Leaving directory `/home/zarathustra/Download/sage-3.0.rc1/
spkg'

real105m15.604s
user82m29.544s
sys 10m36.602s
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Compile Error

[Andrzej Giniewicz]

Just as pasted in 4'th post in topic (it's of course 32bit Arch...
otherwise would have said Arch64 as it's not-so-finished-port in my
opinion)... there's cpuinfo again:

processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 10
model name  : AMD Athlon(tm) XP 2600+
stepping: 0
cpu MHz : 2091.138
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up ts
bogomips: 4186.87
clflush size: 32


On 21 Kwi, 20:00, "William Stein" <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 21, 2008 at 10:53 AM, Andrzej Giniewicz <[EMAIL PROTECTED]> wrote:
>
> >  Also have same error with both .p13 and .p14, but by some random case
> >  I got other error when run make for the second time, there is complete
> >  log from first build:www.giniu.ravenlord.ws/install.log.1(HUGE one),
> >  and there is second one, small log from second build
> >  (www.giniu.ravenlord.ws/install.log.2) - to sum it short, first was
> >  exactly same as before, second one gave:
>
> >  gcc -I/opt/sage-3.0.rc1/local/include -g -O2 -W -Wswitch -Wcomment -
> >  Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-
>
> > sign-compare -O2 -fexpensive-optimizations -falign-functions=4 -
> >  DNO_MULTIMAP_SHM -DNO_MULTIMAP_FILE -DNO_SINGLEMAP -DNO_TRIVIALMAP -
> >  DUNICODE -I. -c spvw.c
>
> > In file included from lispbibl.d:325,
> >  from spvw.d:24:
> >  floatparam.h:18:2: error: #error "Unknown rounding mode for type
> >  double!"
>
> >  I don't know if this because make was runned after broken build or
> >  what, but that's what I got... anyway - will try other ways (flag and
> >  distro package...), distro package for sure works, there is script
> >  used to build clisp under Arch with GCC4.3:
> >  http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/devel/clisp/PKGBUILD?rev...
>
> >  hope it helps, if there is anything I can do/test/check to help with
> >  I'll be happy to do it
>
> We've been building Sage with that clisp under Arch linux 32-bit and
> it works fine, using gcc-4.3.  What exact Arch are you using?  32-bit
> or 64-bit?  Which hardware?  cat /proc/cpuinfo.

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Compile Error

[Andrzej Giniewicz]

Well, I don't know if Arch's clisp works with Sage, it just works by
itself... and about downgrade, it would be hard, because many packages
in Arch are already built against GCC4.3 and downgrade would require
manual rebuild of many vital packages and introduce many
incompatibilities with new software from repos... I think it's price
one have to pay for current system - I hope this can be fixed or
worked-around before 3.0 or 3.0.1 and keep fingers crossed :)

regards,
Andrzej.

On 21 Kwi, 19:53, Andrzej Giniewicz <[EMAIL PROTECTED]> wrote:
> Also have same error with both .p13 and .p14, but by some random case
> I got other error when run make for the second time, there is complete
> log from first build:www.giniu.ravenlord.ws/install.log.1(HUGE one),
> and there is second one, small log from second build
> (www.giniu.ravenlord.ws/install.log.2) - to sum it short, first was
> exactly same as before, second one gave:
>
> gcc -I/opt/sage-3.0.rc1/local/include -g -O2 -W -Wswitch -Wcomment -
> Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-
> sign-compare -O2 -fexpensive-optimizations -falign-functions=4 -
> DNO_MULTIMAP_SHM -DNO_MULTIMAP_FILE -DNO_SINGLEMAP -DNO_TRIVIALMAP -
> DUNICODE -I. -c spvw.c
> In file included from lispbibl.d:325,
>  from spvw.d:24:
> floatparam.h:18:2: error: #error "Unknown rounding mode for type
> double!"
>
> I don't know if this because make was runned after broken build or
> what, but that's what I got... anyway - will try other ways (flag and
> distro package...), distro package for sure works, there is script
> used to build clisp under Arch with 
> GCC4.3:http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/devel/clisp/PKGBUILD?rev...
>
> hope it helps, if there is anything I can do/test/check to help with
> I'll be happy to do it
>
> regards,
> Andrzej.
>
> On 21 Kwi, 18:47, "William Stein" <[EMAIL PROTECTED]> wrote:
>
> > On Mon, Apr 21, 2008 at 9:42 AM,  <[EMAIL PROTECTED]> wrote:
>
> > >  And by same error I mean the one I initially started this thread with,
> > >  sorry about the ambiguity.
>
> > Thanks.  That's helpful.  Unfortunately it also means at least I have
> > no clue how to fix the problem.
>
> > You might try just installing clisp system-wide (using your package
> > management system), then tell SAge to use that by typing in SAGE_ROOT
>
> >touch spkg/installed/clisp-2.41.p14
>
> > and also
>
> >   touch spkg/installed/clisp-2.41.p13
>
> > for good measure, then typing
>
> >  make
>
> > to continue the build as if clisp successfully installed.
>
> > William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Fwd: mercurial --> plain text --> mercurial

[John Cremona]

Sorry if this is a stupid question:  if you are going to make a new
complete repository with a patched version of mercurial, does that
mean that native mercurial installations will not work with Sage from
now on, only Sage's "own" version?

John

2008/4/21 Robert Bradshaw <[EMAIL PROTECTED]>:
>
>  On Apr 21, 2008, at 11:34 AM, mabshoff wrote:
>
>  > On Apr 21, 8:24 pm, Robert Bradshaw <[EMAIL PROTECTED]>
>  > wrote:
>  >> On Apr 21, 2008, at 11:14 AM, William Stein wrote:
>  >
>  > Hi,
>  >
>    Yes, I could. This would mean that no pre-3.0 bundles would
>   apply to
>    post-3.0 (short of re-basing the bundles--and the big one
>   (coercion)
>    I could rebase myself). Patches should be just fine, and most
>   things
>    aren't big enough to warrant bundles.
>  >
>  > The number of bundles in trac is rather small and most of those
>  > bundles either have review issues or shouldn't be bundles in the first
>  > place [as you stated above], so applying them to a pre-3.0 tree,
>  > extracting the patch and so on should be doable.
>
>  Sure. The other concern is people with as-yet unsubmitted code on
>  their own computers. One will no longer be able to pull/push. (Does
>  the current upgrade try and do that?)
>
>  Maybe I could schedule doing it sometime when you're sleeping (does
>  that ever happen? :-) 'cause it can't be done in parallel to merging
>  very well.
>
>
>   Does anyone know if mercurial
>    1.0 changed how hashing is done (yet again) or is it finally
>   stable?
>    If so I think this would be a good thing to do.
>  >>
>  >>> Well this is definitely the right *time* to do it.
>  >>
>  >> I'll do that then. Probably best to do right before the release, to
>  >> not disrupt the development cycle (and as the actual code won't
>  >> change (check with a diff) we won't need to be concerned about
>  >> breaking Sage). Perhaps the other packages should be changed as well.
>  >
>  > The main ones, i.e. extcode and scripts, too and I guess it would be
>  > nice to get all the hg repos in the  spkgs fixed, too.
>
>  Certainly.
>
>
>  > Does this
>  > require that we upgrade to hg 1.0 or is it fine with the release we
>  > ship? Upgrading to 1.0 should be quick and I think I will get it done
>  > during the 3.0.1 cycle.
>
>  It requires a hacked version of hg I have on my computer, and not the
>  kind of patch that would ever get merged upstream (without cleanup).
>  I just asked the Mercurial guy who answered my original question if
>  the hashes changed (again) in 1.0, but I got the impression last time
>  that they have been sable for a while (just not as long as Sage has
>  been around).
>
>  - Robert
>
>
>
>
>  >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Fwd: mercurial --> plain text --> mercurial

[Robert Bradshaw]

On Apr 21, 2008, at 11:34 AM, mabshoff wrote:

> On Apr 21, 8:24 pm, Robert Bradshaw <[EMAIL PROTECTED]>
> wrote:
>> On Apr 21, 2008, at 11:14 AM, William Stein wrote:
>
> Hi,
>
  Yes, I could. This would mean that no pre-3.0 bundles would  
 apply to
  post-3.0 (short of re-basing the bundles--and the big one  
 (coercion)
  I could rebase myself). Patches should be just fine, and most  
 things
  aren't big enough to warrant bundles.
>
> The number of bundles in trac is rather small and most of those
> bundles either have review issues or shouldn't be bundles in the first
> place [as you stated above], so applying them to a pre-3.0 tree,
> extracting the patch and so on should be doable.

Sure. The other concern is people with as-yet unsubmitted code on  
their own computers. One will no longer be able to pull/push. (Does  
the current upgrade try and do that?)

Maybe I could schedule doing it sometime when you're sleeping (does  
that ever happen? :-) 'cause it can't be done in parallel to merging  
very well.

 Does anyone know if mercurial
  1.0 changed how hashing is done (yet again) or is it finally  
 stable?
  If so I think this would be a good thing to do.
>>
>>> Well this is definitely the right *time* to do it.
>>
>> I'll do that then. Probably best to do right before the release, to
>> not disrupt the development cycle (and as the actual code won't
>> change (check with a diff) we won't need to be concerned about
>> breaking Sage). Perhaps the other packages should be changed as well.
>
> The main ones, i.e. extcode and scripts, too and I guess it would be
> nice to get all the hg repos in the  spkgs fixed, too.

Certainly.

> Does this
> require that we upgrade to hg 1.0 or is it fine with the release we
> ship? Upgrading to 1.0 should be quick and I think I will get it done
> during the 3.0.1 cycle.

It requires a hacked version of hg I have on my computer, and not the  
kind of patch that would ever get merged upstream (without cleanup).  
I just asked the Mercurial guy who answered my original question if  
the hashes changed (again) in 1.0, but I got the impression last time  
that they have been sable for a while (just not as long as Sage has  
been around).

- Robert


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Fwd: mercurial --> plain text --> mercurial

[mabshoff]

On Apr 21, 8:24 pm, Robert Bradshaw <[EMAIL PROTECTED]>
wrote:
> On Apr 21, 2008, at 11:14 AM, William Stein wrote:

Hi,

> >>  Yes, I could. This would mean that no pre-3.0 bundles would apply to
> >>  post-3.0 (short of re-basing the bundles--and the big one (coercion)
> >>  I could rebase myself). Patches should be just fine, and most things
> >>  aren't big enough to warrant bundles.

The number of bundles in trac is rather small and most of those
bundles either have review issues or shouldn't be bundles in the first
place [as you stated above], so applying them to a pre-3.0 tree,
extracting the patch and so on should be doable.

> >> Does anyone know if mercurial
> >>  1.0 changed how hashing is done (yet again) or is it finally stable?
> >>  If so I think this would be a good thing to do.
>
> > Well this is definitely the right *time* to do it.
>
> I'll do that then. Probably best to do right before the release, to  
> not disrupt the development cycle (and as the actual code won't  
> change (check with a diff) we won't need to be concerned about  
> breaking Sage). Perhaps the other packages should be changed as well.

The main ones, i.e. extcode and scripts, too and I guess it would be
nice to get all the hg repos in the  spkgs fixed, too. Does this
require that we upgrade to hg 1.0 or is it fine with the release we
ship? Upgrading to 1.0 should be quick and I think I will get it done
during the 3.0.1 cycle.

> - Robert

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Fwd: mercurial --> plain text --> mercurial

[Robert Bradshaw]

On Apr 21, 2008, at 11:14 AM, William Stein wrote:

> On Mon, Apr 21, 2008 at 11:06 AM, Robert Bradshaw
> <[EMAIL PROTECTED]> wrote:
>>
>>
>>  On Apr 21, 2008, at 10:53 AM, William Stein wrote:
>>
>>> On Mon, Apr 21, 2008 at 10:51 AM, mabshoff
>>> <[EMAIL PROTECTED]> wrote:

  Hi,


> Could you "rebase" the entire Sage repo so it has the new hashes,
> then included
> it for Sage-3.0 :-)  If we're going to make a massive change like
> that, 3.0 would
> be the time to do it.  Or does that request make no sense?

  We will likely have the same problem every time we merge heads  
 if I
  understand the problem correctly. We also have about 40 patches
  outstanding [at any given time it seems - the number seems to
  oscillate around 40] and all of those would need to be rebased.
 Since
  the repo-as-text is a very specific case and in case it would
 have to
  be redone after each branch merge I see little benefit to do it.

>>>
>>> I'll let Robert answer, but he said "Yes, they changed the way  
>>> they do
>>> hashing,",
>>> and I'm proposing somehow updating our repo so that throughout it  
>>> uses
>>> their new way of doing hashing.  I'm not proposing something that
>>> would
>>> happen more than once.
>>>
>>> William
>>
>>  Yes, I could. This would mean that no pre-3.0 bundles would apply to
>>  post-3.0 (short of re-basing the bundles--and the big one (coercion)
>>  I could rebase myself). Patches should be just fine, and most things
>>  aren't big enough to warrant bundles. Does anyone know if mercurial
>>  1.0 changed how hashing is done (yet again) or is it finally stable?
>>  If so I think this would be a good thing to do.
>>
>
> Well this is definitely the right *time* to do it.

I'll do that then. Probably best to do right before the release, to  
not disrupt the development cycle (and as the actual code won't  
change (check with a diff) we won't need to be concerned about  
breaking Sage). Perhaps the other packages should be changed as well.

- Robert


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.rc0 released!

[Gonzalo Tornaria]

On 4/21/08, John Cremona <[EMAIL PROTECTED]> wrote:
>  Better late than never (perhaps):  rc0 built fine for me but has two
>  failures with testall:

Same here, rc0, both on a 64 bit and a 32 bit build. In the 64 bit
build (A) there is also a failure in rings/real_double.pyx. I will
compile rc1 on the P4D64 now.

A) Intel(R) Pentium(R) D CPU 3.00GHz (dual core)
debian/testing - 64 bits
gcc-4.3 (Debian 4.3.0-3) 4.3.1 20080401 (prerelease)
kernel 2.6.18-5-amd64 #1 SMP Thu Aug 30 01:14:54 UTC 2007 x86_64
GNU/Linux (stock debian kernel)

--
The following tests failed:


sage -t  devel/sage/sage/interfaces/r.py
sage -t  devel/sage/sage/rings/real_double.pyx
sage -t  devel/sage/sage/rings/polynomial/laurent_polynomial_ring.py
Total time for all tests: 3534.4 seconds
grep: /home/tornaria/sage/sage-3.0.rc0-p4d/tmp/test-dsage.log: No such
file or directory
Please see /home/tornaria/sage/sage-3.0.rc0-p4d/tmp/test.log for the
complete log from this test.

--


B) Genuine Intel(R) CPU2140  @ 1.60GHz
Debian/testing 32 bits
gcc version 4.2.3 (Debian 4.2.3-3)
kernel 2.6.22-2-686 #1 SMP Fri Aug 31 00:24:01 UTC 2007 i686 GNU/Linux
--
The following tests failed:


sage -t  devel/sage/sage/interfaces/r.py
sage -t  devel/sage/sage/rings/polynomial/laurent_polynomial_ring.py
Total time for all tests: 8160.6 seconds
grep: /home/cmat/tornaria/sage/sage-3.0.rc0/tmp/test-dsage.log: No
such file or directory
Please see /home/cmat/tornaria/sage/sage-3.0.rc0/tmp/test.log for the
complete log from this test.

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Fwd: mercurial --> plain text --> mercurial

[William Stein]

On Mon, Apr 21, 2008 at 11:06 AM, Robert Bradshaw
<[EMAIL PROTECTED]> wrote:
>
>
>  On Apr 21, 2008, at 10:53 AM, William Stein wrote:
>
>  > On Mon, Apr 21, 2008 at 10:51 AM, mabshoff
>  > <[EMAIL PROTECTED]> wrote:
>  >>
>  >>  Hi,
>  >>
>  >>
>  >>> Could you "rebase" the entire Sage repo so it has the new hashes,
>  >>> then included
>  >>> it for Sage-3.0 :-)  If we're going to make a massive change like
>  >>> that, 3.0 would
>  >>> be the time to do it.  Or does that request make no sense?
>  >>
>  >>  We will likely have the same problem every time we merge heads if I
>  >>  understand the problem correctly. We also have about 40 patches
>  >>  outstanding [at any given time it seems - the number seems to
>  >>  oscillate around 40] and all of those would need to be rebased.
>  >> Since
>  >>  the repo-as-text is a very specific case and in case it would
>  >> have to
>  >>  be redone after each branch merge I see little benefit to do it.
>  >>
>  >
>  > I'll let Robert answer, but he said "Yes, they changed the way they do
>  > hashing,",
>  > and I'm proposing somehow updating our repo so that throughout it uses
>  > their new way of doing hashing.  I'm not proposing something that
>  > would
>  > happen more than once.
>  >
>  > William
>
>  Yes, I could. This would mean that no pre-3.0 bundles would apply to
>  post-3.0 (short of re-basing the bundles--and the big one (coercion)
>  I could rebase myself). Patches should be just fine, and most things
>  aren't big enough to warrant bundles. Does anyone know if mercurial
>  1.0 changed how hashing is done (yet again) or is it finally stable?
>  If so I think this would be a good thing to do.
>

Well this is definitely the right *time* to do it.

william

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Fwd: mercurial --> plain text --> mercurial

[Robert Bradshaw]

On Apr 21, 2008, at 10:53 AM, William Stein wrote:

> On Mon, Apr 21, 2008 at 10:51 AM, mabshoff
> <[EMAIL PROTECTED]> wrote:
>>
>>  Hi,
>>
>>
>>> Could you "rebase" the entire Sage repo so it has the new hashes,  
>>> then included
>>> it for Sage-3.0 :-)  If we're going to make a massive change like
>>> that, 3.0 would
>>> be the time to do it.  Or does that request make no sense?
>>
>>  We will likely have the same problem every time we merge heads if I
>>  understand the problem correctly. We also have about 40 patches
>>  outstanding [at any given time it seems - the number seems to
>>  oscillate around 40] and all of those would need to be rebased.  
>> Since
>>  the repo-as-text is a very specific case and in case it would  
>> have to
>>  be redone after each branch merge I see little benefit to do it.
>>
>
> I'll let Robert answer, but he said "Yes, they changed the way they do
> hashing,",
> and I'm proposing somehow updating our repo so that throughout it uses
> their new way of doing hashing.  I'm not proposing something that  
> would
> happen more than once.
>
> William

Yes, I could. This would mean that no pre-3.0 bundles would apply to  
post-3.0 (short of re-basing the bundles--and the big one (coercion)  
I could rebase myself). Patches should be just fine, and most things  
aren't big enough to warrant bundles. Does anyone know if mercurial  
1.0 changed how hashing is done (yet again) or is it finally stable?  
If so I think this would be a good thing to do.

- Robert


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Project

[Mike Hansen]

I get the following error:

;; Compiling ../lsp/gcl_listlib.lsp.
;; End of Pass 1.
;; End of Pass 2.
;; OPTIMIZE levels: Safety=3, Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling ../lsp/gcl_listlib.o.
;; Loading /opt/sage-3.0.alpha6/spkg/build/gcl-20080421/src/lsp/gcl_listlib.o
__stack_chk_fail is undefined

Error: ERROR "Cannot get relocated section contents
"
Fast links are on: do (si::use-fast-links nil) for debugging
Signalled by LOAD1.
ERROR "Cannot get relocated section contents
"

Broken at LOAD1.  Type :H for Help.
>>make: *** [unixport/saved_pre_gcl] Error 255
Error building GCL.

--Mike

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Compile Error

[William Stein]

On Mon, Apr 21, 2008 at 10:53 AM, Andrzej Giniewicz <[EMAIL PROTECTED]> wrote:
>
>  Also have same error with both .p13 and .p14, but by some random case
>  I got other error when run make for the second time, there is complete
>  log from first build: www.giniu.ravenlord.ws/install.log.1 (HUGE one),
>  and there is second one, small log from second build
>  ( www.giniu.ravenlord.ws/install.log.2 ) - to sum it short, first was
>  exactly same as before, second one gave:
>
>  gcc -I/opt/sage-3.0.rc1/local/include -g -O2 -W -Wswitch -Wcomment -
>  Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-
>
> sign-compare -O2 -fexpensive-optimizations -falign-functions=4 -
>  DNO_MULTIMAP_SHM -DNO_MULTIMAP_FILE -DNO_SINGLEMAP -DNO_TRIVIALMAP -
>  DUNICODE -I. -c spvw.c
>
> In file included from lispbibl.d:325,
>  from spvw.d:24:
>  floatparam.h:18:2: error: #error "Unknown rounding mode for type
>  double!"
>
>  I don't know if this because make was runned after broken build or
>  what, but that's what I got... anyway - will try other ways (flag and
>  distro package...), distro package for sure works, there is script
>  used to build clisp under Arch with GCC4.3:
>  
> http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/devel/clisp/PKGBUILD?rev=1.2&cvsroot=Extra&only_with_tag=CURRENT&content-type=text/vnd.viewcvs-markup
>
>  hope it helps, if there is anything I can do/test/check to help with
>  I'll be happy to do it
>

We've been building Sage with that clisp under Arch linux 32-bit and
it works fine, using gcc-4.3.  What exact Arch are you using?  32-bit
or 64-bit?  Which hardware?  cat /proc/cpuinfo.

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Compile Error

[Andrzej Giniewicz]

Also have same error with both .p13 and .p14, but by some random case
I got other error when run make for the second time, there is complete
log from first build: www.giniu.ravenlord.ws/install.log.1 (HUGE one),
and there is second one, small log from second build
( www.giniu.ravenlord.ws/install.log.2 ) - to sum it short, first was
exactly same as before, second one gave:

gcc -I/opt/sage-3.0.rc1/local/include -g -O2 -W -Wswitch -Wcomment -
Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-
sign-compare -O2 -fexpensive-optimizations -falign-functions=4 -
DNO_MULTIMAP_SHM -DNO_MULTIMAP_FILE -DNO_SINGLEMAP -DNO_TRIVIALMAP -
DUNICODE -I. -c spvw.c
In file included from lispbibl.d:325,
 from spvw.d:24:
floatparam.h:18:2: error: #error "Unknown rounding mode for type
double!"

I don't know if this because make was runned after broken build or
what, but that's what I got... anyway - will try other ways (flag and
distro package...), distro package for sure works, there is script
used to build clisp under Arch with GCC4.3:
http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/devel/clisp/PKGBUILD?rev=1.2&cvsroot=Extra&only_with_tag=CURRENT&content-type=text/vnd.viewcvs-markup

hope it helps, if there is anything I can do/test/check to help with
I'll be happy to do it

regards,
Andrzej.



On 21 Kwi, 18:47, "William Stein" <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 21, 2008 at 9:42 AM,  <[EMAIL PROTECTED]> wrote:
>
> >  And by same error I mean the one I initially started this thread with,
> >  sorry about the ambiguity.
>
> Thanks.  That's helpful.  Unfortunately it also means at least I have
> no clue how to fix the problem.
>
> You might try just installing clisp system-wide (using your package
> management system), then tell SAge to use that by typing in SAGE_ROOT
>
>touch spkg/installed/clisp-2.41.p14
>
> and also
>
>   touch spkg/installed/clisp-2.41.p13
>
> for good measure, then typing
>
>  make
>
> to continue the build as if clisp successfully installed.
>
> William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Disable ENABLE_PADLOCK_SUPPORT?

[mabshoff]

On Apr 21, 6:54 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 21, 2008 at 9:31 AM, Rob Goedman <[EMAIL PROTECTED]> wrote:
> > Hi,
>
> >  Brand new to Sage builds!
>
> >  On Mac OS 10.5.2, with:
>
> >  Robs-Intel:sage-3.0.rc0 rob$ gcc -v
> >  Using built-in specs.
> >  Target: i686-apple-darwin9
> >  Configured with: /var/tmp/gcc_42/gcc_42-5531~1/src/configure --disable-
> >  checking -enable-werror --prefix=/usr --mandir=/usr/share/man --enable-
> >  languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/
> >  $/-4.2/ --with-gxx-include-dir=/usr/include/c++/4.0.0 --with-slibdir=/
> >  usr/lib --build=i686-apple-darwin9 --host=i686-apple-darwin9 --
> >  target=i686-apple-darwin9
> >  Thread model: posix
> >  gcc version 4.2.1 (Apple Inc. build 5531)
>
> ^^^
>
> Which version of XCode is this?  When did you get it?
> I'm sure your problem is that we haven't ported Sage to work
> with Apple's heavily hacked GCC-4.2.1.

Nah, this is libgcrypt acting stupid, i.e. padlock is only available
on VIA CPUs IIRC. So unless somebody did something they are no
supposed to it is something we can configure around.

> I've been building all my OS X code on all platforms using
> Apples GCC-4.0.1.   I wasn't aware that they released GCC-4.2.1.
> My guess is that numerous things will have to be fixed to get
> Sage to build against APPLE-GCC-4.2.1.  Your best bet
> is to install a binary or install an older XCode (with GCC-4.0.1)
> or wait until Sage supports GCC-4.2.1, which means 1-2 weeks
> (since obviously I'll upgrade and have to support the newer compiler).

Yeah, let's get the new XCode up and running and solve those problems
in Sage 3.0.1.

Cheers,

Michael

> --
> William Stein
> Associate Professor of Mathematics
> University of Washingtonhttp://wstein.org
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Fwd: mercurial --> plain text --> mercurial

[William Stein]

On Mon, Apr 21, 2008 at 10:51 AM, mabshoff
<[EMAIL PROTECTED]> wrote:
>
>  Hi,
>
>
>  > Could you "rebase" the entire Sage repo so it has the new hashes, then 
> included
>  > it for Sage-3.0 :-)  If we're going to make a massive change like
>  > that, 3.0 would
>  > be the time to do it.  Or does that request make no sense?
>
>  We will likely have the same problem every time we merge heads if I
>  understand the problem correctly. We also have about 40 patches
>  outstanding [at any given time it seems - the number seems to
>  oscillate around 40] and all of those would need to be rebased. Since
>  the repo-as-text is a very specific case and in case it would have to
>  be redone after each branch merge I see little benefit to do it.
>

I'll let Robert answer, but he said "Yes, they changed the way they do
hashing,",
and I'm proposing somehow updating our repo so that throughout it uses
their new way of doing hashing.  I'm not proposing something that would
happen more than once.

William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Fwd: mercurial --> plain text --> mercurial

[mabshoff]

Hi,

> Could you "rebase" the entire Sage repo so it has the new hashes, then 
> included
> it for Sage-3.0 :-)  If we're going to make a massive change like
> that, 3.0 would
> be the time to do it.  Or does that request make no sense?

We will likely have the same problem every time we merge heads if I
understand the problem correctly. We also have about 40 patches
outstanding [at any given time it seems - the number seems to
oscillate around 40] and all of those would need to be rebased. Since
the repo-as-text is a very specific case and in case it would have to
be redone after each branch merge I see little benefit to do it.

> Wiliam

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Fwd: mercurial --> plain text --> mercurial

[William Stein]

On Mon, Apr 21, 2008 at 10:32 AM, Robert Bradshaw
<[EMAIL PROTECTED]> wrote:
>
>
>  On Apr 21, 2008, at 7:12 AM, William Stein wrote:
>
>  > On Thu, Mar 27, 2008 at 4:49 PM, Robert Bradshaw
>  > <[EMAIL PROTECTED]> wrote:
>  >>
>  >>  I've looked into this some more and it looks like we can completely
>  >>  reconstruct a repository from the export of all its keywords. The
>  >>  trick is to use the --exact keyword when importing. This forces
>  >> it to
>  >>  apply the given patch to the correct parent (sometimes creating a
>  >> new
>  >>  head) and will also correctly import merge patches (removing heads).
>  >>  Some scripts to do this are up at
>  >>
>  >>  http://sage.math.washington.edu/home/robertwb/hg/
>  >>
>  >>  I've successfully exported and re-created simple repositories (with
>  >>  branching) with these scripts, and it works great and preserves all
>  >>  the history. The only issue is that I can't seem to get it to work
>  >>  with any repositories older than a certain date. I think the
>  >> issue is
>  >>  that mercurial changed the way nodeid's are calculated (and I keep
>  >>  getting an error "abort: patch is damaged or loses information"
>  >> which
>  >>  is thrown when the newly computed nodeid does not match the one in
>  >>  the patch (command.py:1632 in 0.9.5)). Matt Mackall, any suggestions
>  >>  on how to cleanly get around this/get the old node-id numbers
>  >> instead
>  >
>  > Robert,
>  >
>  > Did you ever get a response to this question?  Any updates on this?
>  >
>  > William
>
>  Yes, they changed the way they do hashing, so if you commit the same
>  sequence of patches you will get different nodeids than you would
>  have in the past. This is how parents are identified, so will result
>  in missing parent errors.
>
>  I have a hacked version of mercurial that will keep a correspondance
>  between old and new hashes that allows you to recreate a repository
>  from the list of patches alone (this is how I rebased Cython,
>  exporting the patches, running them through a diff to change the
>  paths, and recreating the repo from those). One drawback is that the
>  nodeid's will be different so the repositories aren't compatible
>  anymore. (I also know how to change it the other way, so the
>  "computed" hash will just be the old one if available.)
>
>  If people are interested, I could try and release a less hackish patch.
>

Could you "rebase" the entire Sage repo so it has the new hashes, then included
it for Sage-3.0 :-)  If we're going to make a massive change like
that, 3.0 would
be the time to do it.  Or does that request make no sense?

Wiliam

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Fwd: mercurial --> plain text --> mercurial

[Robert Bradshaw]

On Apr 21, 2008, at 7:12 AM, William Stein wrote:

> On Thu, Mar 27, 2008 at 4:49 PM, Robert Bradshaw
> <[EMAIL PROTECTED]> wrote:
>>
>>  I've looked into this some more and it looks like we can completely
>>  reconstruct a repository from the export of all its keywords. The
>>  trick is to use the --exact keyword when importing. This forces  
>> it to
>>  apply the given patch to the correct parent (sometimes creating a  
>> new
>>  head) and will also correctly import merge patches (removing heads).
>>  Some scripts to do this are up at
>>
>>  http://sage.math.washington.edu/home/robertwb/hg/
>>
>>  I've successfully exported and re-created simple repositories (with
>>  branching) with these scripts, and it works great and preserves all
>>  the history. The only issue is that I can't seem to get it to work
>>  with any repositories older than a certain date. I think the  
>> issue is
>>  that mercurial changed the way nodeid's are calculated (and I keep
>>  getting an error "abort: patch is damaged or loses information"  
>> which
>>  is thrown when the newly computed nodeid does not match the one in
>>  the patch (command.py:1632 in 0.9.5)). Matt Mackall, any suggestions
>>  on how to cleanly get around this/get the old node-id numbers  
>> instead
>
> Robert,
>
> Did you ever get a response to this question?  Any updates on this?
>
> William

Yes, they changed the way they do hashing, so if you commit the same  
sequence of patches you will get different nodeids than you would  
have in the past. This is how parents are identified, so will result  
in missing parent errors.

I have a hacked version of mercurial that will keep a correspondance  
between old and new hashes that allows you to recreate a repository  
from the list of patches alone (this is how I rebased Cython,  
exporting the patches, running them through a diff to change the  
paths, and recreating the repo from those). One drawback is that the  
nodeid's will be different so the repositories aren't compatible  
anymore. (I also know how to change it the other way, so the  
"computed" hash will just be the old one if available.)

If people are interested, I could try and release a less hackish patch.

- Robert


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Disable ENABLE_PADLOCK_SUPPORT?

[William Stein]

On Mon, Apr 21, 2008 at 9:31 AM, Rob Goedman <[EMAIL PROTECTED]> wrote:
> Hi,
>
>  Brand new to Sage builds!
>
>  On Mac OS 10.5.2, with:
>
>  Robs-Intel:sage-3.0.rc0 rob$ gcc -v
>  Using built-in specs.
>  Target: i686-apple-darwin9
>  Configured with: /var/tmp/gcc_42/gcc_42-5531~1/src/configure --disable-
>  checking -enable-werror --prefix=/usr --mandir=/usr/share/man --enable-
>  languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/
>  $/-4.2/ --with-gxx-include-dir=/usr/include/c++/4.0.0 --with-slibdir=/
>  usr/lib --build=i686-apple-darwin9 --host=i686-apple-darwin9 --
>  target=i686-apple-darwin9
>  Thread model: posix
>  gcc version 4.2.1 (Apple Inc. build 5531)
^^^

Which version of XCode is this?  When did you get it?
I'm sure your problem is that we haven't ported Sage to work
with Apple's heavily hacked GCC-4.2.1.

I've been building all my OS X code on all platforms using
Apples GCC-4.0.1.   I wasn't aware that they released GCC-4.2.1.
My guess is that numerous things will have to be fixed to get
Sage to build against APPLE-GCC-4.2.1.  Your best bet
is to install a binary or install an older XCode (with GCC-4.0.1)
or wait until Sage supports GCC-4.2.1, which means 1-2 weeks
(since obviously I'll upgrade and have to support the newer compiler).

The compiler I use:
bsd:~ was$ gcc -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5465~16/src/configure
--disable-checking -enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=i686-apple-darwin9 --with-arch=apple --with-tune=generic
--host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5465)
bsd:~ was$


 -- William

>
>  make gives below (summarized) error on 2.11, alpha6, rc0 and rc1.
>  Below attachment contains the complete rc1 install.log .
>
>  If, as a quick test, the Mac specific '-fasm-blocks' flag is added in
>  the subdir cipher, make complains about the assembler code in the asm
>  block in poll_padlock.
>
>  Do I have to disable ENABLE_PADLOCK_SUPPORT? If so, can I force the
>  sage make to use './configure -disable_padlock_support'?
>
>  As this is not related to the upcoming Sage 3.0 release, I'm fine to
>  wait for a binary release, although ultimately I would like to be able
>  to build sage myself.
>
>  Thanks,
>  Rob
>
>  --
>
>  Making all in cipher
>  /bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -
>  I..  -I../src -I../src  -I/Users/rob/Downloads/sage-3.0.rc0/local/
>  include -I/Users/rob/Downloads/sage-3.0.rc0/local/include -g -O2 -Wall
>  -Wpointer-arith -MT cipher.lo -MD -MP -MF .deps/cipher.Tpo -c -o
>  cipher.lo cipher.c
>  mkdir .libs
>   gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/Users/rob/
>  Downloads/sage-3.0.rc0/local/include -I/Users/rob/Downloads/
>  sage-3.0.rc0/local/include -g -O2 -Wall -Wpointer-arith -MT cipher.lo -
>  MD -MP -MF .deps/cipher.Tpo -c cipher.c  -fno-common -DPIC -o .libs/
>  cipher.o
>   gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/Users/rob/
>  Downloads/sage-3.0.rc0/local/include -I/Users/rob/Downloads/
>  sage-3.0.rc0/local/include -g -O2 -Wall -Wpointer-arith -MT cipher.lo -
>  MD -MP -MF .deps/cipher.Tpo -c cipher.c -o cipher.o >/dev/null 2>&1
>  mv -f .deps/cipher.Tpo .deps/cipher.Plo
>  /bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -
>  I..  -I../src -I../src  -I/Users/rob/Downloads/sage-3.0.rc0/local/
>  include -I/Users/rob/Downloads/sage-3.0.rc0/local/include -g -O2 -Wall
>  -Wpointer-arith -MT pubkey.lo -MD -MP -MF .deps/pubkey.Tpo -c -o
>  pubkey.lo pubkey.c
>   gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/Users/rob/
>  Downloads/sage-3.0.rc0/local/include -I/Users/rob/Downloads/
>  sage-3.0.rc0/local/include -g -O2 -Wall -Wpointer-arith -MT pubkey.lo -
>  MD -MP -MF .deps/pubkey.Tpo -c pubkey.c  -fno-common -DPIC -o .libs/
>  pubkey.o
>
>  ...
>
>   gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/Users/rob/
>  Downloads/sage-3.0.rc0/local/include -I/Users/rob/Downloads/
>  sage-3.0.rc0/local/include -g -O2 -Wall -Wpointer-arith -MT random.lo -
>  MD -MP -MF .deps/random.Tpo -c random.c  -fno-common -DPIC -o .libs/
>  random.o
>   gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/Users/rob/
>  Downloads/sage-3.0.rc0/local/include -I/Users/rob/Downloads/
>  sage-3.0.rc0/local/include -g -O2 -Wall -Wpointer-arith -MT random.lo -
>  MD -MP -MF .deps/random.Tpo -c random.c -o random.o >/dev/null 2>&1
>  mv -f .deps/random.Tpo .deps/random.Plo
>  /bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -
>  I..  -I../src -I../src  -I/Users/rob/Downloads/sage-3.0.rc0/local/
>  include -I/Users/rob/Downloads/sage-3.0.rc0/local/include -g -O2 -Wall
>  -Wpointer-arith -MT rndhw.lo -MD -MP -MF .de

[sage-devel] Re: Sage 3.0.rc0 released!

[John Cremona]

Better late than never (perhaps):  rc0 built fine for me but has two
failures with testall:

  sage -t  devel/sage/sage/interfaces/r.py
  sage -t  devel/sage/sage/rings/polynomial/laurent_polynomial_ring.py

That's on a 32-bit machine running kubuntu:
Linux fermat 2.6.22-14-generic #1 SMP Tue Feb 12 07:42:25 UTC 2008
i686 GNU/Linux
with
gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)

I'll get going on rc1 -- never a dull moment with Sage!

John


2008/4/21 mabshoff <[EMAIL PROTECTED]>:
>
>
>
>  On Apr 21, 11:01 am, bill purvis <[EMAIL PROTECTED]> wrote:
>  > On Sunday 20 April 2008, mabshoff wrote:
>  >
>  > > Hello folks,
>  >
>  > > Here goes 3.0.rc0. We knocked out a couple blocker, merged the new
>  > > R pexpect interface. This release should also build out of the box
>  > > on RHEL 5/Itanium and SLES 10/Itanium without the need to set any
>  > > FORTRAN env variables. We have a new blocker (#2972), some doctest
>  > > failures with the R doctests, but things are moving toward a stable
>  > > 3.0 release. We also merged a lot of Debian build fixes, so we should
>  > > finally get close to the release. So please build, doctest and report
>  > > and issues you come across. We closed a total of 254 tickets so far.
>  >
>  > > Sources and binaries are in the usual place:
>  >
>  > >http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0/sage...
>  > >c0.tar
>  >
>  > >http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0/sage...
>
> > >c0-sage.math-only-x86_64-Linux.tar.gz
>  >
>  > Sorry I've not been able to do any tests on the alphas - tied up with other
>  > matters.
>  >
>  > System is a Toshiba laptop 2.9GHz Celeron, 512Mb RAM.
>  >
>  > 3.0.rc0 Compiled fine, two failures in make test:
>  >
>
>  Hi Bill,
>
>  both issues have been fixed in 3.0.rc1 - out for about 5 minutes ;)
>
>  Thanks for reporting the issues.
>
>  >
>  > Bill
>
>  Cheers,
>
>  Michael
>
>  > --
>  > +---+
>  > | Bill Purvis, Amateur Mathematician|
>  > |  email: [EMAIL PROTECTED]|
>
>
> > +---+
>  >
>

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Compile Error

[William Stein]

On Mon, Apr 21, 2008 at 9:42 AM,  <[EMAIL PROTECTED]> wrote:
>
>  And by same error I mean the one I initially started this thread with,
>  sorry about the ambiguity.

Thanks.  That's helpful.  Unfortunately it also means at least I have
no clue how to fix the problem.

You might try just installing clisp system-wide (using your package
management system), then tell SAge to use that by typing in SAGE_ROOT

   touch spkg/installed/clisp-2.41.p14

and also

  touch spkg/installed/clisp-2.41.p13

for good measure, then typing

 make

to continue the build as if clisp successfully installed.

William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Project

[Gabriel Dos Reis]

On Mon, Apr 21, 2008 at 11:09 AM, root <[EMAIL PROTECTED]> wrote:

>  GCL runs on windows although I have not spent any time on a
>  windows port. Waldek has, so he might have an opinion.

Well, *I* spend considerable time making Axiom buildable
on Windows back when I was working
on Axiom.build-improvements, which is the basis for both OpenAxiom
and Fricas.  The build environment requirement
is the usual msys/mingw (which makes the life a bit more
bearable on that platform, when working with most software
based on GNU toolchains).You need on thing:  you need
to make rsym.exe callable when dumping the final image to disk.
rsym.exe is built by GCL but for some reasons (mostly related to
pathnames I guess), GCL is unable to find it.  See the hack
@axiom_gcl_rsym_hack@ I introduced here
http://axiom.svn.sourceforge.net/viewvc/axiom/branches/build-improvements/configure.ac.pamphlet?r1=393&r2=395

to be used in:
http://axiom.svn.sourceforge.net/viewvc/axiom/branches/build-improvements/src/lisp/Makefile.in?revision=395&view=markup

> Given
>  what I know about GCL internals I have every reason to believe
>  that it would compile using MS or Borland compilers (modulo a
>  few #ifdefs to pay homage to C). I don't have access to a native
>  C compiler for windows.

Please try it for real and tell us how is works, for GCL has a strong dependency
on GCC.

-- Gaby

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Compile Error

[AMC718]

And by same error I mean the one I initially started this thread with,
sorry about the ambiguity.
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Compile Error

[AMC718]

Yessir, I tried it both ways, the first way gave me an error saying
that I didn't have CFLAGS set, here is the error:

gcc -I/home/zarathustra/Download/sage-3.0.rc1/local/include -g -O2 -W -
Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing
In file included from lispbibl.d:325,
 from spvw.d:24:
floatparam.h:18:2: error: #error "Unknown rounding mode for type
double!"
In file included from spvw.d:24:
lispbibl.d:9118: warning: register used for two global register
variables
make: *** [spvw.o] Error 1
Silly permissions error with first make of clisp.
Do a 'make' again, since second 'make' works.
Error building clisp.
executing /home/zarathustra/Download/sage-3.0.rc1/spkg/build/
clisp-2.41.p14/src/src/configure --disable-mmap --with-readline=/home/
zarathus
configure: loading cache config.cache
configure: error: `CFLAGS' was not set in the previous run
configure: error: changes in the environment can compromise the build
configure: error: run `make distclean' and/or `rm config.cache' and
start over
Error configuring clisp

real1m19.616s
user0m33.158s
sys 0m22.378s
sage: An error occurred while installing clisp-2.41.p14
Please email sage-devel http://groups.google.com/group/sage-devel
explaining the problem and send the relevant part of
of /home/zarathustra/Download/sage-3.0.rc1/install.log.  Describe your
computer, operating system, etc.
If you want to try to fix the problem, yourself *don't* just cd to
/home/zarathustra/Download/sage-3.0.rc1/spkg/build/clisp-2.41.p14 and
type 'make'.
Instead type "/home/zarathustra/Download/sage-3.0.rc1/sage -sh"
in order to set all environment variables correctly, then cd to
/home/zarathustra/Download/sage-3.0.rc1/spkg/build/clisp-2.41.p14
(When you are done debugging, you can type "exit" to leave the
subshell.)
You must set the SAGE_ROOT environment variable or
run this script from the SAGE_ROOT or
SAGE_ROOT/local/bin/ directory.
clisp-2.41.p14
Machine:
Linux localhost.localdomain 2.6.25-1.fc9.i686 #1 SMP Thu Apr 17
01:47:10 EDT 2008 i686 i686 i386 GNU/Linux

And I get the same error as above after setting the CFLAGS
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Compile Error

[William Stein]

On Mon, Apr 21, 2008 at 9:21 AM,  <[EMAIL PROTECTED]> wrote:
>
>  On Apr 21, 11:36 am, "William Stein" <[EMAIL PROTECTED]> wrote:
>  >
>  > Michael did not implement the -O0 thing as planned, since
>  > he ran out of time and got tired after working nearly nonstop
>  > on other issues with rc0.
>  >
>  > So I just made a clisp spkg for you to try.  It sets CFLAGS to -O0 if
>  > the initial compile fails.  This should work *if* clisp actually respects
>  > the CFLAGS option -- I have no idea if it does.
>  >
>  > Could you try installing this spkg:
>  >
>  >http://sage.math.washington.edu/home/was/build/sage-3.0.rc1/spkg/stan...
>
> >
>  > Just download it and do
>  >
>  > ./sage -i clisp-2.41.p14.spkg
>  >
>  > Let us know asap whether or not that build works.
>  >
>  > If it doesn't, please try;
>  >
>  >export CFLAGS="-O0" and then
>  >
>  > ./sage -i clisp-2.41.p13.spkg
>  >
>  > If that doesn't work, then a method other than setting CFLAGS will be 
> needed...
>  >
>  > I can't test this because on all of my vast range of test machines I don't
>  > have your problem (since most of those machines use GCC < 4.3).
>  >
>  >  -- william
>  >
>  >  -- William
>
>  Just tried it and got the same error again.

Did you try both the new spkg *and* explicitly setting CFLAGS via

  export CFLAGS="-O0

then building the spkg?

William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Compile Error

[AMC718]

On Apr 21, 11:36 am, "William Stein" <[EMAIL PROTECTED]> wrote:
>
> Michael did not implement the -O0 thing as planned, since
> he ran out of time and got tired after working nearly nonstop
> on other issues with rc0.
>
> So I just made a clisp spkg for you to try.  It sets CFLAGS to -O0 if
> the initial compile fails.  This should work *if* clisp actually respects
> the CFLAGS option -- I have no idea if it does.
>
> Could you try installing this spkg:
>
>    http://sage.math.washington.edu/home/was/build/sage-3.0.rc1/spkg/stan...
>
> Just download it and do
>
>     ./sage -i clisp-2.41.p14.spkg
>
> Let us know asap whether or not that build works.
>
> If it doesn't, please try;
>
>    export CFLAGS="-O0" and then
>
>     ./sage -i clisp-2.41.p13.spkg
>
> If that doesn't work, then a method other than setting CFLAGS will be 
> needed...
>
> I can't test this because on all of my vast range of test machines I don't
> have your problem (since most of those machines use GCC < 4.3).
>
>  -- william
>
>  -- William

Just tried it and got the same error again.
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Compile Error

[Martin Albrecht]

>export CFLAGS="-O0" and then
>
> ./sage -i clisp-2.41.p13.spkg
>
> If that doesn't work, then a method other than setting CFLAGS will be
> needed...


I had the same problem and 

   CFLAGS="-O0"; ./spkg-install (which is equivalent to the above)

in the appropriate "sage -sh" fixed the problem for me.

Martin



-- 
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
_www: http://www.informatik.uni-bremen.de/~malb
_jab: [EMAIL PROTECTED]


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Compile Error

[William Stein]

On Mon, Apr 21, 2008 at 8:26 AM,  <[EMAIL PROTECTED]> wrote:
>
>  On Apr 20, 10:04 pm, mabshoff <[EMAIL PROTECTED]
>
> dortmund.de> wrote:
>  > On Apr 21, 4:01 am, [EMAIL PROTECTED] wrote:
>  >
>
> > The plan now is to do the following:
>  >
>  >  a) Compile clisp with "-02" - if it works everybody is happy
>  >  b) If it doesn't work fall back to "-O0" and hope for the best.
>  >
>  > This fix will be in 3.0.rc1 later out tonight.
>  >
>  > Cheers,
>  >
>  > Michael
>
>  Just tried compiling rc1 and I get the exact same error.  I am
>  guessing plan "a" doesn't work for me.
>

Michael did not implement the -O0 thing as planned, since
he ran out of time and got tired after working nearly nonstop
on other issues with rc0.

So I just made a clisp spkg for you to try.  It sets CFLAGS to -O0 if
the initial compile fails.  This should work *if* clisp actually respects
the CFLAGS option -- I have no idea if it does.

Could you try installing this spkg:


http://sage.math.washington.edu/home/was/build/sage-3.0.rc1/spkg/standard/clisp-2.41.p14.spkg

Just download it and do

./sage -i clisp-2.41.p14.spkg

Let us know asap whether or not that build works.

If it doesn't, please try;

   export CFLAGS="-O0" and then

./sage -i clisp-2.41.p13.spkg

If that doesn't work, then a method other than setting CFLAGS will be needed...

I can't test this because on all of my vast range of test machines I don't
have your problem (since most of those machines use GCC < 4.3).

 -- william

 -- William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Compile Error

[AMC718]

On Apr 20, 10:04 pm, mabshoff <[EMAIL PROTECTED]
dortmund.de> wrote:
> On Apr 21, 4:01 am, [EMAIL PROTECTED] wrote:
>
> The plan now is to do the following:
>
>  a) Compile clisp with "-02" - if it works everybody is happy
>  b) If it doesn't work fall back to "-O0" and hope for the best.
>
> This fix will be in 3.0.rc1 later out tonight.
>
> Cheers,
>
> Michael

Just tried compiling rc1 and I get the exact same error.  I am
guessing plan "a" doesn't work for me.

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Project

[root]

>> I think you'd feel the same frustrations with Python if you compiled
>> Python from scratch for every platform. You ship "sources" but assume
>> that the python language exists and is compatible, which is not likely
>> to be the case when 3.0 arrives. If you can assume the python  
>> language,
>> why can't you assume the lisp language? If you can't assume the lisp
>> language, why can you assume the python language?
>
>We do compile python from scratch on every platform. It's part of the  
>Sage distribution.

+1 for you, -1 for me. 

t

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Project

[William Stein]

On Mon, Apr 21, 2008 at 9:09 AM, root <[EMAIL PROTECTED]> wrote:
>
>  >For example, is the fact that GCL doesn't build for us anywhere, something
>  >that you think we'll get passed by just trying harder?  Or is it going
>  >to be really really hard.
>
>  
>
>  All versions are built with GCL. I do not have access to a Sparc
>  although GCL has run there in the past. I no longer have access
>  to my Zaurus although GCL has run there in the past. I do have
>  access to an OLPC-XO. I release Axiom every two months so I'm
>  likely to get it working in the next release cycle.
>
>  GCL runs on windows although I have not spent any time on a
>  windows port. Waldek has, so he might have an opinion. Given
>  what I know about GCL internals I have every reason to believe
>  that it would compile using MS or Borland compilers (modulo a
>  few #ifdefs to pay homage to C). I don't have access to a native
>  C compiler for windows.
>
>  GCL is just a (big) C program and like every other C program I've
>  ever used, it is easily ported. But
>  the actual fact of the matter is that it does run everywhere I've
>  ever tried to make it run. All it requires is the right set of
>  ./configure switches.

It also requires the right set of dependencies.   And those themselves
can have all kinds of issues

> My collection above includes, I86-32,
>  I86-64, and PowerPC.
>
>
>
>
>
>  > The GCL-devel mailing list has on average about 5-6 messages a month
>  > during the last couple of months, except for a bunch of messages in
>  > January about people trying to build GCL from cvs.
>
>  You claim that you pass problem reports upstream but I don't see many
>  Sage postings to the GCL mailing list. Camm, the GCL maintainer, has
>  always been very responsive and effective in his replies. But, like
>  you, he needs good, clear, effective bug reports.

We chose clisp instead of GCL long ago for a number of reasons, so
there's been no reason for me to post to the gcl mailing list.

>  I think you'd feel the same frustrations with Python if you compiled
>  Python from scratch for every platform. You ship "sources" but assume
>  that the python language exists and is compatible, which is not likely
>  to be the case when 3.0 arrives. If you can assume the python language,
>  why can't you assume the lisp language? If you can't assume the lisp
>  language, why can you assume the python language?

You don't know what you're talking about here.   The python
build-from-source ecosystem is in much better shape than the lisp
one.Python has easily 100 times as many people supporting it
as clisp or gcl.

>  Having spent a fair portion of my life porting software, I understand
>  the frustrations you feel. And having spent the bulk of my life using
>  Lisp I "get" the get-rid-of-lisp pushback. But a lot of astonishingly
>  good computer algebra exists in lisp (we won't discuss the reasons).
>  Reproducing Axiom's "million-things-of-code" in Python would be no
>  small task, especially since some of the experts are dead.

In my opinion the best computer algebra system for research mathematics
on the planet is Magma, and it is written in C.

 -- William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Project

[David Harvey]

On Apr 21, 2008, at 12:09 PM, root wrote:

> I think you'd feel the same frustrations with Python if you compiled
> Python from scratch for every platform. You ship "sources" but assume
> that the python language exists and is compatible, which is not likely
> to be the case when 3.0 arrives. If you can assume the python  
> language,
> why can't you assume the lisp language? If you can't assume the lisp
> language, why can you assume the python language?

We do compile python from scratch on every platform. It's part of the  
Sage distribution.

david


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Project

[root]

>For example, is the fact that GCL doesn't build for us anywhere, something
>that you think we'll get passed by just trying harder?  Or is it going
>to be really really hard.



All versions are built with GCL. I do not have access to a Sparc
although GCL has run there in the past. I no longer have access
to my Zaurus although GCL has run there in the past. I do have
access to an OLPC-XO. I release Axiom every two months so I'm
likely to get it working in the next release cycle.

GCL runs on windows although I have not spent any time on a 
windows port. Waldek has, so he might have an opinion. Given
what I know about GCL internals I have every reason to believe
that it would compile using MS or Borland compilers (modulo a
few #ifdefs to pay homage to C). I don't have access to a native
C compiler for windows.

GCL is just a (big) C program and like every other C program I've
ever used, it is easily ported. But
the actual fact of the matter is that it does run everywhere I've
ever tried to make it run. All it requires is the right set of
./configure switches. My collection above includes, I86-32, 
I86-64, and PowerPC.




> The GCL-devel mailing list has on average about 5-6 messages a month
> during the last couple of months, except for a bunch of messages in
> January about people trying to build GCL from cvs.

You claim that you pass problem reports upstream but I don't see many
Sage postings to the GCL mailing list. Camm, the GCL maintainer, has
always been very responsive and effective in his replies. But, like
you, he needs good, clear, effective bug reports.




I think you'd feel the same frustrations with Python if you compiled
Python from scratch for every platform. You ship "sources" but assume
that the python language exists and is compatible, which is not likely
to be the case when 3.0 arrives. If you can assume the python language,
why can't you assume the lisp language? If you can't assume the lisp
language, why can you assume the python language? 


Having spent a fair portion of my life porting software, I understand
the frustrations you feel. And having spent the bulk of my life using
Lisp I "get" the get-rid-of-lisp pushback. But a lot of astonishingly
good computer algebra exists in lisp (we won't discuss the reasons).
Reproducing Axiom's "million-things-of-code" in Python would be no
small task, especially since some of the experts are dead.

Tim


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Fwd: mercurial --> plain text --> mercurial

[William Stein]

On Thu, Mar 27, 2008 at 4:49 PM, Robert Bradshaw
<[EMAIL PROTECTED]> wrote:
>
>  I've looked into this some more and it looks like we can completely
>  reconstruct a repository from the export of all its keywords. The
>  trick is to use the --exact keyword when importing. This forces it to
>  apply the given patch to the correct parent (sometimes creating a new
>  head) and will also correctly import merge patches (removing heads).
>  Some scripts to do this are up at
>
>  http://sage.math.washington.edu/home/robertwb/hg/
>
>  I've successfully exported and re-created simple repositories (with
>  branching) with these scripts, and it works great and preserves all
>  the history. The only issue is that I can't seem to get it to work
>  with any repositories older than a certain date. I think the issue is
>  that mercurial changed the way nodeid's are calculated (and I keep
>  getting an error "abort: patch is damaged or loses information" which
>  is thrown when the newly computed nodeid does not match the one in
>  the patch (command.py:1632 in 0.9.5)). Matt Mackall, any suggestions
>  on how to cleanly get around this/get the old node-id numbers instead

Robert,

Did you ever get a response to this question?  Any updates on this?


William

-- 
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Project

[William Stein]

 you can understand why I am more than
>  a little dubious about the build quality of gcl. All these are boxen
>  that build Sage fine [the Solaris boxen need a little help, i.e. about
>  2,3 fixes, but all that is getting merged back into Sage 3.0.1 or
>  3.0.2], so this is far from some FUBAR build box where I set gcl up to
>  fail.
>

In the defense of GCL, *most* components of Sage were a mess
like above when I/you/whoever first tried to add them to Sage.
I personally haven't tried much using cvs GCL only, partly because
it scares me to use cvs for a deployed quality product.  Since cvs
might be broken one day, not the next, etc., and one has no clue
if the code has been tested or not or what.  The last released
version is from 2005, and it's clear the website is just dead (maybe
somebody lost the password?!)  I mean, it just looks a little silly
for the website (http://www.gnu.org/software/gcl/) to start with:
   NEW! (20050810) GCL 2.6.7 is released. The release notes can be found  here.
   NEW! (20050427) Patch added to the errata page to reenable support
for si::run-process on linux.
   NEW! (20050402) Support for new texinfo format and precompiled
regexp searching posted to errata page.

The GCL-devel mailing list has on average about 5-6 messages a month
during the last couple of months, except for a bunch of messages in
January about people trying to build GCL from cvs.

I've made a gcl Sage optional spkg:

   http://sage.math.washington.edu/home/was/tmp/gcl/gcl-20080421.spkg

It's just GCL-from-cvs + a simple spkg-install.  I have never got it to build
on any system.   It's a pretty big spkg, since it appears to include the
entire gas assembler, some version of GMP, etc.  Try it out and see if
it *doesn't* work for you too :-)

   wget http://sage.math.washington.edu/home/was/tmp/gcl/gcl-20080421.spkg
   sage -i gcl-20080421.spkg

Bill Page -- I would be interested in any comments you might have.
For example, is the fact that GCL doesn't build for us anywhere, something
that you think we'll get passed by just trying harder?  Or is it going
to be really really hard.

 -- William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: [fricas-devel] Re: Project

[William Stein]

On Mon, Apr 21, 2008 at 3:22 AM, Ondrej Certik <[EMAIL PROTECTED]> wrote:
>
>
>  On Mon, Apr 21, 2008 at 9:25 AM, mabshoff
>  <[EMAIL PROTECTED]> wrote:
>  >
>  >  On Apr 21, 9:09 am, Martin Rubey <[EMAIL PROTECTED]> wrote:
>  >  > Just a quick note now, maybe more later:
>  >
>  >  
>  >
>  >  Hi Martin,
>  >
>  >
>  >  > > "I know of three open source implementations of lisp that do not need 
> to
>  >  > > bootstrap themselves"
>  >  >
>  >  > What's wrong with bootstrapping, and in particular with 
> sbcl?http://www.sbcl.org/platform-table.html
>  >
>  >  I like sbcl and it works well.
>  >
>  >
>  >  > Do you insist on building the lisp from scratch?
>  >
>  >  Yes.
>  >
>  >  > If so, why?
>  >
>  >  Shipping binaries is not an option due to size constraints. Requiring
>  >  some external version of lisp is tricky and Maxima for example behaves
>  >  differently, i.e. default precision of floats is different, with
>  >  different lisp implementations. And Sage is supposed to be a compile
>  >  from scratch & self hosting experience and while it usually isn't a
>  >  problem to find or install some version of lisp on Linux it is a pain
>  >  to do so on Windows or OSX. And Sage is supposed to be "easy" to
>  >  install and run and every external requirement makes it more
>  >  complicated. There are also important Sage users who greatly
>  >  appreciate the fact that every bit in Sage can be delivered in source.

Just to emphasize -- the fact that Sage can be built from source
on the supported platforms is perhaps the most basic requirement
at the core of the Sage project.
Sage is three things: (1) an easily buildable-from-source distribution
of math software; (2) a new library; (3) interfaces.   Part of the
definition of part (1) is that Sage be buildable from source
with only the following potentially nonstandard dependencies:

 gcc, g++, make, m4, perl, ranlib, and tar

This has not changed since day 1 of Sage and it won't, except
that eventually we may include gfortran in the list.

Note -- we currently ship some Fortran binaries with the Sage
source tarball, but they can easily be deleted if one has gfortran,
which is fairly standard.

>  >
>  >
>  >  > In any case, I think that clisp is not a very good choice for FriCAS 
> except
>  >  > that it is available almost everwhere.  SBCL based FriCAS is *a lot* 
> faster.  I
>  >  > do not have a clisp version handy, but SBCL vs. GCL makes a *factor* of 
> 2 for,
>  >  > eg., guessing.  CLISP is still slower.
>  >
>  >  Yes, we are well aware that clisp is quite bad performance wise
>  >  compared to gcl and especially sbcl, but we prefer a buildable lisp
>  >  over a potentially faster version that creates even more build
>  >  problems.

Hopefully the table here is wrong:

  http://www.sbcl.org/platform-table.html

It says the only supported platform for the most recently
released version of SBCL is Linux MIPS.   The most
recent before that -- version 1.0.12 ? -- says the only supported
platforms are:

Linux x86, Linux x86_64, and Mac OS X x86,

and that is it!  There is no version that has ever supported Microsoft Windows
according to that chart.

So unless the Sage developers want to start spending our time
porting sbcl, then SBCL is a non-option.   This is because we're
not going to start messing with using SBCL on one architecture, another
SBCL version on another architecture, GCL on another,
and clisp on yet a third.   The more I think about the mess
that is lisp compilers, the more I wish we didn't have any lisp
in Sage.

>  Well, you can first build clisp and then sbcl using clisp. :)

The *show stopper* problem with sbcl isn't building it but that
it doesn't support nearly enough platforms, and that nobody
seriously involved in Sage wants to work on porting lisp
compilers (as far as I know -- maybe I'm wrong?).

 -- William

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: [fricas-devel] Re: Project

[Ondrej Certik]

On Mon, Apr 21, 2008 at 9:25 AM, mabshoff
<[EMAIL PROTECTED]> wrote:
>
>  On Apr 21, 9:09 am, Martin Rubey <[EMAIL PROTECTED]> wrote:
>  > Just a quick note now, maybe more later:
>
>  
>
>  Hi Martin,
>
>
>  > > "I know of three open source implementations of lisp that do not need to
>  > > bootstrap themselves"
>  >
>  > What's wrong with bootstrapping, and in particular with 
> sbcl?http://www.sbcl.org/platform-table.html
>
>  I like sbcl and it works well.
>
>
>  > Do you insist on building the lisp from scratch?
>
>  Yes.
>
>  > If so, why?
>
>  Shipping binaries is not an option due to size constraints. Requiring
>  some external version of lisp is tricky and Maxima for example behaves
>  differently, i.e. default precision of floats is different, with
>  different lisp implementations. And Sage is supposed to be a compile
>  from scratch & self hosting experience and while it usually isn't a
>  problem to find or install some version of lisp on Linux it is a pain
>  to do so on Windows or OSX. And Sage is supposed to be "easy" to
>  install and run and every external requirement makes it more
>  complicated. There are also important Sage users who greatly
>  appreciate the fact that every bit in Sage can be delivered in source.
>
>
>  > In any case, I think that clisp is not a very good choice for FriCAS except
>  > that it is available almost everwhere.  SBCL based FriCAS is *a lot* 
> faster.  I
>  > do not have a clisp version handy, but SBCL vs. GCL makes a *factor* of 2 
> for,
>  > eg., guessing.  CLISP is still slower.
>
>  Yes, we are well aware that clisp is quite bad performance wise
>  compared to gcl and especially sbcl, but we prefer a buildable lisp
>  over a potentially faster version that creates even more build
>  problems.

Well, you can first build clisp and then sbcl using clisp. :)

Ondrej

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.rc0 released!

[mabshoff]

On Apr 21, 11:01 am, bill purvis <[EMAIL PROTECTED]> wrote:
> On Sunday 20 April 2008, mabshoff wrote:
>
> > Hello folks,
>
> > Here goes 3.0.rc0. We knocked out a couple blocker, merged the new
> > R pexpect interface. This release should also build out of the box
> > on RHEL 5/Itanium and SLES 10/Itanium without the need to set any
> > FORTRAN env variables. We have a new blocker (#2972), some doctest
> > failures with the R doctests, but things are moving toward a stable
> > 3.0 release. We also merged a lot of Debian build fixes, so we should
> > finally get close to the release. So please build, doctest and report
> > and issues you come across. We closed a total of 254 tickets so far.
>
> > Sources and binaries are in the usual place:
>
> >http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0/sage...
> >c0.tar
>
> >http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0/sage...
> >c0-sage.math-only-x86_64-Linux.tar.gz
>
> Sorry I've not been able to do any tests on the alphas - tied up with other
> matters.
>
> System is a Toshiba laptop 2.9GHz Celeron, 512Mb RAM.
>
> 3.0.rc0 Compiled fine, two failures in make test:
>

Hi Bill,

both issues have been fixed in 3.0.rc1 - out for about 5 minutes ;)

Thanks for reporting the issues.

>
> Bill

Cheers,

Michael

> --
> +---+
> | Bill Purvis, Amateur Mathematician    |
> |  email: [EMAIL PROTECTED]                |
> +---+
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Sage 3.0.rc1 released!

[mabshoff]

Hello folks,

here goes Sage 3.0.rc1. We are down to one blocker, i.e. the "-O0"
fallback for clips in case of failure. Other than that this release
should build and test fine. The 3.0 release is imminent, so if you
find anything you better be quick. The plan is to follow up the 3.0
release with one or two bug fix releases, i.e. 3.0.1 and 3.0.2. The
timing of those releases will depend on the coercion rewrite.

Sources and binaries are in the usual place:

http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0/sage-3.0.rc1.tar

http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0/sage-3.0.rc1-sage.math-only-x86_64-Linux.tar.gz

Cheers,

Michael

Merged in rc1:

#2419: William Stein, Simon King: Gap interface and resultant
   destroy the Singular interface on some machines
#2553: Yi Qiang, William Stein: dsage unit tests fail on linux
#2928: Willem Jan Palenstijn: another p-adic extension segfault
#2934: William Stein: doctesting files outside of sage repo is
   completely broken
#2972: William Stein: libSingular related segfault in
   laurent_polynomial_ring.py
#2973: Michael Abshoff: RDF doctest failures on arch linux
#2974: Mike Hansen: interfaces/r.py doctest failures on many
   linux machines
#2975: William Stein: opening ports too conservative -- breaks
   on some os x systems
#2977: Alex Ghitza: wronskian is broken on constants
#2984: William Stein, Michael Abshoff: ITANIUM (RHEL 5) -- turn
   off all unaligned access messages
#2986: Gonzalo Tornaria: Add atlas pretuning for Pentium D/64
   bits (ARCH=P4D64SSE3)

[I removed the rest of the other tickets merged]
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: Sage 3.0.rc0 released!

[bill purvis]

On Sunday 20 April 2008, mabshoff wrote:
> Hello folks,
>
> Here goes 3.0.rc0. We knocked out a couple blocker, merged the new
> R pexpect interface. This release should also build out of the box
> on RHEL 5/Itanium and SLES 10/Itanium without the need to set any
> FORTRAN env variables. We have a new blocker (#2972), some doctest
> failures with the R doctests, but things are moving toward a stable
> 3.0 release. We also merged a lot of Debian build fixes, so we should
> finally get close to the release. So please build, doctest and report
> and issues you come across. We closed a total of 254 tickets so far.
>
> Sources and binaries are in the usual place:
>
> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0/sage-3.0.r
>c0.tar
>
> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0/sage-3.0.r
>c0-sage.math-only-x86_64-Linux.tar.gz
>
Sorry I've not been able to do any tests on the alphas - tied up with other
matters.

System is a Toshiba laptop 2.9GHz Celeron, 512Mb RAM.

3.0.rc0 Compiled fine, two failures in make test:

--failure #1--

sage -t  devel/sage/sage/interfaces/r.py
**
File "/sage/sage-3.0.rc0/tmp/r.py", line 329:
sage: r.png(file='"%s"'%filename)
Expected:
NULL
Got:
[1] 10.4
**
File "/sage/sage-3.0.rc0/tmp/r.py", line 333:
sage: r.plot(x,y)
Expected:
NULL
Got:
[1] 3
**
File "/sage/sage-3.0.rc0/tmp/r.py", line 335:
sage: r.dev_off()
Expected:
null device
  1
Got:
[1] 2
**
File "/sage/sage-3.0.rc0/tmp/r.py", line 338:
sage: import os; os.unlink(filename)
Exception raised:
Traceback (most recent call last):
  File "/sage/sage-3.0.rc0/local/lib/python2.5/doctest.py", line 1228, in 
__run
compileflags, 1) in test.globs
  File "", line 1, in 
import os; os.unlink(filename)###line 338:
sage: import os; os.unlink(filename)
OSError: [Errno 2] No such file or 
directory: '/home/bill/.sage//temp/felix/12535//tmp_1.png'
**
File "/sage/sage-3.0.rc0/tmp/r.py", line 1064:
sage: r.png(file='"%s"'%filename)
Expected:
NULL
Got:
[1] 1
**
File "/sage/sage-3.0.rc0/tmp/r.py", line 1068:
sage: r.plot(x,y)
Expected:
NULL
Got:
[1] 1 2 3
**
File "/sage/sage-3.0.rc0/tmp/r.py", line 1070:
sage: r.dev_off()
Expected:
null device
  1
Got:
[1] 3
**
File "/sage/sage-3.0.rc0/tmp/r.py", line 1073:
sage: import os; os.unlink(filename)
Exception raised:
Traceback (most recent call last):
  File "/sage/sage-3.0.rc0/local/lib/python2.5/doctest.py", line 1228, in 
__run
compileflags, 1) in test.globs
  File "", line 1, in 
import os; os.unlink(filename)###line 1073:
sage: import os; os.unlink(filename)
OSError: [Errno 2] No such file or 
directory: '/home/bill/.sage//temp/felix/12535//tmp_2.png'
**
2 items had failures:
   4 of   8 in __main__.example_3
   4 of   8 in __main__.example_40
***Test Failed*** 8 failures.

failure #2

sage -t  
devel/sage/sage/rings/polynomial/laurent_polynomial_ring.pySegmentation fault 
(core dumped)

A mysterious error (perphaps a memory error?) occurred, which may have crashed 
doctest.
-end failures-

Bill
-- 
+---+
| Bill Purvis, Amateur Mathematician|
|  email: [EMAIL PROTECTED]|
+---+

--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: [fricas-devel] Re: Project

[mabshoff]

On Apr 21, 9:09 am, Martin Rubey <[EMAIL PROTECTED]> wrote:
> Just a quick note now, maybe more later:



Hi Martin,

> > "I know of three open source implementations of lisp that do not need to
> > bootstrap themselves"
>
> What's wrong with bootstrapping, and in particular with 
> sbcl?http://www.sbcl.org/platform-table.html

I like sbcl and it works well.

> Do you insist on building the lisp from scratch?  

Yes.

> If so, why?

Shipping binaries is not an option due to size constraints. Requiring
some external version of lisp is tricky and Maxima for example behaves
differently, i.e. default precision of floats is different, with
different lisp implementations. And Sage is supposed to be a compile
from scratch & self hosting experience and while it usually isn't a
problem to find or install some version of lisp on Linux it is a pain
to do so on Windows or OSX. And Sage is supposed to be "easy" to
install and run and every external requirement makes it more
complicated. There are also important Sage users who greatly
appreciate the fact that every bit in Sage can be delivered in source.

> In any case, I think that clisp is not a very good choice for FriCAS except
> that it is available almost everwhere.  SBCL based FriCAS is *a lot* faster.  
> I
> do not have a clisp version handy, but SBCL vs. GCL makes a *factor* of 2 for,
> eg., guessing.  CLISP is still slower.

Yes, we are well aware that clisp is quite bad performance wise
compared to gcl and especially sbcl, but we prefer a buildable lisp
over a potentially faster version that creates even more build
problems.



> Martin

Cheers,

Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---

[sage-devel] Re: [fricas-devel] Re: [sage-devel] Re: [fricas-devel] Re: Project

[Martin Rubey]

Just a quick note now, maybe more later:

"William Stein" <[EMAIL PROTECTED]> writes:

> I don't understand the Axiom distribution enough to understand
> how big it is, but my impression is that it is *also* huge.  Looking
> in the src/src/algebra directory there are many hundreds of
> thousands of lines of code (over 300,000 distinct lines just of
> dot-lsp files).  

These files are *not* the source code, they are the code produced by the SPAD
compiler.  The compilation process goes SPAD -> Lisp -> whatever the lisp
produces.

What you want to read are the xxx.spad.pamphlets.  They should be very clear to
read.  In fact, that was one of the more important reasons why I switched from
Maxima to Axiom.

> This is from INTALG.lsp.  Surely this is some machine-generated code that
> isn't meant to be human readable, so I'm measuring the wrong thing!

Oh, sorry.  You realized it already.  Well, it won't hurt.

> Some of the code is funny (from zmod.lsp):
> 
> (DEFUN |ZMOD;coerce;I$;24| (|n| $) (|ZMOD;bloodyCompiler| |n| $))

If you want to, I could even explain that line :-)

> Ahh, maybe the pamphlet files are what generate the lsp files.
> 
> It looks like the pamphlet files that come with fricas are between 100,000
> and 200,000 lines long.
> 
> How does the fricas/axiom source code layout work?  Is it all written in
> pamphlets that lisp is generated from?

The current strategy (at least from my point of view) is to have the maths
(i.e., everything in the algebra directory) in noweb (AKA pamphlet) form.  The
compiler and the interpreter itself use traditional documentation.  In my
opinion, this makes sense, since I want to use LaTeX to explain certain maths
(LaTeX was made for that), but the compiler and the interpreter do not contain
math on that level.

> "I know of three open source implementations of lisp that do not need to
> bootstrap themselves"

What's wrong with bootstrapping, and in particular with sbcl?
http://www.sbcl.org/platform-table.html

Do you insist on building the lisp from scratch?  If so, why?

In any case, I think that clisp is not a very good choice for FriCAS except
that it is available almost everwhere.  SBCL based FriCAS is *a lot* faster.  I
do not have a clisp version handy, but SBCL vs. GCL makes a *factor* of 2 for,
eg., guessing.  CLISP is still slower.

> Yes, indeed redo the guessing package in Sage/Python.  It will only help
> improve the code in both systems.  If you have the time I would strongly
> encourage you to do that.

No, I'm currently struggling to get a job, and it's not unlikely that I'll have
to quit in January anyway.  Furthermore, I doubt that it's interesting to
improve the code.  It would be interesting to improve the algorithm, though.

Martin


--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---