I'm going to update the 'prereq' script to add a test for a Fortran compiler. I
would like to know what we need.
This is what is a quick summary of what is currently tested in 'prereq'. Is
there anything else which should be added to this list.
1) Non GNU compilers permitted, but you need to
On Thu, Jan 21, 2010 at 10:41 PM, Dr. David Kirkby
wrote:
> Gonzalo Tornaria wrote:
>>
>> On Fri, Jan 22, 2010 at 3:24 AM, Dr. David Kirkby
>> wrote:
>>>
>>> But sorting out whether the version of libraries on a system are
>>> suitable,
>>> can be tricky. Even having the right versions does not g
Gonzalo Tornaria wrote:
On Fri, Jan 22, 2010 at 3:24 AM, Dr. David Kirkby
wrote:
But sorting out whether the version of libraries on a system are suitable,
can be tricky. Even having the right versions does not guarantee they will
be found in preference to some other version.
Sure. We already
On Fri, 22 Jan 2010 19:27:56 Gonzalo Tornaria wrote:
> > If you are only going to shave off 20 MB or so from the source code, it
> > might be more hassle than it is worth. If you could cut the download time
> > by 30%, then I could see it would probably be worth the effort in doing
> > this. But I'
On Fri, Jan 22, 2010 at 3:24 AM, Dr. David Kirkby
wrote:
> But sorting out whether the version of libraries on a system are suitable,
> can be tricky. Even having the right versions does not guarantee they will
> be found in preference to some other version.
Sure. We already have related issues.
On Thu, Jan 21, 2010 at 8:09 PM, Gonzalo Tornaria
wrote:
>>> I think Sage is mature enough now to slowly migrate toward this.
>>> Besides, there can still be spkgs for those packages, and there could
>>> be a sage-with-batteries-included tarball with dependencies included.
>>
>> What would be the
Gonzalo Tornaria wrote:
Plus, there can *still* be spkgs for all the dependencies. And there
could be a "sage-with-batteries-included" tarball which works just as
it does now. And another
"sage-reduced-for-expert-developers-and-distros" tarball which doesn't
include the spkgs which can be replac
On Thu, Jan 21, 2010 at 7:11 PM, William Stein wrote:
> +1 to Robert's comments. I can't tell you how many people just in the
> last few days have told me that they use (and work on!) Sage *only*
> because when they try to build it on their computer it "just worked".
Do people tell you when they
On Thu, Jan 21, 2010 at 6:05 PM, Robert Bradshaw
wrote:
> On Jan 21, 2010, at 6:31 AM, Gonzalo Tornaria wrote:
>
>> On Wed, Jan 20, 2010 at 5:47 PM, Peter Jeremy wrote:
>>>
>>> My personal feeling is that it would be nice if some of the more generic
>>> packages (eg bzip, zlib, readline, mercuria
On Fri, Jan 22, 2010 at 12:46 AM, Minh Nguyen wrote:
> With or without the above Unicode preamble, a non-ASCII character in a
> docstring can cause the PDF version of a document to fail to build.
> See ticket #8036 [1] for an example of a case where a source file
> contains the above preamble, but
On Thu, Jan 21, 2010 at 4:22 PM, Pat LeSmithe wrote:
> Should we put
>
> # -*- coding: utf-8 -*-
>
> at the top of all .py and .pyx(?) files in the Sage library?
>
> I think this will allow us to use Unicode literal strings in Sage code,
> doctests, documentation --- without raising coding errors.
Robert Bradshaw wrote:
On Jan 21, 2010, at 8:37 AM, Dr. David Kirkby wrote:
Having worked quite hard on the SPARC build, I was less than keen to
see it broken.
Yes, that is disappointing. I spent a fair amount of time trying to
resolve the first Solaris stopper that came up, but who knows h
Great, thanks!
I just realized I didn't do my referee patch correctly, but I just
added a new one that I think is correct.
-Marshall
On Jan 21, 4:58 pm, Andrey Novoseltsev wrote:
> I'll look over the referee patch.
>
> Andrey
>
> On Jan 21, 10:50 am, mhampton wrote:
>
> > OK, I added a referee
On Thu, Jan 21, 2010 at 01:31:26PM -0800, William Stein wrote:
> We've hand-inspected the R failures and they are all because of
> missing optional R packages that we don't include with Sage.
I also found out later that there's a new R spkg by kcrisman at #6532 (needs
review) that should pass all
>
> Post it where? Here to the list? Should I assume that what holds true for
> Ubuntu is more general, or just make notes in the text that let people know
> that on Ubuntu that's the way it is? (Because that's all I have available to
> me.)
>
>
I looked into it, and looks like it's very standard t
On Thu, Jan 21, 2010 at 1:41 PM, Minh Nguyen wrote:
> Hi Erik,
>
> On Fri, Jan 22, 2010 at 8:15 AM, Erik Lane wrote:
> > Issues with the install:
> >
> > README.txt needs updating. At least for Ubuntu ranlib doesn't show up as
> an
> > option for apt-get, but it is part of the binutils package.
On Thu, Jan 21, 2010 at 1:31 PM, William Stein wrote:
> On Thu, Jan 21, 2010 at 1:15 PM, Erik Lane wrote:
> > Issues with the install:
> >
> > README.txt needs updating. At least for Ubuntu ranlib doesn't show up as
> an
> > option for apt-get, but it is part of the binutils package. Also needs
I'll look over the referee patch.
Andrey
On Jan 21, 10:50 am, mhampton wrote:
> OK, I added a referee patch.
>
> -Marshall
>
> On Jan 21, 9:38 am, William Stein wrote:
>
> > On Thu, Jan 21, 2010 at 7:32 AM, mhampton wrote:
> > > I would like to encourage people to review ticket 7109:
>
> > >ht
On Thu, Jan 21, 2010 at 2:14 PM, Pat LeSmithe wrote:
> On 01/21/2010 12:22 PM, William Stein wrote:
>>
>> local/lib/python/site-packages/sagenb-0.6-py2.6.egg/sagenb/data/graph_editor/
>>
>> It would be *GREAT* if there were a README.txt file in that directory
>> that explained what all the js
On Thu, Jan 21, 2010 at 2:45 PM, Maurizio wrote:
>
> On 21 Gen, 00:22, William Stein wrote:
>> On Wed, Jan 20, 2010 at 1:33 PM, Maurizio wrote:
>> > Hi all,
>> > even if in the recent times I've been much less involved with SAGE, I
>> > just wanted to point out two pieces of software that I hope
On 21 Gen, 00:22, William Stein wrote:
> On Wed, Jan 20, 2010 at 1:33 PM, Maurizio wrote:
> > Hi all,
> > even if in the recent times I've been much less involved with SAGE, I
> > just wanted to point out two pieces of software that I hope could
> > become useful in the next future for SAGE.
> >
On 01/21/2010 12:22 PM, William Stein wrote:
>
> local/lib/python/site-packages/sagenb-0.6-py2.6.egg/sagenb/data/graph_editor/
>
> It would be *GREAT* if there were a README.txt file in that directory
> that explained what all the js files actually are, something about how
> the graph editor w
It seemed to be only associated to that cell: if I took the generated code,
copied it into another cell and then made changes in the other cell, the
changes saved correctly.
I tried publishing the worksheet, but that seemed to change the state of the
cell sufficiently so that I can no longer dupli
Hi David,
I couldn't reproduce that bug. One thing comes to mind is to note what
is written in the box "variable name". The js editor and Sage
communicate only when you hit save and all that happens in that the
graph in the editor is saved under the name in "variable name" box.
When you say Save
On Wed, Jan 20, 2010 at 10:06 PM, Minh Nguyen wrote:
> Hi Robert,
>
> On Thu, Jan 21, 2010 at 6:38 AM, Robert Bradshaw
> wrote:
>
>
>
>> The single bad account can be deleted.
>
> Now there is another spammer account with the username Robert. The
> spammer has put spam content on the FAQ [1] and
Hi Erik,
On Fri, Jan 22, 2010 at 8:15 AM, Erik Lane wrote:
> Issues with the install:
>
> README.txt needs updating. At least for Ubuntu ranlib doesn't show up as an
> option for apt-get, but it is part of the binutils package. Also needs to be
> updated re: the new requirements for gfortran. It
On Thu, Jan 21, 2010 at 1:15 PM, Erik Lane wrote:
> Issues with the install:
>
> README.txt needs updating. At least for Ubuntu ranlib doesn't show up as an
> option for apt-get, but it is part of the binutils package. Also needs to be
> updated re: the new requirements for gfortran. It still list
Issues with the install:
README.txt needs updating. At least for Ubuntu ranlib doesn't show up as an
option for apt-get, but it is part of the binutils package. Also needs to be
updated re: the new requirements for gfortran. It still lists the old info.
GCC needs to be all lowercase for apt-get to
On Thu, Jan 21, 2010 at 12:05 PM, Robert Bradshaw
wrote:
>
> On Jan 21, 2010, at 6:31 AM, Gonzalo Tornaria wrote:
>
>> On Wed, Jan 20, 2010 at 5:47 PM, Peter Jeremy wrote:
>>>
>>> My personal feeling is that it would be nice if some of the more generic
>>> packages (eg bzip, zlib, readline, mercu
Glad you liked it. I will write up the README in the next few days.
The spring layout definitely can be improved as I put in the first
thing that came to mind, but I know those things have been studied and
there are advanced algorithms. Eventually the sliders can be removed
if the algorithm is sma
On Jan 21, 3:22 pm, William Stein wrote:
> Hi,
>
> The new graph editor in sage by Rado is AWESOME. One can try it
+1 ! We had a lot of fun showing it off to people at the Joint
Meetings.
- kcrisman
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from t
I agree that it's awesome. I'm not sure if I'm using it right though. If I
remove a vertex from Williams example below, and then click Save, it changes
the cell, but the graph that it then creates is the same as before I removed
the vertex. The same problem seems to occur for most changes I make
Hi,
The new graph editor in sage by Rado is AWESOME. One can try it
easily at http://sagenb.org by typing:
g = graphs.CompleteGraph(10)
graph_editor(g)
The actual source code is at
local/lib/python/site-packages/sagenb-0.6-py2.6.egg/sagenb/data/graph_editor/
It would be *GREAT* if ther
On Jan 21, 2010, at 6:31 AM, Gonzalo Tornaria wrote:
On Wed, Jan 20, 2010 at 5:47 PM, Peter Jeremy
wrote:
My personal feeling is that it would be nice if some of the more
generic
packages (eg bzip, zlib, readline, mercurial) were moved out of sage
and made explicit requirements.
+1
I th
On Thu, Jan 21, 2010 at 11:29 AM, mhampton wrote:
> Well then perhaps we should have a -very_long flag! I would think
> that some very long doctests stress-test things in a way that may be
> impossible with shorter tests - large memory usage for example.
>
> -Marshall
+1!
--
Robert L. Miller
On Jan 21, 2010, at 8:37 AM, Dr. David Kirkby wrote:
It looks like the exact same version of FLINT, which did work in Sage
4.3, no longer works in 4.3.1. I can't imagine what the problem is.
(Guess: too much fiddling with the Sage build system.)
There's also no patch to fix the issue attach
Well then perhaps we should have a -very_long flag! I would think
that some very long doctests stress-test things in a way that may be
impossible with shorter tests - large memory usage for example.
-Marshall
On Jan 21, 1:03 pm, Robert Miller wrote:
> On Thu, Jan 21, 2010 at 10:59 AM, mhampton
On Thu, Jan 21, 2010 at 9:20 AM, William Stein wrote:
> If the problem really is the filesystem, then maybe /scratch is way
> too slow. Can you try setting DOT_SAGE to something in /tmp or
> /space, since /tmp could be far better than /scratch for large numbers
> of accesses.
I just tried settin
On Thu, Jan 21, 2010 at 5:21 PM, William Stein wrote:
> Hi,
>
> WARNING: On Linux, if you do "sage -upgrade" right now, you may need to do
>
> ./sage -f numpy-1.3.0.p2.spkg scipy_sandbox-20071020.p4.spkg
> scipy-0.7.p3.spkg
>
> (or something very similar) to force rebuild of some code that depen
OK, I added a referee patch.
-Marshall
On Jan 21, 9:38 am, William Stein wrote:
> On Thu, Jan 21, 2010 at 7:32 AM, mhampton wrote:
> > I would like to encourage people to review ticket 7109:
>
> >http://trac.sagemath.org/sage_trac/ticket/7109
>
> > This was originally submitted by Volker Braun,
William Stein wrote:
On Thu, Jan 21, 2010 at 8:22 AM, brandon.bar...@gmail.com
wrote:
The OpenSolaris development repository seems to have a release cycle
of two weeks, but they have a source release or build which is made
available for internal testing (and whoever wants to test it badly
enoug
On Thu, Jan 21, 2010 at 9:10 AM, Robert Miller wrote:
> William wrote:
>> It's possible he didn't set the DOT_SAGE environment variable to
>> something in /scratch, which will impact timings hugely (at least
>> until somebody rewrites Sage temp file code in misc/misc.py to use the
>> standard temp
2010/1/21 William Stein :
> On Thu, Jan 21, 2010 at 9:02 AM, John Cremona wrote:
>> Is there any reason why my password for logging into the wiki has
>> stopped working?
>
> I can't think of any. Mine still works. Maybe you forgot it?
>
I certainly had! but firefox had not. Clearly firefox is
William wrote:
> It's possible he didn't set the DOT_SAGE environment variable to
> something in /scratch, which will impact timings hugely (at least
> until somebody rewrites Sage temp file code in misc/misc.py to use the
> standard tempfile module).
DOT_SAGE was set to /scratch/rlm/.sage when I
On Thu, Jan 21, 2010 at 9:02 AM, John Cremona wrote:
> Is there any reason why my password for logging into the wiki has
> stopped working?
I can't think of any. Mine still works. Maybe you forgot it?
>
> John
>
> 2010/1/21 bump :
>> I think #7729 implementing Iwahori Hecke algebras deserves c
Is there any reason why my password for logging into the wiki has
stopped working?
John
2010/1/21 bump :
> I think #7729 implementing Iwahori Hecke algebras deserves comment.
>
> Dan
>
> On Jan 21, 7:02 am, Minh Nguyen wrote:
>> Hi folks,
>>
>> The release tour for Sage 4.3.1 [1] is nearly compl
On Tue, Jan 19, 2010 at 01:54:57PM -0800, Robert Miller wrote:
> It's time to point our fingers at long doctests again. (I won't name
> names, but there are a few people who are mostly responsible for
> several of these files) Here are the eight files whose doctests
> (without -long) take the longe
On Wed, Jan 20, 2010 at 8:26 PM, bump wrote:
> I had errors building sage-4.3.1.
>
> The trouble came after this warning:
>
> sage-spkg fortran-20100118 2>&1
> Warning: Attempted to overwrite SAGE_ROOT environment variable
> fortran-20100118
>
> Eventually I got:
>
> Error installing Fortran: You
On Thu, Jan 21, 2010 at 8:22 AM, brandon.bar...@gmail.com
wrote:
> The OpenSolaris development repository seems to have a release cycle
> of two weeks, but they have a source release or build which is made
> available for internal testing (and whoever wants to test it badly
> enough to build and i
Bill Hart wrote:
On Jan 21, 11:53 am, "Dr. David Kirkby"
wrote:
I was a little disappointed that 4.3.1 was released, when I'd made it quite
clear there was a *new* problem, introduced since 4.3, which was causing the
build on Solaris SPARC to fail, despite earlier versions working on SPARC.
h
The OpenSolaris development repository seems to have a release cycle
of two weeks, but they have a source release or build which is made
available for internal testing (and whoever wants to test it badly
enough to build and install it themselves) roughly two weeks before
each release. From a user
Hi,
WARNING: On Linux, if you do "sage -upgrade" right now, you may need to do
./sage -f numpy-1.3.0.p2.spkg scipy_sandbox-20071020.p4.spkg scipy-0.7.p3.spkg
(or something very similar) to force rebuild of some code that depends
on fortran libraries.
See http://trac.sagemath.org/sage_trac/tick
I am less unhappy now, having managed to install gfortran. (There was
something broken in our ubuntu package management system, but I
managed to fix it luckily).
John
2010/1/21 Dr. David Kirkby :
> John Cremona wrote:
>
>>> I think this is one further example of the point I made less than an hou
On Wed, Jan 20, 2010 at 02:02:05PM -0800, Jason Grout wrote:
> William Stein wrote:
> >I argue for keeping the current design when I'm *doing* math.
> >I argue for changing echelon_form to return something over the
> >fraction field when I'm teaching undergraduates.
+1
Luckily enough, in France,
Hi folks,
I have setup a wiki page [1] to record the building and doctesting
results of Sage 4.3.1 on various platform/hardware combinations. Feel
free to add more results to that page.
[1] http://wiki.sagemath.org/devel/BuildFarm/sage-4.3.1
--
Regards
Minh Van Nguyen
--
To post to this group,
Ah, I see. I missed the scroll bar at the bottom. Even so it's a real
fiddle to see which line is the problem.
It appears to be complaining about a system include file which is
supposed to test for features available on the system.
Never seen that before, and I don't think it is FLINT after all.
On Thu, Jan 21, 2010 at 7:32 AM, mhampton wrote:
> I would like to encourage people to review ticket 7109:
>
> http://trac.sagemath.org/sage_trac/ticket/7109
>
> This was originally submitted by Volker Braun, and I think it is his
> first contribution to Sage. It is an important refactoring of th
I would like to encourage people to review ticket 7109:
http://trac.sagemath.org/sage_trac/ticket/7109
This was originally submitted by Volker Braun, and I think it is his
first contribution to Sage. It is an important refactoring of the
polyhedra code in geometry/polyhedra.py. This rewrite is
I think #7729 implementing Iwahori Hecke algebras deserves comment.
Dan
On Jan 21, 7:02 am, Minh Nguyen wrote:
> Hi folks,
>
> The release tour for Sage 4.3.1 [1] is nearly complete. If you can
> help out with showcasing new features in Sage 4.3.1 in the release
> tour, please do so. In case I m
On Thu, Jan 21, 2010 at 7:09 AM, Bill Hart wrote:
>
>
> On Jan 21, 11:53 am, "Dr. David Kirkby"
> wrote:
>> I was a little disappointed that 4.3.1 was released, when I'd made it quite
>> clear there was a *new* problem, introduced since 4.3, which was causing the
>> build on Solaris SPARC to fail
On Thu, Jan 21, 2010 at 4:20 AM, Martin Albrecht
wrote:
> On Thursday 21 January 2010, David Joyner wrote:
>> I have run some of these tests on an imac running 10.6.2
>> in sage 4.3.1 (sage-4.3.1.a5, to be precise) and
>> got what seems to be much shorter times
>> (see below). I'm not sure but it
On Jan 21, 11:53 am, "Dr. David Kirkby"
wrote:
> I was a little disappointed that 4.3.1 was released, when I'd made it quite
> clear there was a *new* problem, introduced since 4.3, which was causing the
> build on Solaris SPARC to fail, despite earlier versions working on SPARC.
>
> http://trac
Hi folks,
The release tour for Sage 4.3.1 [1] is nearly complete. If you can
help out with showcasing new features in Sage 4.3.1 in the release
tour, please do so. In case I missed some new features, I appreciate
your help in showcasing those new features. It would be good to have a
second pair of
On Thu, Jan 21, 2010 at 6:09 AM, Gonzalo Tornaria
wrote:
> On Thu, Jan 21, 2010 at 3:22 AM, Pat LeSmithe wrote:
>> Should we put
>>
>> # -*- coding: utf-8 -*-
>>
>> at the top of all .py and .pyx(?) files in the Sage library?
>>
>> I think this will allow us to use Unicode literal strings in Sage
On Thu, Jan 21, 2010 at 12:16 PM, kcrisman wrote:
> Not everyone can easily use a text editor which recognizes all non-
> ASCII character properly, so I think we should be careful about
> this.
I don't think that's true anymore. It may have been true ten years
ago, but nowadays unicode and utf-8
On Wed, Jan 20, 2010 at 5:47 PM, Peter Jeremy wrote:
> My personal feeling is that it would be nice if some of the more generic
> packages (eg bzip, zlib, readline, mercurial) were moved out of sage
> and made explicit requirements.
+1
I think Sage is mature enough now to slowly migrate toward t
On Thu, Jan 21, 2010 at 7:20 AM, Martin Albrecht
wrote:
> On Thursday 21 January 2010, David Joyner wrote:
>> I have run some of these tests on an imac running 10.6.2
>> in sage 4.3.1 (sage-4.3.1.a5, to be precise) and
>> got what seems to be much shorter times
>> (see below). I'm not sure but it
Not everyone can easily use a text editor which recognizes all non-
ASCII character properly, so I think we should be careful about
this.
- kcrisman
On Jan 21, 9:09 am, Gonzalo Tornaria wrote:
> On Thu, Jan 21, 2010 at 3:22 AM, Pat LeSmithe wrote:
> > Should we put
>
> > # -*- coding: utf-8 -*-
John Cremona wrote:
I think this is one further example of the point I made less than an hour
ago. The removal of the Fortran package was made in sage-4.3.1.rc2, which
very quickly becomes 4.3.1, with insufficient time given for testing before
making the 4.3.1 release.
I agree -- this is very
On Thu, Jan 21, 2010 at 3:22 AM, Pat LeSmithe wrote:
> Should we put
>
> # -*- coding: utf-8 -*-
>
> at the top of all .py and .pyx(?) files in the Sage library?
>
> I think this will allow us to use Unicode literal strings in Sage code,
> doctests, documentation --- without raising coding errors.
> However, the error message was fairly clear as to what needs to be done:
> Error installing Fortran: You must install gfortran or set
> SAGE_FORTRAN (and possibly SAGE_FORTRAN_LIB).
Yes, after installing gfortran I was able to build Sage.
Dan
--
To post to this group, send an email to sage-dev
2010/1/21 Dr. David Kirkby :
> Alex Ghitza wrote:
>>
>> On Thu, 21 Jan 2010 12:08:09 +, "Dr. David Kirkby"
>> wrote:
>>>
>>> Though it would appear the log posted by Dan
>>>
>>> http://sporadic.stanford.edu/bump/sage-4.3.1-errors
>>>
>>> shows the compiler was configured with Fortran support:
Alex Ghitza wrote:
On Thu, 21 Jan 2010 12:08:09 +, "Dr. David Kirkby"
wrote:
Though it would appear the log posted by Dan
http://sporadic.stanford.edu/bump/sage-4.3.1-errors
shows the compiler was configured with Fortran support:
Configured with: ../src/configure -v
--enable-languages=
On Thu, 21 Jan 2010 12:08:09 +, "Dr. David Kirkby"
wrote:
> Though it would appear the log posted by Dan
>
> http://sporadic.stanford.edu/bump/sage-4.3.1-errors
>
> shows the compiler was configured with Fortran support:
>
> Configured with: ../src/configure -v
> --enable-languages=c,c++,
On Thursday 21 January 2010, David Joyner wrote:
> I have run some of these tests on an imac running 10.6.2
> in sage 4.3.1 (sage-4.3.1.a5, to be precise) and
> got what seems to be much shorter times
> (see below). I'm not sure but it seems that at least for the
> coding theory modules, there does
Minh Nguyen wrote:
Hi Dan,
On Thu, Jan 21, 2010 at 3:26 PM, bump wrote:
I had errors building sage-4.3.1.
Note this output from a configuration script (it's from the install
log you posted):
checking for g77... no
checking for xlf... no
checking for f77... no
checking for frt... no
checking
I have run some of these tests on an imac running 10.6.2
in sage 4.3.1 (sage-4.3.1.a5, to be precise) and
got what seems to be much shorter times
(see below). I'm not sure but it seems that at least for the
coding theory modules, there does not seem to be a
timing problem.
For me at least, matrix
I was a little disappointed that 4.3.1 was released, when I'd made it quite
clear there was a *new* problem, introduced since 4.3, which was causing the
build on Solaris SPARC to fail, despite earlier versions working on SPARC.
http://trac.sagemath.org/sage_trac/ticket/7990
(I marked it as a bl
Hi!
In the last couple of days I am on a bug hunt, so far without the
faintest success. Perhaps you can help me with a Jedi mind intuition?
It is about the next (not yet released) version of my cohomology spkg.
If I compute the mod-2 cohomology ring of a certain non prime power
group, it works fi
Hi folks,
Below is a release note for Sage 4.3.1, compiled with the help of Mike
Hansen's script [1]. In this release, the lowest ticket number winner
is #383, which is closed thanks to Robert Bradshaw and William Stein.
Sage 4.3.1 was released on January 20th, 2010. It is available at
80 matches
Mail list logo
