Re: [sage-devel] Re: Memory leak
On Fri, Mar 5, 2010 at 10:28 PM, Mike Hansen wrote: > On Fri, Mar 5, 2010 at 6:33 PM, Minh Nguyen wrote: >> Hi Dima, >> >> On Sat, Mar 6, 2010 at 1:27 PM, Dima Pasechnik wrote: >>> if it's PARI-dependent, it makes sense to upgrade PARI to the latest >>> version. >> >> Perhaps upgrading Pari could be a goal for Sage 5.0? > > I think upgrading to the latest stable release is easier than > upgrading to unstable (which Nick tried). There is a new PARI 2.3.5 > spkg at #8453. +1. Excellent. Based on conversations with Karim Belebas, I learned that Pari stable is *designed* to maintain library level compatibility. The unstable version is allowed to possibly massively break library level compatibility. Releases of both versions are supposed to be suitable for general use.Mike's comments above are hopefully right on target. Upgrading Pari is already one of the listed goals for sage-5.0 (it's in the list of tickets at trac that I linked to). > > --Mike > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Memory leak
On Fri, Mar 5, 2010 at 6:33 PM, Minh Nguyen wrote: > Hi Dima, > > On Sat, Mar 6, 2010 at 1:27 PM, Dima Pasechnik wrote: >> if it's PARI-dependent, it makes sense to upgrade PARI to the latest >> version. > > Perhaps upgrading Pari could be a goal for Sage 5.0? I think upgrading to the latest stable release is easier than upgrading to unstable (which Nick tried). There is a new PARI 2.3.5 spkg at #8453. --Mike -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Doc tests with no justification for the result.
As Jason said, the docstrings do indicate what model (simple, for now) we're using to transform colors. We mention in several places in colors.py docstrings that we reduce R, G, and B components modulo one. But we could be more explicit. Anyway, we could make it possible to choose between this and "capped" behavior with a sage.plot.colors.MODULE_SCOPE_VARIABLE or another way. By the way, is it possible to do the equivalent of plot(sin(x), (x, -10, 10), color=Color(x, 1-x, x)) (succinctly)? Wrap-around might be useful here. On 03/05/2010 05:04 PM, Dr. David Kirkby wrote: > Expected: > RGB color (0.51829585732141792, 0.49333037605210095, 0.0) > Got: > RGB color (0.51829585732141814, 0.49333037605210117, 0.0) Does this stem from the slightly different value of e on Solaris? http://trac.sagemath.org/sage_trac/ticket/8374 http://trac.sagemath.org/sage_trac/ticket/8375 On 03/05/2010 07:27 PM, Dr. David Kirkby wrote: > IMHO, it would be good if the trac number appropriate to the test was Try 'hg log colors.py'. Sphinx 1.0 will have an extension http://sphinx.pocoo.org/latest/ext/extlinks.html that makes it a bit more convenient to insert Sage trac URLs. > My main points are Thanks! -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Debian package...
On Mar 5, 11:27 pm, "Dr. David Kirkby" wrote: > I suspect the Debian people are reasonable and could be persuaded to accept > things if there were aware of just how many patches have needed to be made to > 'standard' packages. They are reasonable. My guess is they would usually email upstream to ask about a patch and if upstream agrees but isn't planning to release for a while, then the maintainers might well apply it, particularly in experimental. But all that would take time and may have to be coordinated across several package maintainers. That is why I agree with you about having an option to build sage with reasonably up-to- date versions of system libraries and dependencies. I think that would probably be the biggest thing that could be done to make life easier on Tim and the other package maintainers. Also, with Debian in particular, when they freeze the testing branch to start preparing it for the stable release, there is going to be extra reluctance to take new patches, often even for the unstable branch. The maintainers just devote all their energy toward stabilizing and other things get backlogged. Being Debian, freezes have been known to last a long time. Ben -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Vote on bugs to be fixed for sage-4.4 "stabilization release".
Nick Alexander wrote: David is trying to argue that the goals for Sage-5.0 should be * Official Solaris 10 support (all tests pass) TARGET DATE: Sometime in March? *instead* of the following: * 90% doctest coverage score (=write about 1500 doctests) * Official Solaris 10 support (all tests pass) * Official Cygwin support (all tests pass) * Close _all_ tickets listed at http://trac.sagemath.org/sage_trac/wiki/stab1 TARGET DATE: Sometime in May. I vote -1 to this. As a user, I expect a major release (defined as a version number bump) to include exciting new toys. Solaris support does not *in my opinion* qualify as an exciting new toy. I anticipate a Slashdot story announcing the new release, followed by a surge of interest and downloads. It is *my opinion* that Solaris support is not an exciting new feature that the resulting publicity should be promoting. If anything, it is *my opinion* that Cygwin support is much more likely to appeal to these potential new users, and would warrant the publicity. Nick PS. Emphasis added because I do not want to fan any flames -- please respond accordingly. Part of my logic for this is that given Sun have * Donated hardware (t2) worth around $30,000 - $40,000 for this, * Have supplied other hardware heavily discounted. (sage.math and most of the disks are I believe Suns) * Are asking William for a release where they can point customers at, then those that supplied a lot of money probably do consider it quite important. You personally might not, but a major investor does. If Sun (now Oracle) did not consider it important, I doubt they would have supplied the hardware, and I doubt they would be asking William questions about the Solaris port. The only person paid full time to work on Sage was paid to do the Solaris port. A lot of time, effort and money has gone into it. I agree with you about Cygwin too. I also think reaching a specific level of doc tests is a bit irrelevant in determining when to increment the major release number. Perhaps if the doc tests reached 100%, then I might agree. I think with the very fast release cycle of Sage, no one release is likely to have many exciting new toys. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Doc tests with no justification for the result.
Jason Grout wrote:
On 03/05/2010 07:04 PM, Dr. David Kirkby wrote:
I just got a doc test failure on Solaris.
File
"/export/home/drkirkby/32/sage-4.3.4.alpha0/devel/sage/sage/plot/colors.py",
line 660:
sage: gold / pi + yellow * e
Expected:
RGB color (0.51829585732141792, 0.49333037605210095, 0.0)
Got:
RGB color (0.51829585732141814, 0.49333037605210117, 0.0)
Looking at the doc test I see this:
--
EXAMPLES::
sage: from __future__ import division
sage: from sage.plot.colors import yellow, gold
sage: yellow / 4
RGB color (0.25, 0.25, 0.0)
sage: yellow.__truediv__(4)
RGB color (0.25, 0.25, 0.0)
sage: gold / pi + yellow * e
RGB color (0.51829585732141792, 0.49333037605210095, 0.0)
--
The is absolutely no justification given in the doc test for this
result, so how do we know it's right?
Printing the values of 'yellow' and 'gold' I get:
sage: print yellow
RGB color (1.0, 1.0, 0.0)
sage: print gold
RGB color (1.0, 0.84313725490196079, 0.0)
sage:
I personally don't understand how one can divide one colour by another,
but I'm not disputing that there can be some logic in this. I tried in
Mathematica to just divide the these as lists
In[44]:= yellow={1,1,0}
Out[44]= {1, 1, 0}
In[45]:= gold={1.0,0.84313725490196079, 0.0}
In[46]:= gold/Pi + yellow E
Out[46]= {3.03659, 2.98666, 0.}
With no idea what this division is supposed to do, I tried.
In[47]:= Normalize[%]
Out[47]= {0.712944, 0.701221, 0.}
but that gives totally different numbers.
So I'm none the wiser. Of course, I could create a ticket to check the
expected value to be
0.51829585732141..., 0.49333037605210...,0.0
but I'd have no justification for this.
Perhaps someone can enlighten me how one divides /multiples colours, and
can show me a high precision value for the result.
This is just one of several examples I've seen in Sage where the numeric
result from a doc test is not obvious. The "Expected" value is probably
what someone got on their computer. I "Got" a different value on my
computer. But who knows what the result should be? Without some
justification, I find it hard to believe this doc test achieves very
much. I've just waisted an hour trying to work out how I might reproduce
this, but can't
I assume we are talking about the patches up at #5601?
Probably. I can't say for sure. There is so many large patches on there, that I
have not studied them in detail.
IMHO, it would be good if the trac number appropriate to the test was documented
in the test. Then one might at least have some idea where to look.
First, note that colors are multiplied by scalars, not by other colors.
Yes, my mistake.
The documentation for the multiplication and division methods talk
about what a multiplication or division means---scale the RGB values by
the scalar.
sage: colors.yellow
RGB color (1.0, 1.0, 0.0)
sage: colors.yellow/2
RGB color (0.5, 0.5, 0.0)
sage: colors.yellow*0.3
RGB color (0.2, 0.2, 0.0)
This makes some sort of sense, at least numerically. However, what does
not make sense is when a resulting component is more than one, the
fractional part is taken as the value. Therefore,
sage: colors.red*2
RGB color (0.0, 0.0, 0.0)
I think this is a problem (and missed this when I reviewed the colors
patch, so this getting in is partially my fault!) At least explains
what colors*scalar is. I think this ought to be changed to make more
sense when a resulting component is outside of [0,1] (maybe cap the
values, instead of just take the fractional part). The problem here is
in the rgbcolor() function when it creates a color from a tuple.
There's information here about how Mathematica handles such cases
http://reference.wolfram.com/mathematica/ref/RGBColor.html
If the method in Sage is not right, then I'd give some consideration at least to
following how some other software does it. I'm not suggesting copying everything
Mathematica does, or considering it a God, but at least give it's methods some
thought.
The addition of two colors is documented in the function for addition,
and says there that it uses the blend function. The documentation for
blend says
Return a color blended with the given ``color`` by a given
``fraction``. The algorithm interpolates linearly between the
colors' corresponding R, G, and B coordinates.
This is so that colors.red+colors.blue is approximately purple (though
not exactly colors.purple, since colors.purple is a specifically defined
value according to HTML standards). colors.yellow+colors.red is
approximately colors.orange, etc.
Thanks,
Jason
My main points are
* There is not much information about that test.
* An explanation of why the "Expected" value is expected would be useful.
* It should be possible to compute manually a high precision result and
document that number in many cases - this being one of them.
To m
Re: [sage-devel] Re: Debian package...
On Sat, Mar 6, 2010 at 5:46 AM, Minh Nguyen wrote: > I'm very much inexperienced with respect to Debian porting. > All I'm saying is that the task ahead seems to me too surmountable, That should be "too insurmountable". Sorry for the typo. -- Regards Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Memory leak
Hi Dima, On Sat, Mar 6, 2010 at 1:27 PM, Dima Pasechnik wrote: > if it's PARI-dependent, it makes sense to upgrade PARI to the latest > version. Perhaps upgrading Pari could be a goal for Sage 5.0? -- Regards Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Doc tests with no justification for the result.
On 03/05/2010 07:04 PM, Dr. David Kirkby wrote:
I just got a doc test failure on Solaris.
File
"/export/home/drkirkby/32/sage-4.3.4.alpha0/devel/sage/sage/plot/colors.py",
line 660:
sage: gold / pi + yellow * e
Expected:
RGB color (0.51829585732141792, 0.49333037605210095, 0.0)
Got:
RGB color (0.51829585732141814, 0.49333037605210117, 0.0)
Looking at the doc test I see this:
--
EXAMPLES::
sage: from __future__ import division
sage: from sage.plot.colors import yellow, gold
sage: yellow / 4
RGB color (0.25, 0.25, 0.0)
sage: yellow.__truediv__(4)
RGB color (0.25, 0.25, 0.0)
sage: gold / pi + yellow * e
RGB color (0.51829585732141792, 0.49333037605210095, 0.0)
--
The is absolutely no justification given in the doc test for this
result, so how do we know it's right?
Printing the values of 'yellow' and 'gold' I get:
sage: print yellow
RGB color (1.0, 1.0, 0.0)
sage: print gold
RGB color (1.0, 0.84313725490196079, 0.0)
sage:
I personally don't understand how one can divide one colour by another,
but I'm not disputing that there can be some logic in this. I tried in
Mathematica to just divide the these as lists
In[44]:= yellow={1,1,0}
Out[44]= {1, 1, 0}
In[45]:= gold={1.0,0.84313725490196079, 0.0}
In[46]:= gold/Pi + yellow E
Out[46]= {3.03659, 2.98666, 0.}
With no idea what this division is supposed to do, I tried.
In[47]:= Normalize[%]
Out[47]= {0.712944, 0.701221, 0.}
but that gives totally different numbers.
So I'm none the wiser. Of course, I could create a ticket to check the
expected value to be
0.51829585732141..., 0.49333037605210...,0.0
but I'd have no justification for this.
Perhaps someone can enlighten me how one divides /multiples colours, and
can show me a high precision value for the result.
This is just one of several examples I've seen in Sage where the numeric
result from a doc test is not obvious. The "Expected" value is probably
what someone got on their computer. I "Got" a different value on my
computer. But who knows what the result should be? Without some
justification, I find it hard to believe this doc test achieves very
much. I've just waisted an hour trying to work out how I might reproduce
this, but can't
I assume we are talking about the patches up at #5601?
First, note that colors are multiplied by scalars, not by other colors.
The documentation for the multiplication and division methods talk
about what a multiplication or division means---scale the RGB values by
the scalar.
sage: colors.yellow
RGB color (1.0, 1.0, 0.0)
sage: colors.yellow/2
RGB color (0.5, 0.5, 0.0)
sage: colors.yellow*0.3
RGB color (0.2, 0.2, 0.0)
This makes some sort of sense, at least numerically. However, what does
not make sense is when a resulting component is more than one, the
fractional part is taken as the value. Therefore,
sage: colors.red*2
RGB color (0.0, 0.0, 0.0)
I think this is a problem (and missed this when I reviewed the colors
patch, so this getting in is partially my fault!) At least explains
what colors*scalar is. I think this ought to be changed to make more
sense when a resulting component is outside of [0,1] (maybe cap the
values, instead of just take the fractional part). The problem here is
in the rgbcolor() function when it creates a color from a tuple.
The addition of two colors is documented in the function for addition,
and says there that it uses the blend function. The documentation for
blend says
Return a color blended with the given ``color`` by a given
``fraction``. The algorithm interpolates linearly between the
colors' corresponding R, G, and B coordinates.
This is so that colors.red+colors.blue is approximately purple (though
not exactly colors.purple, since colors.purple is a specifically defined
value according to HTML standards). colors.yellow+colors.red is
approximately colors.orange, etc.
Thanks,
Jason
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Re: Memory leak
On 5-Mar-10, at 6:27 PM, Dima Pasechnik wrote: if it's PARI-dependent, it makes sense to upgrade PARI to the latest version. PARI used by Sage is almost 2-year old. They rolled out two upgrades in the meantime. Unfortunately, updating PARI in sage is phenomenally difficult. I tried more than a year ago, and failed miserably. Nick -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Memory leak
if it's PARI-dependent, it makes sense to upgrade PARI to the latest version. PARI used by Sage is almost 2-year old. They rolled out two upgrades in the meantime. Dima On Mar 6, 6:41 am, mhampton wrote: > I tried to confirm that fix, and realized that this problem isn't > occuring on my mac (running 10.6.2). Strange. > > -Marshall > > On Mar 5, 3:25 pm, Gonzalo Tornaria wrote: > > > > > On Fri, Mar 5, 2010 at 10:47 AM, Simon King wrote > > > > Hi! > > > > I created a ticket at > > > http://trac.sagemath.org/sage_trac/ticket/8444 > > > I think this is caused by a duplicate _sig_on in the bottom part of > > pari.__call__. > > > I'll post details and (possible) solution later (feel free to ping me > > in a few days if I forget). > > > Best, > > Gonzalo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Vote on bugs to be fixed for sage-4.4 "stabilization release".
David is trying to argue that the goals for Sage-5.0 should be * Official Solaris 10 support (all tests pass) TARGET DATE: Sometime in March? *instead* of the following: * 90% doctest coverage score (=write about 1500 doctests) * Official Solaris 10 support (all tests pass) * Official Cygwin support (all tests pass) * Close _all_ tickets listed at http://trac.sagemath.org/sage_trac/wiki/stab1 TARGET DATE: Sometime in May. I vote -1 to this. As a user, I expect a major release (defined as a version number bump) to include exciting new toys. Solaris support does not *in my opinion* qualify as an exciting new toy. I anticipate a Slashdot story announcing the new release, followed by a surge of interest and downloads. It is *my opinion* that Solaris support is not an exciting new feature that the resulting publicity should be promoting. If anything, it is *my opinion* that Cygwin support is much more likely to appeal to these potential new users, and would warrant the publicity. Nick PS. Emphasis added because I do not want to fan any flames -- please respond accordingly. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: computational logic @ sagemath
Hi Uli, On Sat, Mar 6, 2010 at 7:10 AM, kuli wrote: > Hello > > Yes, I've seen the logic module, but I think there's only rudimentary > support for propositional logic. I would like to help in implementing > this stuff, Cool! Glad to know you would like to help out. > but need some time, because I have to make myself > comfortable with Python The help and support page [1] contains links to materials suitable for Python beginners. > and the whole sage math development life cycle > and all its features. In that case, allow me to suggest that you skim through the Sage standard documentation [2]. Please pay special attention to the Developer's Guide [3]. At minimum, the first chapter in that document is required reading for any Sage developer. > For example, I thought it would be a great deal to implement a turing- > machine-simulator - the question is how we represent this in sage-math > (it could be simular to http://ironphoenix.org/tril/tm/). Such stuff > would be very interesting for all computer science students. The Sage community has been trying to polish up the graph theory module in the Sage library. I suspect that the graph theory module would be useful in implementing features relating to automata theory. However, an urgent task right now is to get the NetworkX [4] standard package upgraded to at least version 1.0.1. See ticket #7608 [5] for the work so far. It really is awful that Sage still ships with a very old version of NetworkX. If you want to submit code for review, please familiarize yourself with the Sage trac server [6]. In any case, feel free to ask questions on this list if you can't find any relevant documentation that answers your query. [1] http://www.sagemath.org/help.html [2] http://www.sagemath.org/doc/ [3] http://www.sagemath.org/doc/developer/ [4] http://networkx.lanl.gov [5] http://trac.sagemath.org/sage_trac/ticket/7608 [6] http://trac.sagemath.org -- Regards Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Vote on bugs to be fixed for sage-4.4 "stabilization release".
On Fri, Mar 5, 2010 at 5:31 PM, Nick Alexander wrote: > > On 5-Mar-10, at 5:26 PM, Dr. David Kirkby wrote: > >> William Stein wrote: >>> >>> Hi, >>> Goals for Sage-5.0: >>> * 90% doctest coverage score (=write about 1500 doctests) >> >> Hopefully with some justification of why the expected result is what it >> is. Not magic numbers - see >> >> >> http://groups.google.co.uk/group/sage-devel/browse_thread/thread/90d933ea2881cbf8 >> >>> * Official Solaris 10 support (all tests pass) >> >> I personally can't understand why official support for a completely new >> operating system is not sufficient justification for incrementing the major >> version. > > Isn't the Sage-5.0 incrementing the major version number? > > Nick David is trying to argue that the goals for Sage-5.0 should be * Official Solaris 10 support (all tests pass) TARGET DATE: Sometime in March? *instead* of the following: * 90% doctest coverage score (=write about 1500 doctests) * Official Solaris 10 support (all tests pass) * Official Cygwin support (all tests pass) * Close _all_ tickets listed at http://trac.sagemath.org/sage_trac/wiki/stab1 TARGET DATE: Sometime in May. -- William -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Vote on bugs to be fixed for sage-4.4 "stabilization release".
On 5-Mar-10, at 5:26 PM, Dr. David Kirkby wrote: William Stein wrote: Hi, Goals for Sage-5.0: * 90% doctest coverage score (=write about 1500 doctests) Hopefully with some justification of why the expected result is what it is. Not magic numbers - see http://groups.google.co.uk/group/sage-devel/browse_thread/thread/90d933ea2881cbf8 * Official Solaris 10 support (all tests pass) I personally can't understand why official support for a completely new operating system is not sufficient justification for incrementing the major version. Isn't the Sage-5.0 incrementing the major version number? Nick -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Vote on bugs to be fixed for sage-4.4 "stabilization release".
William Stein wrote: Hi, Goals for Sage-5.0: * 90% doctest coverage score (=write about 1500 doctests) Hopefully with some justification of why the expected result is what it is. Not magic numbers - see http://groups.google.co.uk/group/sage-devel/browse_thread/thread/90d933ea2881cbf8 * Official Solaris 10 support (all tests pass) I personally can't understand why official support for a completely new operating system is not sufficient justification for incrementing the major version. Micheal was paid full-time to work on the Solaris port. With his salary, the hardware costs (admittedly some donated by Sun), overheads etc, this port must have cost close to $100,000. I would have thought that time to crack open a bottle of champagne and increment the major release number! * Official Cygwin support (all tests pass) Again, I would see the addition of that alone as being sufficient to increment the major release number. * Close _all_ tickets listed at http://trac.sagemath.org/sage_trac/wiki/stab1 TARGET DATE: Sometime in May. I can't speak for the other goals, but I believe the Solaris one is probably doable, though I have got some failures in 4.4.4.alpha0 which are not as easily fixed as those in 4.3.3. The problem with Solaris 10 support is that people can bring out incompatible changes faster than I can fix them. I have a set of changes sufficient to make 4.3.3 pass all tests. http://trac.sagemath.org/sage_trac/ticket/8409 Now on 4.3.4.alpha0, the following fail (this includes the long doctests). sage -t -long "local/lib/python2.6/site-packages/sagenb-0.7.5.1-py2.6.egg/sagenb/misc/sageinspect.py" sage -t -long "local/lib/python2.6/site-packages/sagenb-0.7.5.1-py2.6.egg/sagenb/notebook/interact.py" sage -t -long "devel/sage/sage/categories/finite_semigroups.py" sage -t -long "devel/sage/sage/categories/examples/finite_semigroups.py" sage -t -long "devel/sage/sage/combinat/posets/posets.py" sage -t -long "devel/sage/sage/plot/colors.py" sage -t -long "devel/sage/sage/homology/delta_complex.py" sage -t -long "devel/sage/sage/homology/cubical_complex.py" sage -t -long "devel/sage/sage/homology/examples.py" sage -t -long "devel/sage/sage/homology/cell_complex.py" sage -t -long "devel/sage/sage/homology/chain_complex.py" sage -t -long "devel/sage/sage/homology/simplicial_complex.py" Total time for all tests: 42573.4 seconds Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] importing sage in another thread
Hi, I played around a little during the sage status reports seminar today with importing the sage library in a second *thread*, which was something that Robert Bradshaw suggested. This has potential. I'm recording something about this here, just for the record (it doesn't really fit for a trac ticket). (1) I created this b.py file from threading import Thread class Imp(Thread): def run(self): import time; t = time.time() print "Background importing sage.all..." import sage.all print "Done!, time=%s"%(time.time()-t) (2) I wrapped all signal calls in the sage library in try/except: blocks (there were 3 such places; see attached patch). (3) Then I did: wst...@ubuntu:~/tmp$ sage -ipython ... In [1]: import b; b.Imp().start() Background importing sage.all... In [2]: print 2+7 --> print(2+7) 9 In [3]: Done!, time=7.73341584206 In [4]: import sage.all # takes *no* time -- William -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org diff -r 41a16cd736e4 sage/all.py --- a/sage/all.py Fri Feb 26 07:28:26 2010 -0800 +++ b/sage/all.py Fri Mar 05 17:04:32 2010 -0800 @@ -59,7 +59,10 @@ import sage.ext.sig sage.ext.sig.get_bad_sigs() from sage.interfaces.get_sigs import get_sigs -get_sigs() +try: +get_sigs() +except: pass + from sage.misc.all import * # takes a while diff -r 41a16cd736e4 sage/interfaces/all.py --- a/sage/interfaces/all.py Fri Feb 26 07:28:26 2010 -0800 +++ b/sage/interfaces/all.py Fri Mar 05 17:04:32 2010 -0800 @@ -35,7 +35,11 @@ from r import r, r_console, R, r_version, is_RElement # signal handling -from get_sigs import * +try: +from get_sigs import * +except Exception, msg: +print msg + interfaces = ['gap', 'gp', 'mathematica', 'gnuplot', \ 'kash', 'magma', 'macaulay2', 'maple', 'maxima', \ diff -r 41a16cd736e4 sage/interfaces/get_sigs.py --- a/sage/interfaces/get_sigs.py Fri Feb 26 07:28:26 2010 -0800 +++ b/sage/interfaces/get_sigs.py Fri Mar 05 17:04:32 2010 -0800 @@ -12,9 +12,10 @@ raise RuntimeError, "A floating point exception occurred." def get_sigs(): -signal.signal(signal.SIGINT, my_sigint) -signal.signal(signal.SIGABRT, my_sigint) -signal.signal(signal.SIGFPE, my_sigfpe) -signal.signal(signal.SIGALRM, my_sigint) +try: +signal.signal(signal.SIGINT, my_sigint) +signal.signal(signal.SIGABRT, my_sigint) +signal.signal(signal.SIGFPE, my_sigfpe) +signal.signal(signal.SIGALRM, my_sigint) +except: pass - diff -r 41a16cd736e4 sage/libs/pari/gen.pyx --- a/sage/libs/pari/gen.pyx Fri Feb 26 07:28:26 2010 -0800 +++ b/sage/libs/pari/gen.pyx Fri Mar 05 17:04:32 2010 -0800 @@ -7974,15 +7974,18 @@ GP_DATA.fmt.sigd = prec_bits_to_dec(53) # Take control of SIGSEGV back from PARI. -import signal -signal.signal(signal.SIGSEGV, signal.SIG_DFL) - -# We do the following, since otherwise the IPython pager -# causes sage to crash when it is exited early. This is -# because when PARI was initialized it set a trap for this -# signal. -import signal -signal.signal(signal.SIGPIPE, _my_sigpipe) +try: +import signal +signal.signal(signal.SIGSEGV, signal.SIG_DFL) + +# We do the following, since otherwise the IPython pager +# causes sage to crash when it is exited early. This is +# because when PARI was initialized it set a trap for this +# signal. +import signal +signal.signal(signal.SIGPIPE, _my_sigpipe) +except: +pass initialized = 1 stack_avma = avma num_primes = maxprime
[sage-devel] Doc tests with no justification for the result.
I just got a doc test failure on Solaris.
File
"/export/home/drkirkby/32/sage-4.3.4.alpha0/devel/sage/sage/plot/colors.py",
line 660:
sage: gold / pi + yellow * e
Expected:
RGB color (0.51829585732141792, 0.49333037605210095, 0.0)
Got:
RGB color (0.51829585732141814, 0.49333037605210117, 0.0)
Looking at the doc test I see this:
--
EXAMPLES::
sage: from __future__ import division
sage: from sage.plot.colors import yellow, gold
sage: yellow / 4
RGB color (0.25, 0.25, 0.0)
sage: yellow.__truediv__(4)
RGB color (0.25, 0.25, 0.0)
sage: gold / pi + yellow * e
RGB color (0.51829585732141792, 0.49333037605210095, 0.0)
--
The is absolutely no justification given in the doc test for this result, so how
do we know it's right?
Printing the values of 'yellow' and 'gold' I get:
sage: print yellow
RGB color (1.0, 1.0, 0.0)
sage: print gold
RGB color (1.0, 0.84313725490196079, 0.0)
sage:
I personally don't understand how one can divide one colour by another, but I'm
not disputing that there can be some logic in this. I tried in Mathematica to
just divide the these as lists
In[44]:= yellow={1,1,0}
Out[44]= {1, 1, 0}
In[45]:= gold={1.0,0.84313725490196079, 0.0}
In[46]:= gold/Pi + yellow E
Out[46]= {3.03659, 2.98666, 0.}
With no idea what this division is supposed to do, I tried.
In[47]:= Normalize[%]
Out[47]= {0.712944, 0.701221, 0.}
but that gives totally different numbers.
So I'm none the wiser. Of course, I could create a ticket to check the expected
value to be
0.51829585732141..., 0.49333037605210...,0.0
but I'd have no justification for this.
Perhaps someone can enlighten me how one divides /multiples colours, and can
show me a high precision value for the result.
This is just one of several examples I've seen in Sage where the numeric result
from a doc test is not obvious. The "Expected" value is probably what someone
got on their computer. I "Got" a different value on my computer. But who knows
what the result should be? Without some justification, I find it hard to believe
this doc test achieves very much. I've just waisted an hour trying to work out
how I might reproduce this, but can't
Dave
Dave
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Re: Doctests writing to files in Sage tree
Hi William, On Sat, Mar 6, 2010 at 9:13 AM, William Stein wrote: > Maybe you somehow upgraded the system-wide sage in January once with > sudo in some way when you were doing release management...? I can assure you that so far, and to the best of my knowledge, I have not done such a thing. I have consistently avoided trying to upgrade the system-wide Sage installation on sage.math. I have always assumed that you want to do that. Please correct me if I'm wrong. -- Regards Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Vote on bugs to be fixed for sage-4.4 "stabilization release".
Hi, Goals for Sage-5.0: * 90% doctest coverage score (=write about 1500 doctests) * Official Solaris 10 support (all tests pass) * Official Cygwin support (all tests pass) * Close _all_ tickets listed at http://trac.sagemath.org/sage_trac/wiki/stab1 TARGET DATE: Sometime in May. -- William -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: trac login problems
Ok, it only happens in my office. Probably some add-on in firefox or some problem with the cookies... Anyway, it doesn't matter anymore. Chris. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Debian package...
Kasper Peeters wrote: Has anyone considered emailing the official maintainer Tim Abbott and ask him whether he would be interested in handing over maintainership to someone with more time to bring the debian package up to date? I would be happy to help out with this (including contacting Abbott), but it will clearly require quite a bit of work because neither Debian nor Ubuntu like packages which duplicate software already in the repositories. Removing sage from Debian/Ubuntu is probably not a good idea, since those repositories are what those users expect to get their software from. Usage of my cadabra CAS went up dramatically once it got into the Ubuntu repositories, even though I had binaries available for download before that. So it would help a lot to have an up-to-date sage in those repositories too. Cheers, Kasper One way the maintainers might accept the huge Sage bundle is if we could produce a big list of changes made to standard packages. Even libz has been patched for OS X. (There is a new beta which will stop that being necessary). The maintainers logic is clear they don't want to duplicate stuff. I can appreciate that. I suggest we approach them, saying we understand this, and that in general it would be silly to include everything. If we then produce a long list of packages which have needed to be patched, then it is less likely they will object. There are several Solaris-specific patches. This could be used to our advantage by saying that Sage is multi-platform, and some patches are needed for Solaris. Maintaining two separate versions of the source code for two different platforms would present us severe difficulties. I suspect the Debian people are reasonable and could be persuaded to accept things if there were aware of just how many patches have needed to be made to 'standard' packages. One package I think we would have a lot of problem justifying is the inclusion of 'Mercurial'. Whether Mercurial is a perquisite for Sage or not is debatable, but including its source code seems unnecessary to me. If someone is going to be submitting patches based on Mercurial, they are probably quite capable of installing it themselves. I personally prefer to use a system wide install, as I can then apply patches without having built Sage. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Memory leak
I tried to confirm that fix, and realized that this problem isn't occuring on my mac (running 10.6.2). Strange. -Marshall On Mar 5, 3:25 pm, Gonzalo Tornaria wrote: > On Fri, Mar 5, 2010 at 10:47 AM, Simon King wrote > > > Hi! > > > I created a ticket at > > http://trac.sagemath.org/sage_trac/ticket/8444 > > I think this is caused by a duplicate _sig_on in the bottom part of > pari.__call__. > > I'll post details and (possible) solution later (feel free to ping me > in a few days if I forget). > > Best, > Gonzalo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: [sage-combinat-devel] Re: Lie Methods and Related Combinatorics
On Fri, Mar 5, 2010 at 9:43 AM, Robert Bradshaw wrote: > On Mar 5, 2010, at 9:08 AM, Minh Nguyen wrote: >> I can see some advantages and disadvantages for introducing the two >> new classifications: FAQs, and Sage HOWTOs. >> >> Pros: All doctests in the above documents are regularly executed >> before each release. Having these HOWTOs and FAQs available with every >> Sage release means that one does not need to download them separately >> from various websites outside of the Sage infrastructure. For a binary >> distribution of Sage, all the standard documentation comes pre-built >> in HTML format. Another good thing (for the Sage website maintainers) >> is that the help and support page [15] would be less cluttered with >> miscellaneous documents. >> >> Cons: It would add some megabytes to the Sage source and binary >> distributions. Who is going to contribute time and effort to make this >> happen? I feel that I should not write such a long email if I'm not >> going to express my firm willingness to contribute to realizing the >> above proposals. As a first round of improvements that implements some >> of the above tasks, I'm willing to incorporate the FAQs into the >> standard documentation. I'm also willing to create the new category >> "Sage HOWTOs" and incorporate the following documents in it: >> >> * Python Functional Programming for Mathematicians >> >> * Number Theory and the RSA Public Key Cryptosystem [13] >> >> I wrote those two documents, so I'm more familiar with them than I am >> with the others. All I'm asking is that people contribute to the >> reviewing process. >> >> Thoughts? Huge +1. I had decided long ago that I wanted something just like you propose above, and I really hope it happens sooner rather than later. The "testing" and "being available with Sage" pro's are really *huge*.They are especially useful for users not on the internet. By the way, if you look at the MATLAB distribution, it's about 3.3GB and most of that is documentation (including videos!). -- William > > The pros certainly seem to outweigh the cons for me. > > - Robert > > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] notebook startup from different paths
On Fri, Mar 5, 2010 at 12:08 PM, Mike Hansen wrote: > On Fri, Mar 5, 2010 at 8:33 AM, Robert Miller wrote: >> [rlm-book sage-4.3.4.alpha0/devel/sage-main]$ ../../sage -notebook >> ImportError: No module named randstate >> [rlm-book sage-4.3.4.alpha0/devel/sage-main]$ cd ../.. >> [rlm-book sage-4.3.4.alpha0]$ ./sage -notebook >> }}} > > This is a pretty common issue for a lot of things. The current > directory gets added to sys.path by default and that takes precedence > over other paths. When you try to import sage from that location, > then it looks in the current directory and sees a sage/ directory that > contains an __init__.py. However, none of the built extension modules > are in that tree. sage.misc.randstate is the first extension module > that tries to get loaded and fails as you see above. > > --Mike > Yep, that's exactly what happened. I've been bitten by this a few times too. Perhaps somebody could actually write some code (in local/bin/sage-sage, say), which would print a big warning if Sage is started from $SAGE_ROOT/devel/sage. It might be tricky to actually write such code that works robustly though... William -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Doctests writing to files in Sage tree
On Fri, Mar 5, 2010 at 11:33 AM, Minh Nguyen wrote: > Hi Ryna, > > On Sat, Mar 6, 2010 at 6:16 AM, Ryan Hinton wrote: > > > >> This isn't a docbuild -- this is a doctest. I'm just running the >> tests. I expect that when I run >> >> /system/path/sage -testall >> >> I should get an "All tests passed!" result for a successful install -- >> whether or not I have write access in the install tree. For example, >> the builder.py doctests might write to temporary files in my ~/.sage >> directory (where I have write access) and then compare their contents >> to the desired result. > > I think I misunderstood you. So allow me to apologize. What I'm trying > to say is that one should avoid trying to use a system-wide Sage > installation to run its own doctests. (Also avoid (re)building the > Sage standard documentation in a system-wide Sage installation.) Could > you please try running doctests using the system-wide Sage > installation on the machine sage.math, and report how it goes? At the > moment, it looks like I can do what you described above. However, > looking at the file permissions in the system-wide installation of > Sage 4.3.3 on the machine sage.math, I see that I have read and write > privileges for some files and directories. (I shouldn't be having such > privileges on sage.math for the system-wide Sage installation.) That's really, really odd. wst...@sage:/usr/local/sage$ ls -lh total 47M -rw-r--r-- 1 mvngu mvngu 71K 2010-02-25 16:18 COPYING.txt drwxr-xr-x 17 root root 4.0K 2010-02-25 17:21 data drwxr-xr-x 4 root root 4.0K 2010-02-25 16:51 devel drwxr-xr-x 15 root root 4.0K 2010-02-04 15:54 examples drwxr-xr-x 22 root root 4.0K 2010-02-06 20:37 extra_docs -rw-r--r-- 1 root root 47M 2010-02-06 20:53 install.log drwxr-xr-x 2 root root 4.0K 2010-02-04 14:55 ipython drwxr-xr-x 15 root root 4.0K 2010-02-25 16:48 local -rw-r--r-- 1 mvngu mvngu 2.6K 2009-12-13 22:09 makefile -rw-r--r-- 1 mvngu mvngu 11K 2010-02-25 16:18 README.txt -rwxr-xr-x 1 mvngu mvngu 1.5K 2010-01-13 19:43 sage Maybe you somehow upgraded the system-wide sage in January once with sudo in some way when you were doing release management...? William -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Debian package...
On Mar 5, 7:27 pm, Kasper Peeters wrote: > I would be happy to help out with this ... I just want to add that there is a package for mandriva. Look here at the list of required packages: http://fr2.rpmfind.net/linux/RPM/mandriva/devel/2010.1/i586/media/contrib/release/sagemath-4.3.3-2mdv2010.1.i586.html Since all their modifications are online, it might be useful to look at their patches how they have done it. H -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Doctests writing to files in Sage tree
On 5 Mrz., 22:29, Simon King wrote: > I think the conclusion in this other thread (that I can't find, I am > afraid) was:... It was ticket http://trac.sagemath.org/sage_trac/ticket/4568 -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Doctests writing to files in Sage tree
Hi! On 5 Mrz., 20:33, Minh Nguyen wrote: > > > I should get an "All tests passed!" result for a successful install -- > > whether or not I have write access in the install tree. For example, > > the builder.py doctests might write to temporary files in my ~/.sage > > directory (where I have write access) and then compare their contents > > to the desired result. IIRC there was some issue of this type previously. In some cases one can't avoid to write data in a doc test. But then, there are two things to worry about: (1) The person who is requesting the test must have write permission -- otherwise the test fails (2) The test must not detroy the person's own data. I think the conclusion in this other thread (that I can't find, I am afraid) was: If a doc test writes data, then it MUST use a temporary file, that is automatically deleted as soon as the sage (test) session is left. temporary file names can be create with tmp_filename(). So, if Ryan found a doc test where a permanent file is written then it's a bug IMO. Best regards, Simon -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Memory leak
On Fri, Mar 5, 2010 at 10:47 AM, Simon King wrote > Hi! > > I created a ticket at > http://trac.sagemath.org/sage_trac/ticket/8444 I think this is caused by a duplicate _sig_on in the bottom part of pari.__call__. I'll post details and (possible) solution later (feel free to ping me in a few days if I forget). Best, Gonzalo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Debian package...
On Mar 5, 8:35 pm, François Bissey wrote: > > Earlier there was some discussion of creating an environmental > > variable that would attempt to build sage with system versions of the > > libraries and other dependencies, rather than the versions shipped > > with sage. Did anything come of that? > > Nothing came out of that, but it would be useful to us packagers. > There are things to carefully consider. > Time as always is the biggest obstacle to anything like that. > > Francois +1 to more consideration, although I don't have much to contribute. One thing I do think is that if sage is packaged for distributions, the target audience for those binaries is probably not the people who are doing cutting-edge mathematical research. So if a dependency has a bug, certainly the patch should try to go upstream ASAP, but a lot of people in the target audience wouldn't be affected by that bug, even though for some people the bug breaks a needed feature or possibly produces wrong results. If people are doing really important stuff, then they can get the latest sage from sage's website. Ben -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Debian package...
> In the past, Tim Abbott asked to be cc'ed on threads like these. I > think his primary difficulty is keeping up with all the dependencies > of sage, especially when sage releases with a patched version of a > dependency that has not made it upstream yet. Debian package > maintainers are unlikely to quickly apply such patches for the > unstable or testing branch, although they might for the experimental > branch. > > Earlier there was some discussion of creating an environmental > variable that would attempt to build sage with system versions of the > libraries and other dependencies, rather than the versions shipped > with sage. Did anything come of that? > Nothing came out of that, but it would be useful to us packagers. There are things to carefully consider. Time as always is the biggest obstacle to anything like that. Francois -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Debian package...
In the past, Tim Abbott asked to be cc'ed on threads like these. I think his primary difficulty is keeping up with all the dependencies of sage, especially when sage releases with a patched version of a dependency that has not made it upstream yet. Debian package maintainers are unlikely to quickly apply such patches for the unstable or testing branch, although they might for the experimental branch. Earlier there was some discussion of creating an environmental variable that would attempt to build sage with system versions of the libraries and other dependencies, rather than the versions shipped with sage. Did anything come of that? Ben -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: computational logic @ sagemath
Hello Yes, I've seen the logic module, but I think there's only rudimentary support for propositional logic. I would like to help in implementing this stuff, but need some time, because I have to make myself comfortable with Python and the whole sage math development life cycle and all its features. For example, I thought it would be a great deal to implement a turing- machine-simulator - the question is how we represent this in sage-math (it could be simular to http://ironphoenix.org/tril/tm/). Such stuff would be very interesting for all computer science students. best regards, Uli Kastlunger -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] notebook startup from different paths
On Fri, Mar 5, 2010 at 8:33 AM, Robert Miller wrote: > [rlm-book sage-4.3.4.alpha0/devel/sage-main]$ ../../sage -notebook > ImportError: No module named randstate > [rlm-book sage-4.3.4.alpha0/devel/sage-main]$ cd ../.. > [rlm-book sage-4.3.4.alpha0]$ ./sage -notebook > }}} This is a pretty common issue for a lot of things. The current directory gets added to sys.path by default and that takes precedence over other paths. When you try to import sage from that location, then it looks in the current directory and sees a sage/ directory that contains an __init__.py. However, none of the built extension modules are in that tree. sage.misc.randstate is the first extension module that tries to get loaded and fails as you see above. --Mike -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Doctests writing to files in Sage tree
Hi Ryna, On Sat, Mar 6, 2010 at 6:16 AM, Ryan Hinton wrote: > This isn't a docbuild -- this is a doctest. I'm just running the > tests. I expect that when I run > > /system/path/sage -testall > > I should get an "All tests passed!" result for a successful install -- > whether or not I have write access in the install tree. For example, > the builder.py doctests might write to temporary files in my ~/.sage > directory (where I have write access) and then compare their contents > to the desired result. I think I misunderstood you. So allow me to apologize. What I'm trying to say is that one should avoid trying to use a system-wide Sage installation to run its own doctests. (Also avoid (re)building the Sage standard documentation in a system-wide Sage installation.) Could you please try running doctests using the system-wide Sage installation on the machine sage.math, and report how it goes? At the moment, it looks like I can do what you described above. However, looking at the file permissions in the system-wide installation of Sage 4.3.3 on the machine sage.math, I see that I have read and write privileges for some files and directories. (I shouldn't be having such privileges on sage.math for the system-wide Sage installation.) -- Regards Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Doctests writing to files in Sage tree
Minh, Thanks for the reply. On Mar 5, 2:03 pm, Minh Nguyen wrote: > Hi Ryan, > > On Sat, Mar 6, 2010 at 5:17 AM, Ryan Hinton wrote: > > I am in the process of running doctests on a machine with a system-wide Sage > > install. I don't have write access to the install area. Several doctests > > for doc/common/builder.py try to write to files in the install area, and so > > fail. > > I think the docbuild failures at ticket #8448 [1] are expected. That > is, say you run all doctests under the directory > SAGE_ROOT/devel/sage-main, where your Sage installation is a > system-wide installation. I would expect that the system-wide > installation was performed by a user with more privileges than a > normal user. Writing to a directory that you don't have access to is > asking for trouble. And the docbuild script is clearly writing to such > a directory. So at the moment, I would consider ticket #8448 as > invalid. But we'll wait and see how all your doctesting turns out. This isn't a docbuild -- this is a doctest. I'm just running the tests. I expect that when I run /system/path/sage -testall I should get an "All tests passed!" result for a successful install -- whether or not I have write access in the install tree. For example, the builder.py doctests might write to temporary files in my ~/.sage directory (where I have write access) and then compare their contents to the desired result. Did I explain better this time? Thanks! - Ryan -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Doctests writing to files in Sage tree
Hi Ryan, On Sat, Mar 6, 2010 at 5:17 AM, Ryan Hinton wrote: > I am in the process of running doctests on a machine with a system-wide Sage > install. I don't have write access to the install area. Several doctests > for doc/common/builder.py try to write to files in the install area, and so > fail. I think the docbuild failures at ticket #8448 [1] are expected. That is, say you run all doctests under the directory SAGE_ROOT/devel/sage-main, where your Sage installation is a system-wide installation. I would expect that the system-wide installation was performed by a user with more privileges than a normal user. Writing to a directory that you don't have access to is asking for trouble. And the docbuild script is clearly writing to such a directory. So at the moment, I would consider ticket #8448 as invalid. But we'll wait and see how all your doctesting turns out. [1] http://trac.sagemath.org/sage_trac/ticket/8448 -- Regards Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] computational logic @ sagemath
Hi Uli On Sat, Mar 6, 2010 at 5:33 AM, kuli wrote: > Secondly, I want to ask you, if it would make sense (I think it makes) > to develop a computational logic module for sage math. I'm thinking of > tools for logic > > -> CNF/DNF convertions > -> boolean truth tables (mandatory) > -> support for predicate logic See the logic module SAGE_ROOT/devel/sage-main/sage/logic/ For an incomplete Quine-McCluskey implementation, see ticket #5910: http://trac.sagemath.org/sage_trac/ticket/5910 > -> support for term rewrite systems > -> support for automatas (turing machines, finite automatas) > -> support for grammar and regular expressions I think such features are yet to be implemented. I would very much love to help out. Can you lay out a plan for such a task at implementing these features? Can you give me papers and references that list relevant algorithms? Would you be willing to help out with the implementation of these and perform code review? -- Regards Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Debian package...
Hi Kasper, On Sat, Mar 6, 2010 at 5:27 AM, Kasper Peeters wrote: > I would be happy to help out with this (including contacting Abbott), > but it will clearly require quite a bit of work because neither Debian > nor Ubuntu like packages which duplicate software already in the > repositories. I would also like to contribute. In the past [1], I have expressed an interest to do so. However, my feeling at the time was that I considered myself too inexperienced to take on the task by myself. What I'm looking for is a partnership in the Debian port effort, where I work with someone who is knowledgeable about Debian and Debian packaging. I'm very much inexperienced with respect to Debian porting. All I'm saying is that the task ahead seems to me too surmountable, and I greatly appreciate if anyone would step up to work with me. [1] http://groups.google.com/group/debian-sage/browse_thread/thread/c2e0b0af7b1b56f1 -- Regards Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Vote on bugs to be fixed for sage-4.4 "stabilization release".
On Mar 5, 2010, at 12:23 AM, Simon King wrote:
Hi Robert!
On Mar 5, 12:42 am, Robert Bradshaw
wrote:
[...]
As soon as anything is done with the object, it
does a *real* import, replaces itself in G with the real thing, and
since the reference from G is gone, the LazyImport object would
eventually be garbage collected.
I've actually intended to do this as well, it'd be easy, but I just
haven't had time to do it. Note, however, that this is not
transitive,
so the lazy objects may still be around.
You mean, if you have
sage: imp =
LazyImport(globals(),'QQ','sage.rings.rational_field','MyQQ')
then "imp" would remain lazy even if at some point it injects QQ into
globals()? Sure, this would be difficult to circumvent, but that way
of usage is certainly discouraged.
(This is less of an issue for
the global namespace, but if someone does "from sage.all import foo"
they'll have the lazy version forever.)
Why? If you start with a lazy import of "foo" then foo will be a
LazyImport object, to start with. If you then do "from sage.all import
foo" then the reference "foo" to the LazyImport object is replaced by
a reference to what was just imported; as there is no pointer to the
LazyImport object, garbage collection will work.
What I was referring to is the lack of transitivity. If in sage.all
you have
lazy_import("sage.rings.all", "foo")
than anything that does "from sage.all import foo" before foo is
looked up will have the lazy version, even if sage.all's reference is
updated.
There's some other
improvements that I'd like to make too. You willing to referee a
patch
in this direction? :)
Sure! Where is the ticket?
I'll get a patch up later today (I think all that's missing is some
doctests, but I'll have to see).
- Robert
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Re: Debian package...
On Mar 5, 2010, at 10:27 AM, Kasper Peeters wrote: Has anyone considered emailing the official maintainer Tim Abbott and ask him whether he would be interested in handing over maintainership to someone with more time to bring the debian package up to date? I would be happy to help out with this (including contacting Abbott), but it will clearly require quite a bit of work because neither Debian nor Ubuntu like packages which duplicate software already in the repositories. Removing sage from Debian/Ubuntu is probably not a good idea, since those repositories are what those users expect to get their software from. Usage of my cadabra CAS went up dramatically once it got into the Ubuntu repositories, even though I had binaries available for download before that. So it would help a lot to have an up-to-date sage in those repositories too. Clearly we want up-to-date packages in the repositories, but the current situation of a really old, broken Sage is much worse than not being there at all. - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] computational logic @ sagemath
Hello, first at all I want to congratulate you all for your work at sagemath. I think it's very important that there are free high-quality math- solutions available. Secondly, I want to ask you, if it would make sense (I think it makes) to develop a computational logic module for sage math. I'm thinking of tools for logic -> CNF/DNF convertions -> boolean truth tables (mandatory) -> support for predicate logic -> support for term rewrite systems -> support for automatas (turing machines, finite automatas) -> support for grammar and regular expressions ... maybe I can convince (although this would take some time, because I'm still an undergraduate) my tutors to do a master project in this field. I've although another suggestion. The browser-approach is a super idea, but why do you have to be logged in to do your work. Wouldn't it be a cool idea, to make the resources available by one site (something like sagemath.org), so that you can use it like google, but for calculation stuff. I know, there's wolfram alpha, but I think such stuff has to be free. best regards, uli kastlunger -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Debian package...
Has anyone considered emailing the official maintainer Tim Abbott and ask him whether he would be interested in handing over maintainership to someone with more time to bring the debian package up to date? I would be happy to help out with this (including contacting Abbott), but it will clearly require quite a bit of work because neither Debian nor Ubuntu like packages which duplicate software already in the repositories. Removing sage from Debian/Ubuntu is probably not a good idea, since those repositories are what those users expect to get their software from. Usage of my cadabra CAS went up dramatically once it got into the Ubuntu repositories, even though I had binaries available for download before that. So it would help a lot to have an up-to-date sage in those repositories too. Cheers, Kasper -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Doctests writing to files in Sage tree
I am in the process of running doctests on a machine with a system-wide Sage install. I don't have write access to the install area. Several doctests for doc/common/builder.py try to write to files in the install area, and so fail. I created trac #8448 for this, but thought I should post it here so "the right person" is aware of the problem. Thanks! - Ryan -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: [sage-combinat-devel] Re: Lie Methods and Related Combinatorics
On Mar 5, 2010, at 9:08 AM, Minh Nguyen wrote: Hi Dan, On Sat, Mar 6, 2010 at 2:12 AM, bump wrote: Of course the documentation in the source files is essential. But although there is adequate documentation in the source files for someone who knows it is there and wants to dig, you don't get any sense of how to use the program from the reference manual. I'm glad you brought this up. Your description above nicely sums up the purpose of a reference manual, and at the same time points out its drawbacks. I think that for Lie group computations, Sage now has adequate tools for all the typical problems. (If there are gaps, let us fill them.) But people don't seem to know this. So I wanted to write a tutorial. A tutorial has a different function from the documentation in the source files and should be complementary. I personally like the way the Python standard documentation [1] is organized. And I very much like the Sage standard documentation to adopt what works for end users and beginners. Another possible source of inspiration for improving the Sage documentation can be found in the Perl documentation [2]. As regards accessible documentation, I hold the Django documentation [3] in high esteem. Probably Sage would benefit from an expanded set of good tutorials here: http://www.sagemath.org/doc/ To get the Lie tutorial into that page I guess I would edit devel/sage/doc/en/website/templates/index.html when the patch is revised. Before you do so, for the record, I would like to point out some ideas that have been in the documentation backlog for quite some time. A review of the current Sage documentation shows that it consists of the following: * Tutorial --- a tutorial guide to some of Sage's features that are useful for beginners. * Developer's Guide --- guidelines and policies regarding Sage development. * Constructions --- various short guides along the line of "How do I...?" * Reference Manual --- the Sage reference manual. * A Tour of Sage --- a very short guide along the line of Mathematica's tour. * Numerical Guide --- numerical computation with Sage. * Installation Guide --- how to install Sage. * Three Lectures about Explicit Methods in Number Theory Using Sage --- how to do computations in algebraic number theory, especially number fields and modular forms. What I'm proposing and offer for discussion (and am willing to devote time and energy to the effort) is this. Expand the Sage standard documentation to include the following: * Sage HOWTOs --- consisting of various in-depth documents on specific topics. * FAQs --- a collection of answers to frequently asked questions. The FAQs can incorporate the existing one on the Sage wiki [4], in addition to fleshing it out further. The category of Sage HOWTOs needs more thought. Some chapters in the Constructions Document [5] fit nicely within the category of HOWTOs, e.g. * Linear Programming * Python Functional Programming for Mathematicians But are not all of the chapters making up the Constructions Document written in the style of HOWTOs? I don't know how to answer this question myself. Anyway, if one is to include in-depth guides in the "Sage HOWTOs" classification, I would propose first including the following: * Python Functional Programming for Mathematicians * Sage and Coding Theory [6,7] * Sage and Cython: A Brief Introduction [8] * Linear Programming in Sage [9,10] * Group Theory and Sage: A Primer [11] * Sage and Cython: A Brief Introduction [12] * Number Theory and the RSA Public Key Cryptosystem [13] * Lie Methods and Related Combinatorics [14] I can't help but put the number 13 next to the number theory document because that document deals with prime numbers :-) I can see some advantages and disadvantages for introducing the two new classifications: FAQs, and Sage HOWTOs. Pros: All doctests in the above documents are regularly executed before each release. Having these HOWTOs and FAQs available with every Sage release means that one does not need to download them separately from various websites outside of the Sage infrastructure. For a binary distribution of Sage, all the standard documentation comes pre-built in HTML format. Another good thing (for the Sage website maintainers) is that the help and support page [15] would be less cluttered with miscellaneous documents. Cons: It would add some megabytes to the Sage source and binary distributions. Who is going to contribute time and effort to make this happen? I feel that I should not write such a long email if I'm not going to express my firm willingness to contribute to realizing the above proposals. As a first round of improvements that implements some of the above tasks, I'm willing to incorporate the FAQs into the standard documentation. I'm also willing to create the new category "Sage HOWTOs" and incorporate the following documents in it: * Python Functional Programming for Mathematicians * Number Theory and the RSA Public K
[sage-devel] Re: [sage-combinat-devel] Re: Lie Methods and Related Combinatorics
Hi Dan, On Sat, Mar 6, 2010 at 2:12 AM, bump wrote: > Of course the documentation in the source files is essential. But > although > there is adequate documentation in the source files for someone who > knows it > is there and wants to dig, you don't get any sense of how to use the > program > from the reference manual. I'm glad you brought this up. Your description above nicely sums up the purpose of a reference manual, and at the same time points out its drawbacks. > I think that for Lie group computations, Sage now has adequate tools > for all the > typical problems. (If there are gaps, let us fill them.) But people > don't seem to know this. > So I wanted to write a tutorial. A tutorial has a different function > from the > documentation in the source files and should be complementary. I personally like the way the Python standard documentation [1] is organized. And I very much like the Sage standard documentation to adopt what works for end users and beginners. Another possible source of inspiration for improving the Sage documentation can be found in the Perl documentation [2]. As regards accessible documentation, I hold the Django documentation [3] in high esteem. > Probably Sage would benefit from an expanded set of good tutorials > here: > > http://www.sagemath.org/doc/ > > To get the Lie tutorial into that page I guess I would edit > > devel/sage/doc/en/website/templates/index.html > > when the patch is revised. Before you do so, for the record, I would like to point out some ideas that have been in the documentation backlog for quite some time. A review of the current Sage documentation shows that it consists of the following: * Tutorial --- a tutorial guide to some of Sage's features that are useful for beginners. * Developer's Guide --- guidelines and policies regarding Sage development. * Constructions --- various short guides along the line of "How do I...?" * Reference Manual --- the Sage reference manual. * A Tour of Sage --- a very short guide along the line of Mathematica's tour. * Numerical Guide --- numerical computation with Sage. * Installation Guide --- how to install Sage. * Three Lectures about Explicit Methods in Number Theory Using Sage --- how to do computations in algebraic number theory, especially number fields and modular forms. What I'm proposing and offer for discussion (and am willing to devote time and energy to the effort) is this. Expand the Sage standard documentation to include the following: * Sage HOWTOs --- consisting of various in-depth documents on specific topics. * FAQs --- a collection of answers to frequently asked questions. The FAQs can incorporate the existing one on the Sage wiki [4], in addition to fleshing it out further. The category of Sage HOWTOs needs more thought. Some chapters in the Constructions Document [5] fit nicely within the category of HOWTOs, e.g. * Linear Programming * Python Functional Programming for Mathematicians But are not all of the chapters making up the Constructions Document written in the style of HOWTOs? I don't know how to answer this question myself. Anyway, if one is to include in-depth guides in the "Sage HOWTOs" classification, I would propose first including the following: * Python Functional Programming for Mathematicians * Sage and Coding Theory [6,7] * Sage and Cython: A Brief Introduction [8] * Linear Programming in Sage [9,10] * Group Theory and Sage: A Primer [11] * Sage and Cython: A Brief Introduction [12] * Number Theory and the RSA Public Key Cryptosystem [13] * Lie Methods and Related Combinatorics [14] I can't help but put the number 13 next to the number theory document because that document deals with prime numbers :-) I can see some advantages and disadvantages for introducing the two new classifications: FAQs, and Sage HOWTOs. Pros: All doctests in the above documents are regularly executed before each release. Having these HOWTOs and FAQs available with every Sage release means that one does not need to download them separately from various websites outside of the Sage infrastructure. For a binary distribution of Sage, all the standard documentation comes pre-built in HTML format. Another good thing (for the Sage website maintainers) is that the help and support page [15] would be less cluttered with miscellaneous documents. Cons: It would add some megabytes to the Sage source and binary distributions. Who is going to contribute time and effort to make this happen? I feel that I should not write such a long email if I'm not going to express my firm willingness to contribute to realizing the above proposals. As a first round of improvements that implements some of the above tasks, I'm willing to incorporate the FAQs into the standard documentation. I'm also willing to create the new category "Sage HOWTOs" and incorporate the following documents in it: * Python Functional Programming for Mathematicians * Number Theory and the RSA Public Key Cryptosystem [13] I
[sage-devel] Re: Debian package...
On 5 Mar, 15:27, William Stein wrote: > On Fri, Mar 5, 2010 at 7:09 AM, Dima Pasechnik wrote: > > here is the response from one of Debian folks > > Bill says: > > >> >>http://groups.google.com/group/sage-support/t/1f055a381532b667#354256... > > > This email mentions problem with Ubuntu. Removing the package from Ubuntu > > is a totally different issue from removing it from Debian. > > Thanks Bill for explaining everything, which I greatly appreciate. > > So the new question (for the list): how do we get Sage out of Ubuntu? > > -- William I don't know, but the obvious way to stop this in future is to issue a suitable warning when the date on the computer exceeds the Sage release data by some period of time. I suggest two levels of warnings - perhaps one after 4 months, and a stronger one after a year. This is http://trac.sagemath.org/sage_trac/ticket/8447 It will at least stop this being such an issue in future, as the user will be reminded each time they start Sage that they are using an old version. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: sage server user pool
ok, that's what I understood. I do have the ssh thing set upproperly (otherwise it would not work at all). The *only* think not working is when magma is run! John On 5 March 2010 15:26, Dr David Kirkby wrote: > > > On 5 Mar, 13:53, John Cremona wrote: >> A while back I reported a problem, but had not much useful feedback. I >> am running a local sage server which runs under the user "sage" and I >> created a pool of other users sage0, ..., sage3 under which the >> individual worksheets run. That basically worked fine, except that I >> could not run magma from a worksheet (by putting %magma in the top of >> the cell) because of some file/directory permissions issue. >> >> Well, I just turned off the pool of worksheet process users, and now >> %magma works fine. (I cannot quite remember what the advantage of the >> user pool was supposed to be.) >> >> Just in case anyone was trying to trouble shoot... >> >> Can anyone else running a server with a pool of users confirm (or >> otherwise) that %magma in a cell works? >> >> John > > From what I understand the advantage of running one username in the > pool is that the user processes run as that user, and so a user can't > crash the server. > > But from what feedback I got from William, there was no advantage in > having more than one username in the pool. The usernames are not > mapped in any way to the pool names. > > The username the server runs under needs to be able to ssh to the > users with no password. i.e. you need to create a key on the server > which has an emptry pass phrase, then copy that to $HOME/.ssh/ > authorized_keys of each username in the pool. > > It would be a lot more secure if one user name was mapped to one user > in the pool, as any user can kill all the processes of everyone else > running under the same user name. > > Dave > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] trac login problems
Did anyone run into a similar problem : Everytime I would like to do something (like adding a patch, reviewing one...) on http://trac.sagemath.org/sage_trac/ it logs me out. And then I am not allowed to do it anymore. I can log in, though. Any idea ? Chris. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] notebook startup from different paths
I wasn't sure if this was a known bug or not, so I thought I'd post
here before creating a new ticket. I tried running the notebook from
the command line, and it only worked from certain places:
{{{
[rlm-book sage-4.3.4.alpha0/devel/sage-main]$ ../../sage -notebook
--
| Sage Version 4.3.4.alpha0, Release Date: 2010-03-03|
| Type notebook() for the GUI, and license() for information.|
--
**
**
* Warning: this is a prerelease version, and it may be unstable. *
**
**
Please wait while the Sage Notebook server starts...
Traceback (most recent call last):
File "/Users/rlmill/sage-4.3.4.alpha0/local/bin/sage-notebook", line
9, in
from sage.server.notebook.all import notebook
File
"/Users/rlmill/sage-4.3.4.alpha0/devel/sage-main/sage/server/notebook/all.py",
line 22, in
from sagenb.notebook.all import *
File
"/Users/rlmill/sage-4.3.4.alpha0/local/lib/python2.6/site-packages/sagenb-0.7.5.1-py2.6.egg/sagenb/notebook/all.py",
line 16, in
from notebook_object import notebook, inotebook
File
"/Users/rlmill/sage-4.3.4.alpha0/local/lib/python2.6/site-packages/sagenb-0.7.5.1-py2.6.egg/sagenb/notebook/notebook_object.py",
line 17, in
import notebook as _notebook
File
"/Users/rlmill/sage-4.3.4.alpha0/local/lib/python2.6/site-packages/sagenb-0.7.5.1-py2.6.egg/sagenb/notebook/notebook.py",
line 40, in
import js # javascript
File
"/Users/rlmill/sage-4.3.4.alpha0/local/lib/python2.6/site-packages/sagenb-0.7.5.1-py2.6.egg/sagenb/notebook/js.py",
line 38, in
from sage.misc.misc import SAGE_ROOT
File "/Users/rlmill/sage-4.3.4.alpha0/devel/sage-main/sage/misc/misc.py",
line 38, in
import sage.misc.prandom as random
File "/Users/rlmill/sage-4.3.4.alpha0/devel/sage-main/sage/misc/prandom.py",
line 56, in
from sage.misc.randstate import current_randstate
ImportError: No module named randstate
[rlm-book sage-4.3.4.alpha0/devel/sage-main]$ cd ../..
[rlm-book sage-4.3.4.alpha0]$ ./sage -notebook
}}}
(Everything worked under this second attempt.)
--
Robert L. Miller
http://www.rlmiller.org/
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
[sage-devel] Re: Sage Development. Thank you to Dennis Clark of Blastwave
On 5 Mar, 12:23, David Kirkby wrote: > Dennis Clark of Blastwave has given me access to a Blade 2000 with a > couple of 1.6 GHz CPUs. > Dave Oops, it was a Sun Blade 2500 Dennis gave me access to - not a Blade 2000. The Blade 2000 is limited to CPUs of 1.2 GHz, whereas the 2500's can take 1.6 GHz CPUS. But the two Blade 2500's on skynet have the slower 1280 MHZ CPUs, so are only marginanally faster than my box. In practice, on a shared system, I'm better off using what I have at home. But Dennis' machine is significantly faster - and saves my electric bill !! Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Debian package...
On Fri, Mar 5, 2010 at 7:09 AM, Dima Pasechnik wrote: > here is the response from one of Debian folks Bill says: >> >>http://groups.google.com/group/sage-support/t/1f055a381532b667#354256... > > This email mentions problem with Ubuntu. Removing the package from Ubuntu > is a totally different issue from removing it from Debian. Thanks Bill for explaining everything, which I greatly appreciate. So the new question (for the list): how do we get Sage out of Ubuntu? -- William > > > -- Forwarded message -- > From: Bill Allombert > Date: 5 March 2010 18:49 > Subject: Re: Fwd: Debian package... > To: Dima Pasechnik > > > On Thu, Mar 04, 2010 at 08:28:53PM -0800, Dima Pasechnik wrote: >> Dear Bill, >> >> do you know how to handle this? >> We would like remove Sage from debian, as it is horribly >> outdated there, and there is no work being done on fixing >> the debian distribution. > > Hello Dima, Sage is not really in Debian, since the "sagemath" Debian package > is only in the 'unstable' distibution an not in 'testing', 'squeeze' or > 'stable', 'lenny': This is the list of sagemath in Debian: > > sagemath | 3.0.5dfsg-5.1 | unstable | source, amd64 > sagemath | 3.0.5dfsg-5.1+b1 | unstable | hppa, i386, ia64, > powerpc, s390, sparc > > There are 3 critical bugs reported on the package, so no further action is > required, though you can report a bug with severity grave asking it to > be removed because it is outdated. > > However I have some comment on William email below: > >> -- Forwarded message -- >> From: William Stein >> To: sage-devel >> >> >>> Disclaimer: I'm not a debian user and my intend is not to launch a >> >>> flame nor to disregard the hard work that has been done to have a >> >>> sage debian package. >> >> >>> However, during sage days 20 as well as during my course at the >> >>> university of Rouen, I've got at least a dozen reports of people >> >>> trying to install sage with the standard "dpkg -i". Everything, looks >> >>> fine except that this sage seems to be broken. Maxima simply does not >> >>> start (just try x+1). I'm quite concerned that debian is a quite wide >> >>> spread distro, and that for all these guys the image of sage is >> >>> something huge that simply doesn't work. I was very angry when I >> >>> heard this very argument from a colleague and two students. If >> >>> confirmed, couldn't we make an official request to debian that this >> >>> package is removed from their repositories. This non working sage is >> >>> a very bad publicity... > > If the users really used 'dpkg -i' to install the package, then much probably > it was not the official Debian package, because such package are normally > installed by high-level tools like 'apt-get', 'aptitude' or 'synaptics', that > will take care of downloading and installing the numberous dependencies. > 'dpkg -i' does not and is likely to fail. > > If they actually used 'dpkg -i' they probably downloadied some unofficial > .deb file from some web site (maybe even sagemath.org) and used > dpkg -i *.deb to install it. > >> >> See also: >> > >> > We might make a PPA for Ubuntu. If someone is interested in an easy way to >> > install Sage via dpkg, that might be the best option at this point. >> >> > I agree that removing sage 3.0.5 (or whatever version it is) from Debian is >> > probably best, since our first piece of advice to anyone is to uninstall it >> > and install Sage from scratch. >> >> Yes, +1 to removing sage 3.0.5 from Debian. >> >> But how do we make that happen? > > Cheers, > Bill > > > > -- > Dmitrii Pasechnik > - > DISCLAIMER: Any text following this sentence does not constitute a > part of this message, and was added automatically during transmission. > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: sage server user pool
On 5 Mar, 13:53, John Cremona wrote: > A while back I reported a problem, but had not much useful feedback. I > am running a local sage server which runs under the user "sage" and I > created a pool of other users sage0, ..., sage3 under which the > individual worksheets run. That basically worked fine, except that I > could not run magma from a worksheet (by putting %magma in the top of > the cell) because of some file/directory permissions issue. > > Well, I just turned off the pool of worksheet process users, and now > %magma works fine. (I cannot quite remember what the advantage of the > user pool was supposed to be.) > > Just in case anyone was trying to trouble shoot... > > Can anyone else running a server with a pool of users confirm (or > otherwise) that %magma in a cell works? > > John >From what I understand the advantage of running one username in the pool is that the user processes run as that user, and so a user can't crash the server. But from what feedback I got from William, there was no advantage in having more than one username in the pool. The usernames are not mapped in any way to the pool names. The username the server runs under needs to be able to ssh to the users with no password. i.e. you need to create a key on the server which has an emptry pass phrase, then copy that to $HOME/.ssh/ authorized_keys of each username in the pool. It would be a lot more secure if one user name was mapped to one user in the pool, as any user can kill all the processes of everyone else running under the same user name. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Debian package...
here is the response from one of Debian folks -- Forwarded message -- From: Bill Allombert Date: 5 March 2010 18:49 Subject: Re: Fwd: Debian package... To: Dima Pasechnik On Thu, Mar 04, 2010 at 08:28:53PM -0800, Dima Pasechnik wrote: > Dear Bill, > > do you know how to handle this? > We would like remove Sage from debian, as it is horribly > outdated there, and there is no work being done on fixing > the debian distribution. Hello Dima, Sage is not really in Debian, since the "sagemath" Debian package is only in the 'unstable' distibution an not in 'testing', 'squeeze' or 'stable', 'lenny': This is the list of sagemath in Debian: sagemath | 3.0.5dfsg-5.1 | unstable | source, amd64 sagemath | 3.0.5dfsg-5.1+b1 | unstable | hppa, i386, ia64, powerpc, s390, sparc There are 3 critical bugs reported on the package, so no further action is required, though you can report a bug with severity grave asking it to be removed because it is outdated. However I have some comment on William email below: > -- Forwarded message -- > From: William Stein > To: sage-devel > > >>> Disclaimer: I'm not a debian user and my intend is not to launch a > >>> flame nor to disregard the hard work that has been done to have a > >>> sage debian package. > > >>> However, during sage days 20 as well as during my course at the > >>> university of Rouen, I've got at least a dozen reports of people > >>> trying to install sage with the standard "dpkg -i". Everything, looks > >>> fine except that this sage seems to be broken. Maxima simply does not > >>> start (just try x+1). I'm quite concerned that debian is a quite wide > >>> spread distro, and that for all these guys the image of sage is > >>> something huge that simply doesn't work. I was very angry when I > >>> heard this very argument from a colleague and two students. If > >>> confirmed, couldn't we make an official request to debian that this > >>> package is removed from their repositories. This non working sage is > >>> a very bad publicity... If the users really used 'dpkg -i' to install the package, then much probably it was not the official Debian package, because such package are normally installed by high-level tools like 'apt-get', 'aptitude' or 'synaptics', that will take care of downloading and installing the numberous dependencies. 'dpkg -i' does not and is likely to fail. If they actually used 'dpkg -i' they probably downloadied some unofficial .deb file from some web site (maybe even sagemath.org) and used dpkg -i *.deb to install it. > >> See also: > > >>http://groups.google.com/group/sage-support/t/1f055a381532b667#354256... This email mentions problem with Ubuntu. Removing the package from Ubuntu is a totally different issue from removing it from Debian. > > We might make a PPA for Ubuntu. If someone is interested in an easy way to > > install Sage via dpkg, that might be the best option at this point. > > > I agree that removing sage 3.0.5 (or whatever version it is) from Debian is > > probably best, since our first piece of advice to anyone is to uninstall it > > and install Sage from scratch. > > Yes, +1 to removing sage 3.0.5 from Debian. > > But how do we make that happen? Cheers, Bill -- Dmitrii Pasechnik - DISCLAIMER: Any text following this sentence does not constitute a part of this message, and was added automatically during transmission. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] sage server user pool
A while back I reported a problem, but had not much useful feedback. I am running a local sage server which runs under the user "sage" and I created a pool of other users sage0, ..., sage3 under which the individual worksheets run. That basically worked fine, except that I could not run magma from a worksheet (by putting %magma in the top of the cell) because of some file/directory permissions issue. Well, I just turned off the pool of worksheet process users, and now %magma works fine. (I cannot quite remember what the advantage of the user pool was supposed to be.) Just in case anyone was trying to trouble shoot... Can anyone else running a server with a pool of users confirm (or otherwise) that %magma in a cell works? John -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Sage Development. Thank you to Dennis Clark of Blastwave
Hi David, On Fri, Mar 5, 2010 at 11:23 PM, David Kirkby wrote: > Perhaps Harald could add this fact the acknowledgements page. Done. Please see the updated acknowledgement page: http://www.sagemath.org/development-ack.html -- Regards Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Failure building MPIR on sage 4.3.2
I doubt Sage will include mpir 1.3.1. Numerous versions of sage have past without including this, so presumably there is some reason for that. But I'm sure sage will eventually update to *some* more recent version of MPIR, which will certainly fix the yasm issues, and perhaps many others. Bill. On 4 Mar, 00:44, Ryan Hinton wrote: > I just tried building MPIR 1.3.1 on /tmp -- a local file system -- > instead of the network file system I was using before. Suddenly, it > works! > > I assume the next Sage release will include this MPIR revision. Sage > 4.3.3 (MPIR 1.2.2) fails to build yasm as before. > > Thanks! > > - Ryan -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Memory leak
Hi! I created a ticket at http://trac.sagemath.org/sage_trac/ticket/8444 Best regards, Simon -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Cayley tables, Operation tables
On Fri, Mar 5, 2010 at 12:04 AM, Rob Beezer wrote: > Cayley tables for groups aren't working properly (http:// > trac.sagemath.org/sage_trac/ticket/7340), so I've taken this as an > excuse to write some new code for a more general object I've been > calling an "operation table." (http://trac.sagemath.org/sage_trac/ > ticket/7555) Besides groups, it could be used with lattices, for both > operations in a ring, etc. I wonder if this could even morph into a pseudo-spreadsheet class? You could attach formulas to certain cells then evaluate them and plot the results using matplotlib? > > Cayley tables are currently matrices over a ring of multivariate > polynomials, where each element of the group is represented by a > different variable. My approach is to simply create tables to look > at, ie ASCII or Latex or colored squares or Before I get this all > organized to contribute I could use some advice on two questions: > > 1) Where would you park this? I'd be inclined to stick it in a > misc.py module somewhere since it might be employed in a variety of > places, but I don't even see a natural choice for an existing such > module to add to, nor an obvious place to start a new one. > > 2) It would be unwieldy to place actual elements of, say a > permutation group, into the body of the table. Similar to the > variables mentioned above, I've been representing elements by > "integers" (according to the ordering output by list()), using 0's on > the left to pad to a common width, so elements might look like '03' > and '12'. This runs the risk of being confused with actual integer > elements of a group, ring or lattice in certain situations. However, > I would also like to allow alternate orderings (with keyword > requests), for example, in the presence of a normal subgroup the table > can have a nice block structure if the elements are ordered by > cosets. Any ideas for compact ways to consistently represent elements > of an algebraic structure in such a visual table? > > Thanks, > Rob > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Sage Development. Thank you to Dennis Clark of Blastwave
As those who have used 't2' know, it is not the fastest machine in the world. The machines I have at home * Sun Blade 1000 , dual 900 MHZ, 2 GB RAM * Sun Blade 2000, dual 1.2 GHz, are both faster. I tried using skynet yesterday, but the two machines on there (Sun Bade 2500's with 1.28 GHz processors) should be marginally quicker than my Blade 2000, but in practice they are not, as they are heavily used. Both had 2 CPU bound tasks running on them. Dennis Clark of Blastwave has given me access to a Blade 2000 with a couple of 1.6 GHz CPUs. Whilst this is not as quick as an M3000 which I feel would be an ideal machine for Sage development, it is significantly quicker than anything I own. It will also allow me to power off my machines, which is a welcome relief due to their running costs. Perhaps Harald could add this fact the acknowledgements page. If Willam has any chance of getting funding for futher hardware, then an Sun (now Oracle) M3000 http://www.oracle.com/us/products/servers-storage/servers/sparc-enterprise/031588.htm is the cheapest new machine that will give us a perfomrance bost over anything else any of us have access to. The processors are 3 generations newer than anything I have any acess two, and run at almost twice the speed. It's a real shame the T5240 donated by Sun is not working well for us - it is designed for a totally different task. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Debian package...
Hi, > > Disclaimer: I'm not a debian user and my intend is not to launch a > > flame nor to disregard the hard work that has been done to have a > > sage debian package. > > > > However, during sage days 20 as well as during my course at the > > university of Rouen, I've got at least a dozen reports of people > > trying to install sage with the standard "dpkg -i". Everything, looks > > fine except that this sage seems to be broken. Maxima simply does not > > start (just try x+1). I'm quite concerned that debian is a quite wide > > spread distro, and that for all these guys the image of sage is > > something huge that simply doesn't work. I was very angry when I > > heard this very argument from a colleague and two students. If > > confirmed, couldn't we make an official request to debian that this > > package is removed from their repositories. This non working sage is > > a very bad publicity... > > +10 If you think this is of any use and if I have an official mandate from the sage community, I'm willing to ping again the maintainer to push those things forward. This is very irritating and deserve sage a lot. Cheers, Florent -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Vote on bugs to be fixed for sage-4.4 "stabilization release".
Hi Robert! On Mar 5, 12:42 am, Robert Bradshaw wrote: [...] > > As soon as anything is done with the object, it > > does a *real* import, replaces itself in G with the real thing, and > > since the reference from G is gone, the LazyImport object would > > eventually be garbage collected. > > I've actually intended to do this as well, it'd be easy, but I just > haven't had time to do it. Note, however, that this is not transitive, > so the lazy objects may still be around. You mean, if you have sage: imp = LazyImport(globals(),'QQ','sage.rings.rational_field','MyQQ') then "imp" would remain lazy even if at some point it injects QQ into globals()? Sure, this would be difficult to circumvent, but that way of usage is certainly discouraged. > (This is less of an issue for > the global namespace, but if someone does "from sage.all import foo" > they'll have the lazy version forever.) Why? If you start with a lazy import of "foo" then foo will be a LazyImport object, to start with. If you then do "from sage.all import foo" then the reference "foo" to the LazyImport object is replaced by a reference to what was just imported; as there is no pointer to the LazyImport object, garbage collection will work. > There's some other > improvements that I'd like to make too. You willing to referee a patch > in this direction? :) Sure! Where is the ticket? Best regards, Simon -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: When we say all tests pass, do we include optional ones ?
Hello ! > actually, some of these "optional" things here only need an LP solver > (not a MILP solver), and Sage does have an LP solver, via > a standard package CVXOPT. > It would be nice to get rid of these dependencies on optional > packages. Well, the only algorithm which I think could be replaced now is the matching function, if we can ensure that the solution returned by cvxopt is an integer one. But it would *really* be nice, if we were to do that, to use cvxopt through the same LP class and not by defining manually the matrix, etc, etc.. Theoretically, the same thing should be possible for the flow function too, though not the way it is defined now : there are optional arguments to this function to let the user add constraints like "a vertex receives at most 1 of flow", or even directly the integrity of the flow, as this function is also used (I believe) to find edge- disjoint paths between two vertices, etc. I do not know what cvxopt would return in this case. Do you know how cvxopt compares for Linear Programs with GLPK/CPLEX/ CBC in term of speed ? Nathann P.S. : Oh, and let me say again that I am sorry for these broken docstrings... All these errors are already fixed in some patches waiting for review in Graph Theory or Numerical, because I corrected them while working on other things... I should have taken the time to write independent patches, but well... :-p -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
