Re: [sage-devel] Call for vote: make top-level identity_matrix and zero_matrix constructors return mutable matrices again

On Jun 12, 2010, at 4:22 PM, Jason Grout wrote: A few months ago, #8276 made the MatrixSpace identity_matrix and zero_matrix methods return immutable matrices, following a discussion on sage-devel. A consequence of this (unintended, I hope!) was that the top-level identity_matrix and zero_

[sage-devel] Re: Call for vote: make top-level identity_matrix and zero_matrix constructors return mutable matrices again

I vote YES, because I think that in most cases when these functions are used the intention is to end up with something similar but not equal to the identity or zero matrix. Andrey -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email

Re: [sage-devel] Re: matplotlib is reading old system headers, in preference to Sage ones.

On 06/12/10 02:59 PM, Jason Grout wrote: On 06/12/2010 04:49 AM, David Kirkby wrote: On 12 June 2010 09:34, Georg S. Weber wrote: I mean what will happen on OS X? I have pkg-config installed automatically via MacPorts, so at least some OSX systems will have the program. In the case of matpl

Re: [sage-devel] Re: Error building Sage 4.4.3 under vanilla Debian lenny amd64: Error while installing flint

On 06/13/10 01:44 AM, orca wrote: Ok Hart I have now changed the make command to: make CC=c99 FC=gfortran-4.2 and a new error emerges: I've told you. You are wasting your time trying to set CC. I've set CC to be the Sun Studio compiler, but gcc still gets called many times. Some parts of Sa

Re: [sage-devel] Error building Sage 4.4.3 under vanilla Debian lenny amd64: Error while installing flint

On 06/12/10 10:30 PM, orca wrote: Dear Sirs, I have a palin vanilla Debian lenny amd64 machine, which I use for quite some time now; I am reasonably conversant (but not much) with some installation commands for programs in general. I have just tried to compile Sage 4.4.3 from source under that

[sage-devel] Re: Error building Sage 4.4.3 under vanilla Debian lenny amd64: Error while installing flint

Ok Hart I have now changed the make command to: make CC=c99 FC=gfortran-4.2 and a new error emerges: libtool: link: `/home/orca/sage/sage-4.4.3/spkg/build/ freetype-2.3.5.p2/src/objs/ftsystem.lo' is not a valid libtool object make[2]: *** [/home/orca/sage/sage-4.4.3/spkg/build/freetype-2.3.5.p2

[sage-devel] Re: Call for vote: make top-level identity_matrix and zero_matrix constructors return mutable matrices again

On 6/12/10 6:22 PM, Jason Grout wrote: 3. It breaks consistency with the 4 M's, which all return mutable matrices from the top-level identity matrix constructor. Correction: Maple identity matrices are immutable. However, Magma, Mathematica, and Matlab matrices identity matrix top-level comm

[sage-devel] Re: Error building Sage 4.4.3 under vanilla Debian lenny amd64: Error while installing flint

FLINT needs to compile with the -std=c99 flag. I presume someone overrode it somehow, which breaks the build. Bill. On Jun 12, 11:46 pm, orca wrote: > Ok Marik > > I checked that the default g++ under lenny is said to be 4.3.2, > despite the fact that in mine it is 4.2.4 and I'm sure I did not >

[sage-devel] Call for vote: make top-level identity_matrix and zero_matrix constructors return mutable matrices again

A few months ago, #8276 made the MatrixSpace identity_matrix and zero_matrix methods return immutable matrices, following a discussion on sage-devel. A consequence of this (unintended, I hope!) was that the top-level identity_matrix and zero_matrix methods now return immutable matrices. This

[sage-devel] Re: [R] Can one get a list of recommended packages?

On 06/12/10 05:27 PM, Douglas Bates wrote: On Sat, Jun 12, 2010 at 8:37 AM, Dr. David Kirkby wrote: R 2.10.1 is used in the Sage maths project. Several recommended packages (Matrix, class, mgcv, nnet, rpart, spatial, and survival) are failing to build on Solaris 10 (SPARC). Have you checked

[sage-devel] Re: Error building Sage 4.4.3 under vanilla Debian lenny amd64: Error while installing flint

Ok Marik I checked that the default g++ under lenny is said to be 4.3.2, despite the fact that in mine it is 4.2.4 and I'm sure I did not change this myself... At any rate, I do not think this has any relationship to the failure of installation of flint, which is my current problem now; do you??

[sage-devel] Re: Error building Sage 4.4.3 under vanilla Debian lenny amd64: Error while installing flint

On 12 čvn, 23:30, orca wrote: > Dear Sirs, > > I have a palin vanilla Debian lenny amd64 machine, which I use for > quite some time now; I am reasonably conversant (but not much) with > some installation commands for programs in general. > > I have just tried to compile Sage 4.4.3 from source un

[sage-devel] Error building Sage 4.4.3 under vanilla Debian lenny amd64: Error while installing flint

Dear Sirs, I have a palin vanilla Debian lenny amd64 machine, which I use for quite some time now; I am reasonably conversant (but not much) with some installation commands for programs in general. I have just tried to compile Sage 4.4.3 from source under that machine. I had to circumvent some "s

Re: [sage-devel] Re: ANSI C vs. C99

On 2010-Jun-10 12:25:03 +0100, "Dr. David Kirkby" wrote: >Sage builds on Solaris systems with SPARC processors. These will >never have SSE instructions, as the processor is completely different >to Intel/AMD. You can check if the system has a sparc processor by >detecting if __sparc__ is defined.

[sage-devel] python based buildsystem

Hi, for FEMhub (http://femhub.org/) got rid of the Sage buildsystem completely and wrote a simple 414 lines Python script that does the same (that we need -- for Sage more stuff would have to be ported). I talk a little bit about it here: http://ondrejcertik.blogspot.com/2010/06/week-june-5-june-

Re: [sage-devel] Re: Coordinating updating of standard packages.

On Jun 12, 2010, at 1:47 AM, David Kirkby wrote: On 12 June 2010 00:58, Robert Bradshaw wrote: On Jun 9, 2010, at 1:44 PM, Dr. David Kirkby wrote: On 06/ 9/10 08:39 PM, leif wrote: A drop-down box like "component", without the version number? I can see the point of that. Being able to

[sage-devel] Re: [R] Can one get a list of recommended packages?

On 06/12/10 03:31 PM, Tal Galili wrote: Hello David, I am not sure I understood your question. Sorry, perhaps I should have rephrased it better. Are you asking what are the packages that the R release comes with? Sort of. When R is configured, there is an option --with-recommended-packa

Re: [sage-devel] Re: How can this be avoided in future?

On Jun 12, 2010, at 4:10 AM, David Kirkby wrote: On 12 June 2010 03:46, kcrisman wrote: Notice I'm talking about actual practice as observed on actual tickets, not 'official' policy. I think Sage does an excellent job of giving incentive for writing documentation, but there is far less inc

[sage-devel] Re: [R] Can one get a list of recommended packages?

Hello David, I am not sure I understood your question. Are you asking what are the packages that the R release comes with? Or are you asking what recommended packages one should have when installing R? (There is a good list to start with here

[sage-devel] Re: matplotlib is reading old system headers, in preference to Sage ones.

On 06/12/2010 04:49 AM, David Kirkby wrote: On 12 June 2010 09:34, Georg S. Weber wrote: I mean what will happen on OS X? I have pkg-config installed automatically via MacPorts, so at least some OSX systems will have the program. In the case of matplotlib, it looks like it has a fallback (

[sage-devel] Re: matplotlib is reading old system headers, in preference to Sage ones.

On 06/12/2010 03:34 AM, Georg S. Weber wrote: >> >>> I mean what will happen on OS X? >> >> I have pkg-config installed automatically via MacPorts, so at least some >> OSX systems will have the program. In the case of matplotlib, it looks >> like it has a fallback (which is taken care of in the p

Re: [sage-devel] pushing towards 90% doctest coverage for Sage 5.0

Hi John, I don't have an answer to your questions, but... On Sat, 12 Jun 2010 14:38:52 +0100, John Cremona wrote: > I intend to deal with interfaces/mwrank.py (2/10) and > databases/cremona.py (17/40) (at least to start with!). ... have a look at #9223, I have just posted a patch that brings t

Re: [sage-devel] pushing towards 90% doctest coverage for Sage 5.0

Is there still a wiki page for people to sign up to deal with one or more of these? Or a standard for trac ticket titles to ensure that effort is not duplicated? I intend to deal with interfaces/mwrank.py (2/10) and databases/cremona.py (17/40) (at least to start with!). John On 12 June 2010 05

[sage-devel] Can one get a list of recommended packages?

R 2.10.1 is used in the Sage maths project. Several recommended packages (Matrix, class, mgcv, nnet, rpart, spatial, and survival) are failing to build on Solaris 10 (SPARC). We would like to be able to get a list of the recommended packages for R 2.10.1, but ideally via a call to R, so it is

[sage-devel] Ubuntu 10.4 LTS JMOL applet source is not properly provided

Hello everyone, this problem has been brought up several times, yet all the threads end without any solution whatsoever. Let me quickly sum this up: Ubuntu 10.4LTS x86_64 and the latest SAGE binaries provided for that specific version on the homepage. All files copied into /opt/sage/. As JAVA

[sage-devel] Re: How can this be avoided in future?

> 1) Get a list of recommended packages from that version of R - > preferably in a way that does not require them to be hard-coded in a > test script, but generated by R. Unfortunately, I couldn't find one when I was looking for it. It might be worth asking the R list whether there is something li

Re: [sage-devel] Re: How can this be avoided in future?

On 12 June 2010 13:02, kcrisman wrote: > >> I suspect there is a difference between what is needed (base) and what >> is recommended. A failure for a recommended package to build might not >> be reason to break the build of Sage. > > Correct, in fact we only very recently re-enabled building recom

Re: [sage-devel] Re: How can this be avoided in future?

On 12 June 2010 12:10, Ben Goodrich wrote: > > > On Jun 12, 6:38 am, David Kirkby wrote: >> On 12 June 2010 04:06, Ben Goodrich wrote: >> >> >> >> > If the goal were to test that the R functions in these packages are >>  > working correctly, that is documented at >> >> >http://cran.r-project.org

[sage-devel] questions about sage/databases/*

Dear sage-devels, The directory sage/databases has a dismal coverage score of 34.6%, and a lot of the code is part of revision 0 in the hg repository (aka sage-0.10.12 aka the Jurassic era). This makes it rather fun to document, and I've run into a few things on which I'd like to get some clarif

[sage-devel] README.txt says "Sage builds with GCC >= 3.x" but it does NOT

This is now http://trac.sagemath.org/sage_trac/ticket/9226 Other suggested changes are to add/change * The fact gcc, g++ and gfortran need to be the same versions. * Spelling change of Sparc -> SPARC. * Better information about what does and does not work on Solaris. Dave -- To po

[sage-devel] Re: How can this be avoided in future?

> I suspect there is a difference between what is needed (base) and what > is recommended. A failure for a recommended package to build might not > be reason to break the build of Sage. Correct, in fact we only very recently re-enabled building recommended packages. But in practice they are heav

[sage-devel] Re: How can this be avoided in future?

On Jun 12, 6:38 am, David Kirkby wrote: > On 12 June 2010 04:06, Ben Goodrich wrote: > > > > > If the goal were to test that the R functions in these packages are > > working correctly, that is documented at > > >http://cran.r-project.org/doc/manuals/R-admin.html#Testing-a-Unix-Ins... > > > In

Re: [sage-devel] Re: How can this be avoided in future?

On 12 June 2010 03:46, kcrisman wrote: > >> >> 1) If you want to make the functions available for your own use, you >> >> don't need to test them or document them. >> >> >> 2) If you want them incorporated into Sage, you must document them >> >> well and test them extensively. If you don't know h

Re: [sage-devel] Re: How can this be avoided in future?

On 12 June 2010 04:06, Ben Goodrich wrote: > > If the goal were to test that the R functions in these packages are > working correctly, that is documented at > > http://cran.r-project.org/doc/manuals/R-admin.html#Testing-a-Unix-Installation > > In particular, one might want to call > > library(too

Re: [sage-devel] Re: matplotlib is reading old system headers, in preference to Sage ones.

On 12 June 2010 09:34, Georg S. Weber wrote: >> >> > I mean what will happen on OS X? >> >> I have pkg-config installed automatically via MacPorts, so at least some >> OSX systems will have the program.  In the case of matplotlib, it looks >> like it has a fallback (which is taken care of in the p

[sage-devel] Can some look at this python package for review please

There's a patch I'd like to get reviewed at http://trac.sagemath.org/sage_trac/ticket/9041 which, excluding * Comments * A few lines in spkg-install to apply the patch consists of just 3 changed lines in one large Python source file. So it is small, but because I've had to copy one of the la

Re: [sage-devel] Re: Coordinating updating of standard packages.

On 12 June 2010 00:58, Robert Bradshaw wrote: > On Jun 9, 2010, at 1:44 PM, Dr. David Kirkby wrote: > >> On 06/ 9/10 08:39 PM, leif wrote: >>> A drop-down box like "component", without the version number? >> >> I can see the point of that. Being able to search by component would be >> useful. >>

[sage-devel] Re: matplotlib is reading old system headers, in preference to Sage ones.

> > > I mean what will happen on OS X? > > I have pkg-config installed automatically via MacPorts, so at least some > OSX systems will have the program.  In the case of matplotlib, it looks > like it has a fallback (which is taken care of in the patches in the > update spkg) > > Thanks, > > Jason