[sage-devel] google 3d browser api
Hi, I just discovered: http://code.google.com/apis/o3d/ watch the video there. I think this is awesome -- I hope sooner or later all major browsers implement something like this, then it could be used for all kinds of 3d interaction in the notebook. Ondrej --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Thursday 23 April 2009, mabshoff wrote: > Hello, > > while there should be a quick 3.4.2 to mop up patches from trac before > the big 4.0 jump today we had a planning session during the UW status > meeting about the goals for Sage 4.0. The result is at > >http://wiki.sagemath.org/plan/sage-4.0 > > It still needs a little polish, i.e. the issues for Solaris as well as > 64 bit OSX support need to be fleshed out, but the 75% coverage target > has a lot of concrete projects and/or suggestions on what to attack. > If anyone has some other suggestions for large projects that are > doable in the next 3 weeks please let us know. I'd add: first class support for multivariate polynomials over rings (Z and Z/nZ) to the list: this is basically equivalent to updating to Singular 3.1 and getting some interface code right. Still, for some application this would mean the world ;) I'd work on this while I'm in Seattle. Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99 _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF _www: http://www.informatik.uni-bremen.de/~malb _jab: martinralbre...@jabber.ccc.de --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: trac ticket width and hgrc tips?
2009/4/22 mabshoff :
>
>
>
> On Apr 22, 12:52 pm, Nick Alexander wrote:
>> >> To override this in Firefox on Linux, I put
>>
>> >> #content.ticket { width: 100% !important; }
>>
>> > Hmm, that seems to be a worthwhile change to me since these days most
>> > people should not be limited by 800x600 displays any more? Is anyone
>> > opposed to this change for some reason?
>>
>> +1.
>
> Hehe, if Nick likes it I think we are good to go :)
>
> For the record: I changed site-packages/Trac-0.11.3-py2.5.egg/trac/
> htdocs/css/ticket.css, but kept the orignial ticket.css as
> ticket.css.orig.
>
> For the last trac install we had also changed the color scheme for the
> diffs due to problems for people with red-green color blindness, so I
> will try to restore that fix today since I assume it is still desired,
Yes please -- much appreciated. I put in Pat's 100% width fix as soon
as I saw it and it's great: +1 from me.
John
> too.
>
>> Nick
>
> Cheers,
>
> Michael
> >
>
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Multivariate polynomial quotient ring
Hi, It seems that multivariate polynomial quotient rings are not in Sage yet. Is someone working to fill this gap? or should I rely on Singular or Magma interface? or should I attempt to implement my own toyish one? Give me an advice. Thank you. Kwankyu --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Apr 23, 1:22 am, Martin Albrecht wrote: > On Thursday 23 April 2009, mabshoff wrote: > > > Hello, Hi Martin, > > while there should be a quick 3.4.2 to mop up patches from trac before > > the big 4.0 jump today we had a planning session during the UW status > > meeting about the goals for Sage 4.0. The result is at > > > http://wiki.sagemath.org/plan/sage-4.0 > > > It still needs a little polish, i.e. the issues for Solaris as well as > > 64 bit OSX support need to be fleshed out, but the 75% coverage target > > has a lot of concrete projects and/or suggestions on what to attack. > > If anyone has some other suggestions for large projects that are > > doable in the next 3 weeks please let us know. > > I'd add: first class support for multivariate polynomials over rings (Z and > Z/nZ) to the list: this is basically equivalent to updating to Singular 3.1 > and getting some interface code right. Still, for some application this would > mean the world ;) > > I'd work on this while I'm in Seattle. Cool. William and I spend an evening on the current OSX 64 bit problem - see #5862. We fixed one issue that is caused by different dlopen behavior by explicitly using dlsym() to get siInit() since it wasn't executed at all on 64 bit OSX. But fixing that issue still does not fix the segfault at startup. What is happening is oMalloc not being properly initialized and going boom the first time a ring is instantiated. I tried compiling oMalloc's check target on OSX in 64 bit mode, but failed after only spending 5 minutes on the problem. Turning on debugging did not help for any of the oMalloc issues. It seems that the initialization for oMalloc mysteriously works for some releases while it is completely broken for other releases, so we need an oMalloc expert to fix this :). Reverting the fix GSW did for the mmap vs. sbrk problem did not revert the problem either, so I am fresh out of ideas :( > Martin Cheers, Michael > -- > name: Martin Albrecht > _pgp:http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99 > _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF > _www:http://www.informatik.uni-bremen.de/~malb > _jab: martinralbre...@jabber.ccc.de --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: google 3d browser api
On Apr 23, 1:04 am, Ondrej Certik wrote: > Hi, Hi, > I just discovered: > > http://code.google.com/apis/o3d/ > > watch the video there. I think this is awesome -- I hope sooner or > later all major browsers implement something like this, then it could > be used for all kinds of 3d interaction in the notebook. Yes, it looks pretty awesome and was mentioned in IRC the other day, but it requires either OpenGL or DirectX, so at least on Linux there seem to be plenty of driver issues in the past. That was the reason to pick JMOL as a software renderer since it tends to work (well, not 100%, but hopefully we will be getting there soon). > Ondrej Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Multivariate polynomial quotient ring
On Apr 23, 2009, at 1:29 AM, Kwankyu wrote: > Hi, > > It seems that multivariate polynomial quotient rings are not in Sage > yet. Is someone working to fill this gap? or should I rely on Singular > or Magma interface? or should I attempt to implement my own toyish > one? Give me an advice. Thank you. Actually, they are: sage: R. = QQ[] sage: S = R.quotient([x^3-x-y^2, z*x-1]); S Quotient of Multivariate Polynomial Ring in x, y, z over Rational Field by the ideal (x^3 - y^2 - x, x*z - 1) Singular is being used here. I don't think all rings are supported yet though. - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: google 3d browser api
On Apr 23, 2009, at 1:04 AM, Ondrej Certik wrote: > Hi, > > I just discovered: > > http://code.google.com/apis/o3d/ > > watch the video there. I think this is awesome -- I hope sooner or > later all major browsers implement something like this, then it could > be used for all kinds of 3d interaction in the notebook. This would be great. When I first started on the 3d stuff, I looked around for some kind of browser standard, and there wasn't one. (Not even close.) Time will tell, but hopefully this becomes one. Our framework works with jmol and tachyon, hopefully it'll be easy to add support for o3d as well (though I doubt I'll have time for such a project). - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Multivariate polynomial quotient ring
Hi Robert, Thank you. I just found examples in the reference using multivariate quotient rings. May I ask a similar question about hermite normal form of matrices over univariate polynomial ring? ^^ Kwankyu --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Final 3.4.1 source released
2009/4/22 mabshoff : > > > > On Apr 22, 12:54 pm, "David M. Monarres" wrote: > > Hi David, > >> On an upgrade from 3.4 on Mac OS X 10.5.6 (intel) I get the following >> doctest errors: > > Thanks for the build report. > >> The following tests failed: >> >> sage -t "devel/sage/sage/algebras/quaternion_algebra_element.py" >> sage -t "devel/sage/sage/schemes/elliptic_curves/ >> ell_rational_field.py" >> sage -t "devel/sage/sage/structure/sage_object.pyx" >> >> The errors are a bit long so here is a link to the test.log: >> >> http://www-rohan.sdsu.edu/~monarres/test.log > > The problems: > > sage -t "devel/sage/sage/schemes/elliptic_curves/ > ell_rational_field.py" > ** > File "/Users/ayeq/sage/devel/sage/sage/schemes/elliptic_curves/ > ell_rational_field.py", line 4941: >sage: P = G(E.0) + G(E.1) + G(phi(F.0)); P > Expected: >(-867/3872*a - 3615/3872 : -18003/170368*a - 374575/170368 : 1) > Got: >(-51/1058*a + 141/1058 : -1581/12167*a - 9912/12167 : 1) > ** > File "/Users/ayeq/sage/devel/sage/sage/schemes/elliptic_curves/ > ell_rational_field.py", line 4943: >sage: P.division_points(2) > Expected: >[(1/8*a + 5/8 : -5/16*a - 9/16 : 1)] > Got: >[(1/2*a - 1/2 : 1/2*a - 5/2 : 1)] > ** > File "/Users/ayeq/sage/devel/sage/sage/schemes/elliptic_curves/ > ell_rational_field.py", line 3185: >sage: E.cremona_label() > Expected: >Traceback (most recent call last): >... >RuntimeError: Cremona label not known for Elliptic Curve defined > by y^2 + x*y + 3*y = x^3 + 2*x^2 + 4*x + 5 over Rational Field. > Got: >'10351a1' > ** > > This is caused by you having some optional Cremona database installed > and it is #5346 which has a trivial fix suggested by John - someone > just has to put a patch up and unless someone beats me to it I will do > it tonight :) > > The other two failures are upgrade specific and happen when when left > over pyc and so files are around due to the Quaternion classes being > moved. One brutal fix is to do delete devel/sage* and to do a -ba. > The more fine tuned fix is to delete some py files and touch a couple > others followed by a -b, but I would need to look up the details. > I am fixing this. In fact all three only arise when the optional database is installed (reason: you then get generators for more curves from the database instead of computing them). I will post patch which addresses all three at #5346. John >> -- >> David Monarres >> dmmonar...@gmail.com > > Cheers, > > Michael > >> >> "There... I've run rings 'round you logically" >> -- Monty Python's Flying Circus >> >> On Apr 21, 2009, at 10:49 PM, mabshoff wrote: >> >> >> >> > Hello folks, >> >> > as expected changes over 3.4.1.rc4 are minimal: >> >> > Merged in Sage 3.4.1.final: >> >> > #5284: Michael Abshoff: Set sage-flags.txt up to SSE2 only when >> > building Sage in SSE2 only mode/remove SSSE3 and SSE4 flags (followup >> > to #5219) [Reviewed by Gonzalo Tornaria] >> > #5829: Minh Van Nguyen: copyright on standard documentation [Reviewed >> > by Dan Drake] >> >> > To build an SSE2 only binary do the following: >> >> >SAGE_SIMD_MODE=SSE2; export SAGE_SIMD_MODE >> >make >> >> > This will obviously have an impact on performance and I am afraid it >> > could be significant for certain problems. If anyone bothers to do two >> > builds please let us know. Good candidates for performance regressions >> > would be linear algebra, i.e. anything that involves ATLAS. >> >> > All the bits are as usual in >> >> > sage.math.washington.edu/home/mabshoff/release-cycles-3.4.1/ >> >> > I am building my 3.4.2.alpha0 merge tree and should merge in a couple >> > hours. Hopefully 3.4.2.alpha0 will drop tomorrow. >> >> > Cheers, >> >> > Michael > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Multivariate polynomial quotient ring
On Apr 23, 2009, at 1:51 AM, Kwankyu wrote: > Hi Robert, > > Thank you. I just found examples in the reference using multivariate > quotient rings. > > May I ask a similar question about hermite normal form of matrices > over univariate polynomial ring? ^^ Don't think it's implemented yet, but you could try it out. - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: 3.4.1 release tour updates
Hi folks, On Wed, Apr 22, 2009 at 5:09 PM, mabshoff wrote: > > Hi folks, > > it would be good if you contributed a feature to Sage 3.4.1 to check > the release tour at > > http://wiki.sagemath.org/sage-3.4.1 > > and edit what is there already in case it can be improved or add > something in case it is missing. Can someone please help me showcase the features of #5450? In particular, it would be good to have some images of 3-D plots that the ticket is meant to fix/add/feature. My net connection is pretty poor so I can't directly download Sage 3.4.1 or upgrade to it. For most features, I would just use sage.math. Doing a 3-D plot would give me a jmol object saved under the directory $HOME/.sage, but I can't figure out how to view 3-D plots using sage.math. -- Regards Minh Van Nguyen --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Final 3.4.1 source released
2009/4/23 John Cremona : > 2009/4/22 mabshoff : >> >> >> >> On Apr 22, 12:54 pm, "David M. Monarres" wrote: >> >> Hi David, >> >>> On an upgrade from 3.4 on Mac OS X 10.5.6 (intel) I get the following >>> doctest errors: >> >> Thanks for the build report. >> >>> The following tests failed: >>> >>> sage -t "devel/sage/sage/algebras/quaternion_algebra_element.py" >>> sage -t "devel/sage/sage/schemes/elliptic_curves/ >>> ell_rational_field.py" >>> sage -t "devel/sage/sage/structure/sage_object.pyx" >>> >>> The errors are a bit long so here is a link to the test.log: >>> >>> http://www-rohan.sdsu.edu/~monarres/test.log >> >> The problems: >> >> sage -t "devel/sage/sage/schemes/elliptic_curves/ >> ell_rational_field.py" >> ** >> File "/Users/ayeq/sage/devel/sage/sage/schemes/elliptic_curves/ >> ell_rational_field.py", line 4941: >>sage: P = G(E.0) + G(E.1) + G(phi(F.0)); P >> Expected: >>(-867/3872*a - 3615/3872 : -18003/170368*a - 374575/170368 : 1) >> Got: >>(-51/1058*a + 141/1058 : -1581/12167*a - 9912/12167 : 1) >> ** >> File "/Users/ayeq/sage/devel/sage/sage/schemes/elliptic_curves/ >> ell_rational_field.py", line 4943: >>sage: P.division_points(2) >> Expected: >>[(1/8*a + 5/8 : -5/16*a - 9/16 : 1)] >> Got: >>[(1/2*a - 1/2 : 1/2*a - 5/2 : 1)] >> ** >> File "/Users/ayeq/sage/devel/sage/sage/schemes/elliptic_curves/ >> ell_rational_field.py", line 3185: >>sage: E.cremona_label() >> Expected: >>Traceback (most recent call last): >>... >>RuntimeError: Cremona label not known for Elliptic Curve defined >> by y^2 + x*y + 3*y = x^3 + 2*x^2 + 4*x + 5 over Rational Field. >> Got: >>'10351a1' >> ** >> >> This is caused by you having some optional Cremona database installed >> and it is #5346 which has a trivial fix suggested by John - someone >> just has to put a patch up and unless someone beats me to it I will do >> it tonight :) >> >> The other two failures are upgrade specific and happen when when left >> over pyc and so files are around due to the Quaternion classes being >> moved. One brutal fix is to do delete devel/sage* and to do a -ba. >> The more fine tuned fix is to delete some py files and touch a couple >> others followed by a -b, but I would need to look up the details. >> > > I am fixing this. In fact all three only arise when the optional > database is installed (reason: you then get generators for more > curves from the database instead of computing them). I will post > patch which addresses all three at #5346. > Done and ready for review. > John > > >>> -- >>> David Monarres >>> dmmonar...@gmail.com >> >> Cheers, >> >> Michael >> >>> >>> "There... I've run rings 'round you logically" >>> -- Monty Python's Flying Circus >>> >>> On Apr 21, 2009, at 10:49 PM, mabshoff wrote: >>> >>> >>> >>> > Hello folks, >>> >>> > as expected changes over 3.4.1.rc4 are minimal: >>> >>> > Merged in Sage 3.4.1.final: >>> >>> > #5284: Michael Abshoff: Set sage-flags.txt up to SSE2 only when >>> > building Sage in SSE2 only mode/remove SSSE3 and SSE4 flags (followup >>> > to #5219) [Reviewed by Gonzalo Tornaria] >>> > #5829: Minh Van Nguyen: copyright on standard documentation [Reviewed >>> > by Dan Drake] >>> >>> > To build an SSE2 only binary do the following: >>> >>> >SAGE_SIMD_MODE=SSE2; export SAGE_SIMD_MODE >>> >make >>> >>> > This will obviously have an impact on performance and I am afraid it >>> > could be significant for certain problems. If anyone bothers to do two >>> > builds please let us know. Good candidates for performance regressions >>> > would be linear algebra, i.e. anything that involves ATLAS. >>> >>> > All the bits are as usual in >>> >>> > sage.math.washington.edu/home/mabshoff/release-cycles-3.4.1/ >>> >>> > I am building my 3.4.2.alpha0 merge tree and should merge in a couple >>> > hours. Hopefully 3.4.2.alpha0 will drop tomorrow. >>> >>> > Cheers, >>> >>> > Michael >> >> >> > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: feature request
Thanks Michael, I was really referring to multiprocessing, since their APIs are not the same and pyprocessing isn't supported anymore. Multiprocessing is maintained to be fully compatible with the 2.6 module to help with forward compatibility. So I guess the answer to my question is that Multiprocessing won't be in 3.4.1, right? That's fine I can always import it from an egg. Flávio On 22 abr, 17:25, mabshoff wrote: > On Apr 22, 8:09 am, William Stein wrote: > > > On Wed, Apr 22, 2009 at 6:10 AM,FlavioCoelho wrote: > > > > Hi, > > > > is it too late to include the multiprocessing package into sage > > > 3.4.1? > > > No, since we included it in Sage a year ago: > > While we ship pyprocessing we should really consider upgrading to > multiprocessing since once we update to Python 2.6 we can just drop > the spkg and it contains fixes not in pyprocessing, i.e. I could never > get pyprocessing to work on FreeBSD. > > > teragon:~ wstein$ sage > > -- > > | Sage Version 3.4.1, Release Date: 2009-04-21 | > > | Type notebook() for the GUI, and license() for information. | > > -- > > sage:import processing > > sage: > > > > There is a backport of it for python 2.5 in Pypi, which is maintained > > > by the author of the one which figures in the standard library from > > > 2.6 on. > > > > thanks, > > > > Flávio > > Cheers, > > Michael > > > -- > > William Stein > > Associate Professor of Mathematics > > University of Washingtonhttp://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Fwd: google 3d js api (open source)
Hello, this seems to be more than jmol... O3D is an open-source web API for creating rich, interactive 3D applications in the browser. This API is shared at an early stage as part of a conversation with the broader developer community about establishing an open web standard for 3D graphics. -- Forwarded message -- From: mdipierro Date: Wed, Apr 22, 2009 at 3:59 PM Subject: [web2py:20284] google 3d js api To: web2py Web Framework http://code.google.com/apis/o3d/ -- Jurgis Pralgauskis tel: 8-616 77613; jabber: jur...@akl.lt; skype: dz0rdzas; Don't worry, be happy and make things better ;) http://sagemath.visiems.lt --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
Hi Michael, probably you did. But just to be sure: did you really do tests with the singular spkg I put a while ago at http://sage.math.washington.edu/home/weberg/spkg/ ? There are quite some changes in it (ask me if you have specific questions), one or the other of which might possibly help. The oMalloc package also brings its own "testsuite", what are its results? The problem for me to work myself on this issue, is that I do have a MacIntel Core2Duo, but I haven't got OS X 10.5 available at all, and I do not intend to buy one, or to install it. (Waiting for 10.6 to come out.) And OS X 10.4 does not seem to be really "64-bit ready". Working remote might be a possibility, but I can't promise to spend much time on it. Cheers, gsw --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
mabshoff wrote: > Hello, > > while there should be a quick 3.4.2 to mop up patches from trac before > the big 4.0 jump today we had a planning session during the UW status > meeting about the goals for Sage 4.0. The result is at > >http://wiki.sagemath.org/plan/sage-4.0 > > It still needs a little polish, i.e. the issues for Solaris as well as > 64 bit OSX support need to be fleshed out, but the 75% coverage target > has a lot of concrete projects and/or suggestions on what to attack. > If anyone has some other suggestions for large projects that are > doable in the next 3 weeks please let us know. > > Cheers, > > Michael Hi Michael, As Sage on Solaris needs a custom tool chain, could a script be provided that builds that tool chain from a full (but fresh) installation of the latest version of Solaris, which is Solaris 10 update 6? In principle something like #!/bin/sh /usr/sfw/bin/wget http://www.somewhere.com/gcc-a.b.c.tar.gz /usr/sfw/bin/wget http://www.somewhere.com/gmake-e.g.g.tar.gz ... /usr/sfw/bin/gtar xf gcc-a.b.c.tar.gz To say "It builds on skynet" is not too helpful to people. Whereas you if you could say "Various versions of gcc, make, etc cause problems with Sage, but if you use this script on a fresh full installation of Solaris 10 update 6, you will have all the tools necessary." As far as I know (but are NOT 100% sure), a full install of Solaris 10 update 6 on SPARC includes * GNU tar (version 1.14) * gcc (version 3.4.3) * wget (version 1.10.2) * GNU make (version 3.80, under the name 'gmake') All those are in /usr/sfw/bin As it is necessary to build a later gcc, then I assume that will be one of the steps in the script. If building gcc needs to be done in two stages (i.e. build version 4.1 from 3.4.2, then use 4.1 to build 4.3), then that too could be scripted. Once someone has a suitable tool chain, they might have some hope of making a useful contribution on the rest of the Solaris issues. There is some advantage in being able to do this from source, rather than downloading packages from Sunfreware or similar, as you don't need root access to compile source code, but you do to install packages. Potentially someone at college will have access to Suns running Solaris, but most will not have root access. Dave --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Final 3.4.1 source released
The latest RC of MPIR 1.1.1 should fix this issue. Bill. On 23 Apr, 01:43, Bill Hart wrote: > Hi Marshall. I think I have a fix for this. But I've started a thread > on the MPIR development list for this: > > http://groups.google.co.uk/group/mpir-devel/browse_thread/thread/34a4... > > Bill. > > On 22 Apr, 23:31, Marshall Hampton wrote: > > > I am having an error in building 3.4.1 on an intel mac running 10.5. > > The error is in mpir: > > > Deleting assembly files which depend on PIC assembly working or 32 bit > > OSX on Intel hardware > > checking build system type... Invalid configuration `penryn-apple- > > darwin9.6.0': machine `penryn-apple' not recognized > > configure: error: /bin/sh ./config.sub penryn-apple-darwin9.6.0 failed > > Failed to configure. > > > The chip is an intel Core 2 Duo, 2.4 Ghz, on a Macbook. This was on a > > fresh source build, not an upgrade. > > > -M. Hampton > > > On Apr 22, 12:49 am, mabshoff wrote: > > > > Hello folks, > > > > as expected changes over 3.4.1.rc4 are minimal: > > > > Merged in Sage 3.4.1.final: > > > > #5284: Michael Abshoff: Set sage-flags.txt up to SSE2 only when > > > building Sage in SSE2 only mode/remove SSSE3 and SSE4 flags (followup > > > to #5219) [Reviewed by Gonzalo Tornaria] > > > #5829: Minh Van Nguyen: copyright on standard documentation [Reviewed > > > by Dan Drake] > > > > To build an SSE2 only binary do the following: > > > > SAGE_SIMD_MODE=SSE2; export SAGE_SIMD_MODE > > > make > > > > This will obviously have an impact on performance and I am afraid it > > > could be significant for certain problems. If anyone bothers to do two > > > builds please let us know. Good candidates for performance regressions > > > would be linear algebra, i.e. anything that involves ATLAS. > > > > All the bits are as usual in > > > > sage.math.washington.edu/home/mabshoff/release-cycles-3.4.1/ > > > > I am building my 3.4.2.alpha0 merge tree and should merge in a couple > > > hours. Hopefully 3.4.2.alpha0 will drop tomorrow. > > > > Cheers, > > > > Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
I'd like to add as a goal that Sage 4.0 works with versions of its dependencies available from the relevant upstreams. For context, I would very much like to be able to package Sage 4.0 for Debian once it comes out, since I find the current state of having Sage 3.0.5 from last July to be somewhat embarrassing. However, updating Sage in Debian is really difficult because most Sage releases use a version of at least one of its dependencies that could not reasonably be packaged for use both in Sage and outside of Sage. This has been a problem both for my efforts and for the people working on making Sage available in Fedora. I like that Sage has a development model where fixing a bug in Sage resulting from a dependency does not require waiting for an upstream release, since this helps keep progress moving quickly. However, I would find it incredibly helpful if every 3 or 6 months Sage did a release that worked with upstream releases of its dependencies. Those releases would then be packaged by distributions. This model is very similar to how a lot of projects do unstable development for N months before doing a stable release that can be shipped by distributions. It seems to me that major releases like Sage 4.0 would be good candidates for these. I want to be really clear that I'm not asking that Sage change its rapid development model of aggressively fixing bugs in its dependencies. I'm only requesting that Sage occasionally do a release that works with dependencies that are available from the relevant upstream developers. What do people think about this proposal? There are basically two pieces of work that would be involved in making Sage 4.0 use only upstream versions of dependencies. The first is upgrading CVS/SVN versions of dependencies to actual releases. I notice the Sage currently has an SVN version of jqueryui, an SVN version of matplotlib, and an SVN version of ghmm (to be fair, ghmm hasn't released is ages, so I don't blame Sage for that one. That said, they tell me they will be doing a release soon, and I bet we could convince that soon to be before Sage 4.0 releases). Can all of these be replaced with actual releases for Sage 4.0? The second is cleaning out ABI-changing patches that Sage has against its dependencies. For example, there's a Sage patch to NTL written by David Harvey that I submitted upstream. After a discussion between David Harvey and the NTL maintainer, upstream added a different API accomplishing the patch's goal in the 5.5 release. It would be great if Sage were converted to use NTL 5.5 and that new API for Sage 4.0. The long-term work related to doing this is quite small if the project submitted all of those patches upstream as they are committed to Sage. In my experience pushing Sage patches upstream so far, the original developers have generally been very helpful with these kinds of issues. So, I think it is feasible to do both of these things in the next 3 weeks if we start soon. -Tim Abbott On Wed, 22 Apr 2009, mabshoff wrote: > > Hello, > > while there should be a quick 3.4.2 to mop up patches from trac before > the big 4.0 jump today we had a planning session during the UW status > meeting about the goals for Sage 4.0. The result is at > >http://wiki.sagemath.org/plan/sage-4.0 > > It still needs a little polish, i.e. the issues for Solaris as well as > 64 bit OSX support need to be fleshed out, but the 75% coverage target > has a lot of concrete projects and/or suggestions on what to attack. > If anyone has some other suggestions for large projects that are > doable in the next 3 weeks please let us know. > > Cheers, > > Michael > > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
+1 from me as a good goal for 4.0. But I don't have a whole lot of experience with dealing with spkgs, and I'll be working on improving p-adics, so I probably won't be helping much. David 2009/4/23 Tim Abbott > > I'd like to add as a goal that Sage 4.0 works with versions of its > dependencies available from the relevant upstreams. > > For context, I would very much like to be able to package Sage 4.0 for > Debian once it comes out, since I find the current state of having Sage > 3.0.5 from last July to be somewhat embarrassing. However, updating Sage > in Debian is really difficult because most Sage releases use a version of > at least one of its dependencies that could not reasonably be packaged for > use both in Sage and outside of Sage. This has been a problem both for my > efforts and for the people working on making Sage available in Fedora. > > I like that Sage has a development model where fixing a bug in Sage > resulting from a dependency does not require waiting for an upstream > release, since this helps keep progress moving quickly. However, I would > find it incredibly helpful if every 3 or 6 months Sage did a release that > worked with upstream releases of its dependencies. Those releases would > then be packaged by distributions. This model is very similar to how a > lot of projects do unstable development for N months before doing a stable > release that can be shipped by distributions. It seems to me that major > releases like Sage 4.0 would be good candidates for these. > > I want to be really clear that I'm not asking that Sage change its rapid > development model of aggressively fixing bugs in its dependencies. I'm > only requesting that Sage occasionally do a release that works with > dependencies that are available from the relevant upstream developers. > > What do people think about this proposal? > > > There are basically two pieces of work that would be involved in making > Sage 4.0 use only upstream versions of dependencies. > > The first is upgrading CVS/SVN versions of dependencies to actual > releases. I notice the Sage currently has an SVN version of jqueryui, an > SVN version of matplotlib, and an SVN version of ghmm (to be fair, ghmm > hasn't released is ages, so I don't blame Sage for that one. That said, > they tell me they will be doing a release soon, and I bet we could > convince that soon to be before Sage 4.0 releases). Can all of these be > replaced with actual releases for Sage 4.0? > > The second is cleaning out ABI-changing patches that Sage has against its > dependencies. For example, there's a Sage patch to NTL written by David > Harvey that I submitted upstream. After a discussion between David Harvey > and the NTL maintainer, upstream added a different API accomplishing the > patch's goal in the 5.5 release. It would be great if Sage were converted > to use NTL 5.5 and that new API for Sage 4.0. The long-term work related > to doing this is quite small if the project submitted all of those patches > upstream as they are committed to Sage. > > In my experience pushing Sage patches upstream so far, the original > developers have generally been very helpful with these kinds of issues. > So, I think it is feasible to do both of these things in the next 3 weeks > if we start soon. > >-Tim Abbott > > On Wed, 22 Apr 2009, mabshoff wrote: > > > > > Hello, > > > > while there should be a quick 3.4.2 to mop up patches from trac before > > the big 4.0 jump today we had a planning session during the UW status > > meeting about the goals for Sage 4.0. The result is at > > > >http://wiki.sagemath.org/plan/sage-4.0 > > > > It still needs a little polish, i.e. the issues for Solaris as well as > > 64 bit OSX support need to be fleshed out, but the 75% coverage target > > has a lot of concrete projects and/or suggestions on what to attack. > > If anyone has some other suggestions for large projects that are > > doable in the next 3 weeks please let us know. > > > > Cheers, > > > > Michael > > > > > > > > > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Indefinite Integration [WAS: programming: define a new function]
Ondrej Certik wrote: > On Wed, Apr 22, 2009 at 2:53 PM, Maurizio wrote: >>> We managed to get one gsoc project that does the assumptions right, so >>> it may happen anyways over the summer, in fact I very much hope so. >>> >> How does assumptions affect this? If that's so important, you should >> probably get a lot of focus on that! But consider also PDE >> important ;) > > PDE's are of course important, also it's my main research thing, but > for sympy the assumptions are essential, because you cannot build a > more advanced symbolics without a good assumption system. I am > curious which approach Sage is going to use for this, since ginac > doesn't have any assumptions. Is there anyone working on an assumptions framework in Sage? On the one hand, you can work in certain domains in Sage (i.e., polynomials over QQ, etc.), so some of this need may be taken care of there. But for a more general framework (like declaring that x>0?) Hmmm...maybe we'll use sympy? :) Jason -- Jason Grout --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Thu, Apr 23, 2009 at 12:32 PM, David Roe wrote: > +1 from me as a good goal for 4.0. But I don't have a whole lot of > experience with dealing with spkgs, and I'll be working on improving > p-adics, so I probably won't be helping much. > David > > 2009/4/23 Tim Abbott >> >> I'd like to add as a goal that Sage 4.0 works with versions of its >> dependencies available from the relevant upstreams. >> >> For context, I would very much like to be able to package Sage 4.0 for >> Debian once it comes out, since I find the current state of having Sage >> 3.0.5 from last July to be somewhat embarrassing. However, updating Sage >> in Debian is really difficult because most Sage releases use a version of >> at least one of its dependencies that could not reasonably be packaged for >> use both in Sage and outside of Sage. This has been a problem both for my >> efforts and for the people working on making Sage available in Fedora. >> >> I like that Sage has a development model where fixing a bug in Sage >> resulting from a dependency does not require waiting for an upstream >> release, since this helps keep progress moving quickly. However, I would >> find it incredibly helpful if every 3 or 6 months Sage did a release that >> worked with upstream releases of its dependencies. Those releases would >> then be packaged by distributions. This model is very similar to how a >> lot of projects do unstable development for N months before doing a stable >> release that can be shipped by distributions. It seems to me that major >> releases like Sage 4.0 would be good candidates for these. >> >> I want to be really clear that I'm not asking that Sage change its rapid >> development model of aggressively fixing bugs in its dependencies. I'm >> only requesting that Sage occasionally do a release that works with >> dependencies that are available from the relevant upstream developers. >> >> What do people think about this proposal? -1 from me as a goal for 4.0, since we already have a very daunting challenge to accomplish the current goals for 4.0 in the timeframe we have set, unless of course you are volunteering to do all of the work :-). The proposal seems very reasonable post 4.0 though. - William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Indefinite Integration [WAS: programming: define a new function]
On Thu, Apr 23, 2009 at 12:51 PM, Jason Grout wrote: > > Ondrej Certik wrote: >> On Wed, Apr 22, 2009 at 2:53 PM, Maurizio wrote: We managed to get one gsoc project that does the assumptions right, so it may happen anyways over the summer, in fact I very much hope so. >>> How does assumptions affect this? If that's so important, you should >>> probably get a lot of focus on that! But consider also PDE >>> important ;) >> >> PDE's are of course important, also it's my main research thing, but >> for sympy the assumptions are essential, because you cannot build a >> more advanced symbolics without a good assumption system. I am >> curious which approach Sage is going to use for this, since ginac >> doesn't have any assumptions. Could you explain how assumptions are so important? Could you particularly address how they can (1) be so critically important, and yet (2) ginac doesn't have them. Incidentaly, to me they are particularly important in symbolic integration, which ginac doesn't do.Also, could you explain why the assumption system in Sympy needs to be rewritten -- in particular, what design decisions were suboptimal? -- William > > > Is there anyone working on an assumptions framework in Sage? On the one > hand, you can work in certain domains in Sage (i.e., polynomials over > QQ, etc.), so some of this need may be taken care of there. > > But for a more general framework (like declaring that x>0?) > Hmmm...maybe we'll use sympy? :) > > Jason > > -- > Jason Grout > > > > > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
2009/4/23 Tim Abbott : > > I'd like to add as a goal that Sage 4.0 works with versions of its > dependencies available from the relevant upstreams. > > For context, I would very much like to be able to package Sage 4.0 for > Debian once it comes out, since I find the current state of having Sage > 3.0.5 from last July to be somewhat embarrassing. However, updating Sage > in Debian is really difficult because most Sage releases use a version of > at least one of its dependencies that could not reasonably be packaged for > use both in Sage and outside of Sage. This has been a problem both for my > efforts and for the people working on making Sage available in Fedora. Tim, would it make sense to have a small "sage-source" debian package which depends on the (few) build tools required to build debian and which upon installation downloads sage, compiles it, and places it in a (debian specific) standard place in the system? Alternatively, the package actually comes with the full source code (better for places with apt caches or debian mirrors). I recall once upon a time there was a (similar idea) debian package for netscape, which would actually download it from netscape website and install it. Best, Gonzalo --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Indefinite Integration [WAS: programming: define a new function]
On Apr 23, 2009, at 4:07 PM, William Stein wrote: > > Could you explain how assumptions are so important? Could you > particularly address how they can (1) be so critically important, and > yet (2) ginac doesn't have them. Incidentaly, to me they are > particularly important in symbolic integration, which ginac doesn't > do.Also, could you explain why the assumption system in Sympy > needs to be rewritten -- in particular, what design decisions were > suboptimal? > > -- William > One place where I use assumptions regularly is with trig functions. If you have sin(n*pi) or cos(n*pi), stating the assumption that n is integer reduces the first to 0 and the second to alternating +1,-1. These crop up in modal analysis of physical systems regularly. I don't know if sympy's assumptions are suboptimal, since I haven't used sympy much, but I guess it is since they're planning on improvements. Cheers, Tim. --- Tim Lahey PhD Candidate, Systems Design Engineering University of Waterloo http://www.linkedin.com/in/timlahey --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: 3.4.1 release tour updates
Minh Nguyen wrote: > Hi folks, > > On Wed, Apr 22, 2009 at 5:09 PM, mabshoff wrote: >> Hi folks, >> >> it would be good if you contributed a feature to Sage 3.4.1 to check >> the release tour at >> >> http://wiki.sagemath.org/sage-3.4.1 >> >> and edit what is there already in case it can be improved or add >> something in case it is missing. > > Can someone please help me showcase the features of #5450? In > particular, it would be good to have some images of 3-D plots that the > ticket is meant to fix/add/feature. My net connection is pretty poor > so I can't directly download Sage 3.4.1 or upgrade to it. For most > features, I would just use sage.math. Doing a 3-D plot would give me a > jmol object saved under the directory $HOME/.sage, but I can't figure > out how to view 3-D plots using sage.math. > I think of that patch as more of a bugfix than a new feature, so i didn't think it was necessary to mention in the release notes. However, it should make the plotting quite a bit faster (you can plot lots of points in not very much time, but it's harder to plot lots of spheres). Maybe one of the best applications would be a 3d vector field, where you want to plot lots and lots of vectors very quickly. So maybe the plot_vector_field3d function would provide a good example (see http://trac.sagemath.org/sage_trac/ticket/2646). I've posted a picture there. Basically, that command (the last function defined in the comments on the ticket) should provide a lot more responsive picture than before, because it now plots line3d objects instead of full arrow objects. I've published an example here: http://sagenb.org/home/pub/474/ You can get the picture by clicking on the Get Image link next to the 3d plot after adjusting the angle to whatever you want. For what it's worth, that plot_vector_field3d at #2646 just needs some documentation, and then I think it's ready to go into Sage too. Jason -- Jason Grout --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: feature request
On Apr 23, 4:36 am, Flavio Coelho wrote: > Thanks Michael, Hi Flávio, > I was really referring to multiprocessing, since their APIs are not > the same and pyprocessing isn't supported anymore. Multiprocessing is > maintained to be fully compatible with the 2.6 module to help with > forward compatibility. > > So I guess the answer to my question is that Multiprocessing won't be > in 3.4.1, right? That's fine I can always import it from an egg. No, it won't be, but as mentioned earlier due to the drive to update to Python 2.6 I want to update to the backport so that once we switch to python 2.6 we can just drop the spkg. > Flávio Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Apr 23, 5:51 am, "Georg S. Weber" wrote: > Hi Michael, Hi Georg, > probably you did. But just to be sure: did you really do tests with > the singular spkg I put a while ago at > http://sage.math.washington.edu/home/weberg/spkg/ > ? I will take it for a spin. I am pretty sure we need to push these changes upstream. > There are quite some changes in it (ask me if you have specific > questions), one or the other of which might possibly help. The oMalloc > package also brings its own "testsuite", what are its results? The > problem for me to work myself on this issue, is that I do have a > MacIntel Core2Duo, but I haven't got OS X 10.5 available at all, and I > do not intend to buy one, or to install it. (Waiting for 10.6 to come > out.) And OS X 10.4 does not seem to be really "64-bit ready". Working > remote might be a possibility, but I can't promise to spend much time > on it. William can give you an account on a 10.5 box that is capable of building 64 bit binaries. It is indeed the main test box for us to do so. > Cheers, > gsw Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
Tim Abbott wrote: > > The first is upgrading CVS/SVN versions of dependencies to actual > releases. I notice the Sage currently has an SVN version of jqueryui, an > SVN version of matplotlib, and an SVN version of ghmm (to be fair, ghmm > hasn't released is ages, so I don't blame Sage for that one. That said, > they tell me they will be doing a release soon, and I bet we could > convince that soon to be before Sage 4.0 releases). Can all of these be > replaced with actual releases for Sage 4.0? Jqueryui can actually be updated to the latest release, which is later than the svn version shipping with Sage, so that shouldn't be a problem. Matplotlib should be releasing a new version Real Soon Now, and then can be upgraded. Currently, we use some features from SVN that are not available in the latest release (arrow drawing stuff). We also ship an SVN version of scipy. Before a couple of months ago, everyone did, though (I think even debian), since it hadn't had a release in a very long time. We should upgrade to the latest release of scipy now, though. Jason -- Jason Grout --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Indefinite Integration [WAS: programming: define a new function]
On Thu, Apr 23, 2009 at 1:17 PM, Tim Lahey wrote:
>
>
> On Apr 23, 2009, at 4:07 PM, William Stein wrote:
>
>>
>> Could you explain how assumptions are so important? Could you
We already discussed this many times on this list, just search the
archives. Without good assumptions, you cannot implement good
integration, good solvers, good simplification, nothing. Of course,
things like x+x is easy, but once you have for example
Integral(), sometimes you
can simplify it, sometimes not and this very much depends on the
assumptions for the constants. Or things like integrate(x**n, x).
>> particularly address how they can (1) be so critically important, and
>> yet (2) ginac doesn't have them. Incidentaly, to me they are
ginac doesn't have any assumptions and so ginac doesn't have any
advanced symbolic features.
Of course, if the only thing that you are going to use ginac for is
the core engine, then it should not matter much. But what I want from
a CAS is to be able to do advanced symbolic calculations with symbols,
so I need some way to tell it my assumptions about the symbols. Taking
everything as complex numbers will not simplify things in many cases.
>> particularly important in symbolic integration, which ginac doesn't
>> do. Also, could you explain why the assumption system in Sympy
>> needs to be rewritten -- in particular, what design decisions were
>> suboptimal?
Because we attach assumptions to symbols, e.g. you define
In [2]: x = Symbol("x", positive=True)
and then you work with that:
In [3]: sqrt(x**2)
Out[3]: x
In [4]: x = Symbol("x", negative=True)
In [5]: sqrt(x**2)
Out[5]: -x
In [6]: x = Symbol("x")
In [7]: sqrt(x**2)
Out[7]:
╱ 2
╲╱ x
But this approach is the wrong one, because then the core engine has
to take this into account and it slows things down. Our new system
will keep the assumptions external, and define methods to work with
them, like in mathematica, e.g. refine(). This should simplify the
core and then we should be able to speed it up.
>>
>> -- William
>>
>
> One place where I use assumptions regularly is with trig functions. If
> you have sin(n*pi) or cos(n*pi), stating the assumption that n is
> integer
> reduces the first to 0 and the second to alternating +1,-1. These crop
> up
> in modal analysis of physical systems regularly. I don't know
> if sympy's assumptions are suboptimal, since I haven't used sympy much,
> but I guess it is since they're planning on improvements.
Exactly, all kinds of these assumptions, that are necessary for
integration, simplifications, e.g. sometimes sqrt(x**2) reduces to x,
sometimes to -x, sometimes to neither.
Ondrej
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Apr 23, 6:23 am, "Dr. David Kirkby" wrote: > mabshoff wrote: > > Hello, > Hi Michael, Hi David, > As Sage on Solaris needs a custom tool chain, could a script be provided > that builds that tool chain from a full (but fresh) installation of the > latest version of Solaris, which is Solaris 10 update 6? Maybe, I don't know if it will happen in time for 4.0. But I have binary packages for the toolchain. > In principle something like > > #!/bin/sh > /usr/sfw/bin/wgethttp://www.somewhere.com/gcc-a.b.c.tar.gz > /usr/sfw/bin/wgethttp://www.somewhere.com/gmake-e.g.g.tar.gz > ... > /usr/sfw/bin/gtar xf gcc-a.b.c.tar.gz > > To say > > "It builds on skynet" > > is not too helpful to people. Well, it is helpful to the people who pay me and it will work on the T2000 we will be hosting the notebook on. > Whereas you if you could say "Various versions of gcc, make, etc cause > problems with Sage, but if you use this script on a fresh full > installation of Solaris 10 update 6, you will have all the tools > necessary." See http://wiki.sagemath.org/solaris/toolchain for details. > As far as I know (but are NOT 100% sure), a full install of Solaris 10 > update 6 on SPARC includes > > * GNU tar (version 1.14) > * gcc (version 3.4.3) > * wget (version 1.10.2) > * GNU make (version 3.80, under the name 'gmake') > > All those are in /usr/sfw/bin I know, they are too broken to build Sage reliably, especially the linker. We also don't support using g77 as a Fortran compiler at the moment, but we will again in the future. > As it is necessary to build a later gcc, then I assume that will be one > of the steps in the script. If building gcc needs to be done in two > stages (i.e. build version 4.1 from 3.4.2, then use 4.1 to build 4.3), > then that too could be scripted. > > Once someone has a suitable tool chain, they might have some hope of > making a useful contribution on the rest of the Solaris issues. OK. Not that for gcc 4.2.2 the gfortran creates completely broken code on Sparc, so the only toolchain I will be using is the one specified above since it is well tested by me. > There is some advantage in being able to do this from source, rather > than downloading packages from Sunfreware or similar, as you don't need > root access to compile source code, but you do to install packages. > Potentially someone at college will have access to Suns running Solaris, > but most will not have root access. Yes, I am not planning to put any energy on packaging Sage up for Sunfreware since I prefer building from source or using binaries delivered via tarball that work without the need to be root. > Dave Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Thu, Apr 23, 2009 at 1:50 PM, mabshoff wrote: > > > > On Apr 23, 6:23 am, "Dr. David Kirkby" > wrote: >> mabshoff wrote: >> > Hello, > > >> Hi Michael, > > Hi David, > >> As Sage on Solaris needs a custom tool chain, could a script be provided >> that builds that tool chain from a full (but fresh) installation of the >> latest version of Solaris, which is Solaris 10 update 6? > > Maybe, I don't know if it will happen in time for 4.0. But I have > binary packages for the toolchain. > >> In principle something like >> >> #!/bin/sh >> /usr/sfw/bin/wgethttp://www.somewhere.com/gcc-a.b.c.tar.gz >> /usr/sfw/bin/wgethttp://www.somewhere.com/gmake-e.g.g.tar.gz >> ... >> /usr/sfw/bin/gtar xf gcc-a.b.c.tar.gz >> >> To say >> >> "It builds on skynet" >> >> is not too helpful to people. > > Well, it is helpful to the people who pay me and it will work on the > T2000 we will be hosting the notebook on. > >> Whereas you if you could say "Various versions of gcc, make, etc cause >> problems with Sage, but if you use this script on a fresh full >> installation of Solaris 10 update 6, you will have all the tools >> necessary." > > See http://wiki.sagemath.org/solaris/toolchain for details. > >> As far as I know (but are NOT 100% sure), a full install of Solaris 10 >> update 6 on SPARC includes >> >> * GNU tar (version 1.14) >> * gcc (version 3.4.3) >> * wget (version 1.10.2) >> * GNU make (version 3.80, under the name 'gmake') >> >> All those are in /usr/sfw/bin > > I know, they are too broken to build Sage reliably, especially the > linker. We also don't support using g77 as a Fortran compiler at the > moment, but we will again in the future. > >> As it is necessary to build a later gcc, then I assume that will be one >> of the steps in the script. If building gcc needs to be done in two >> stages (i.e. build version 4.1 from 3.4.2, then use 4.1 to build 4.3), >> then that too could be scripted. >> >> Once someone has a suitable tool chain, they might have some hope of >> making a useful contribution on the rest of the Solaris issues. > > OK. Not that for gcc 4.2.2 the gfortran creates completely broken code > on Sparc, so the only toolchain I will be using is the one specified > above since it is well tested by me. I think for the near term we should provide a binary tarball of your toolchain. I just tried dumping it on a completely different sparc box, and it works well. william --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Apr 23, 12:57 pm, William Stein wrote: > On Thu, Apr 23, 2009 at 12:32 PM, David Roe wrote: Hi, > > +1 from me as a good goal for 4.0. But I don't have a whole lot of > > experience with dealing with spkgs, and I'll be working on improving > > p-adics, so I probably won't be helping much. > > David > > > 2009/4/23 Tim Abbott > > >> I'd like to add as a goal that Sage 4.0 works with versions of its > >> dependencies available from the relevant upstreams. > > >> For context, I would very much like to be able to package Sage 4.0 for > >> Debian once it comes out, since I find the current state of having Sage > >> 3.0.5 from last July to be somewhat embarrassing. However, updating Sage > >> in Debian is really difficult because most Sage releases use a version of > >> at least one of its dependencies that could not reasonably be packaged for > >> use both in Sage and outside of Sage. This has been a problem both for my > >> efforts and for the people working on making Sage available in Fedora. > > >> I like that Sage has a development model where fixing a bug in Sage > >> resulting from a dependency does not require waiting for an upstream > >> release, since this helps keep progress moving quickly. However, I would > >> find it incredibly helpful if every 3 or 6 months Sage did a release that > >> worked with upstream releases of its dependencies. Those releases would > >> then be packaged by distributions. This model is very similar to how a > >> lot of projects do unstable development for N months before doing a stable > >> release that can be shipped by distributions. It seems to me that major > >> releases like Sage 4.0 would be good candidates for these. > > >> I want to be really clear that I'm not asking that Sage change its rapid > >> development model of aggressively fixing bugs in its dependencies. I'm > >> only requesting that Sage occasionally do a release that works with > >> dependencies that are available from the relevant upstream developers. > > >> What do people think about this proposal? > > -1 from me as a goal for 4.0, since we already have a very daunting > challenge to accomplish the current goals for 4.0 in the timeframe we > have set, unless of course you are volunteering to do all of the work > :-). > > The proposal seems very reasonable post 4.0 though. I doubt this will ever happen. Soon for example we plan to switch to the svn version of pari which absolutely changes lots of things in Sage in non-backward compatible ways, so you cannot use the stable pari release with Sage any more. And given the timeframe the pari devs do releases this does not bode well for stable releases. Also: NTL releases maybe once a year, often less frequent, so the next time we change something in the interface there won't be a release for some time. While we will upgrade to NTL 5.5 soon I am not sure it will be there in time for Sage 4.0. The problem is that some upstream projects release slowly while others are fast and do a point release when we submit a bugfix. One such example is FLINT where I get an instant update when we fix something or complain about a bug (i.e. see FLINT 1.2.3, 1.2.4, 1.2.5 the last two weeks for build issues for example). I don't think there is any reasonable way to guarantee that Sage will ship clean upstream every 3 or 6 months. I am happy to try, but I don't want any rule since fixing a bug in Sage takes precedence over packaging concerns for me any day. Sorry. > - William Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Apr 23, 1:52 pm, William Stein wrote: > On Thu, Apr 23, 2009 at 1:50 PM, mabshoff wrote: > I think for the near term we should provide a binary tarball of your > toolchain. > I just tried dumping it on a completely different sparc box, and it works > well. They have been available since Sage 3.2.3 at http://sage.math.washington.edu/home/mabshoff/solaris-binaries/ And they "just" work since Solaris has excellent binary compatibility :) > william Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Thu, Apr 23, 2009 at 1:58 PM, mabshoff wrote: > > > > On Apr 23, 12:57 pm, William Stein wrote: >> On Thu, Apr 23, 2009 at 12:32 PM, David Roe wrote: > > Hi, > >> > +1 from me as a good goal for 4.0. But I don't have a whole lot of >> > experience with dealing with spkgs, and I'll be working on improving >> > p-adics, so I probably won't be helping much. >> > David >> >> > 2009/4/23 Tim Abbott >> >> >> I'd like to add as a goal that Sage 4.0 works with versions of its >> >> dependencies available from the relevant upstreams. >> >> >> For context, I would very much like to be able to package Sage 4.0 for >> >> Debian once it comes out, since I find the current state of having Sage >> >> 3.0.5 from last July to be somewhat embarrassing. However, updating Sage >> >> in Debian is really difficult because most Sage releases use a version of >> >> at least one of its dependencies that could not reasonably be packaged for >> >> use both in Sage and outside of Sage. This has been a problem both for my >> >> efforts and for the people working on making Sage available in Fedora. >> >> >> I like that Sage has a development model where fixing a bug in Sage >> >> resulting from a dependency does not require waiting for an upstream >> >> release, since this helps keep progress moving quickly. However, I would >> >> find it incredibly helpful if every 3 or 6 months Sage did a release that >> >> worked with upstream releases of its dependencies. Those releases would >> >> then be packaged by distributions. This model is very similar to how a >> >> lot of projects do unstable development for N months before doing a stable >> >> release that can be shipped by distributions. It seems to me that major >> >> releases like Sage 4.0 would be good candidates for these. >> >> >> I want to be really clear that I'm not asking that Sage change its rapid >> >> development model of aggressively fixing bugs in its dependencies. I'm >> >> only requesting that Sage occasionally do a release that works with >> >> dependencies that are available from the relevant upstream developers. >> >> >> What do people think about this proposal? >> >> -1 from me as a goal for 4.0, since we already have a very daunting >> challenge to accomplish the current goals for 4.0 in the timeframe we >> have set, unless of course you are volunteering to do all of the work >> :-). >> >> The proposal seems very reasonable post 4.0 though. > > I doubt this will ever happen. Soon for example we plan to switch to > the svn version of pari which absolutely changes lots of things in > Sage in non-backward compatible ways, so you cannot use the stable > pari release with Sage any more. And given the timeframe the pari devs > do releases this does not bode well for stable releases. > > Also: NTL releases maybe once a year, often less frequent, so the next > time we change something in the interface there won't be a release for > some time. While we will upgrade to NTL 5.5 soon I am not sure it will > be there in time for Sage 4.0. > > The problem is that some upstream projects release slowly while others > are fast and do a point release when we submit a bugfix. One such > example is FLINT where I get an instant update when we fix something > or complain about a bug (i.e. see FLINT 1.2.3, 1.2.4, 1.2.5 the last > two weeks for build issues for example). I don't think there is any > reasonable way to guarantee that Sage will ship clean upstream every 3 > or 6 months. I am happy to try, but I don't want any rule since fixing > a bug in Sage takes precedence over packaging concerns for me any day. > Sorry. I agree that it is laudable to aim for, but not something we should ever try to guarantee. It just doesn't make sense. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Apr 23, 2:04 pm, William Stein wrote: > On Thu, Apr 23, 2009 at 1:58 PM, mabshoff wrote: > > I doubt this will ever happen. Soon for example we plan to switch to > > the svn version of pari which absolutely changes lots of things in > > Sage in non-backward compatible ways, so you cannot use the stable > > pari release with Sage any more. And given the timeframe the pari devs > > do releases this does not bode well for stable releases. > > > Also: NTL releases maybe once a year, often less frequent, so the next > > time we change something in the interface there won't be a release for > > some time. While we will upgrade to NTL 5.5 soon I am not sure it will > > be there in time for Sage 4.0. > > > The problem is that some upstream projects release slowly while others > > are fast and do a point release when we submit a bugfix. One such > > example is FLINT where I get an instant update when we fix something > > or complain about a bug (i.e. see FLINT 1.2.3, 1.2.4, 1.2.5 the last > > two weeks for build issues for example). I don't think there is any > > reasonable way to guarantee that Sage will ship clean upstream every 3 > > or 6 months. I am happy to try, but I don't want any rule since fixing > > a bug in Sage takes precedence over packaging concerns for me any day. > > Sorry. > > I agree that it is laudable to aim for, but not something we should > ever try to guarantee. It just doesn't make sense. Another thing: In 3.4.1 we downgraded GAP to 4.4.10 from 4.4.12 that was upgraded in Sage 3.3 due to a significant number of bugs and issues in GAP 4.4.12. How would you deal with something like that in the packaged version of Sage? The whole point about shipping nearly every dependency in Sage was that we can do things like that because it is the only way Sage does work reliably and pass doctests. That does not really work too well with a distribution like Debain with tens of thousands of packages. While the number of packages depending on GAP are probably close to zero in Debian for something like NTL this might be an issue. Another problem is that often we have to put in fixes or use CVS for non-Linux builds and with the Windows port this will become even more extreme. So I truly don't see any reasonable hope we will ship clean upstream anytime soon. Obviously if it is clean upstream and fixes in patches in the spkg you can just ignore it. > William Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Apr 23, 5:51 am, "Georg S. Weber" wrote: > Hi Michael, Hi Georg, > probably you did. But just to be sure: did you really do tests with > the singular spkg I put a while ago at > http://sage.math.washington.edu/home/weberg/spkg/ > ? Your spkg + sage -b to rebuild the extensions blow up in exactly the same fashion as what is in Sage 3.4.1: bash-3.2$ ./sage -- | Sage Version 3.4.1.rc4, Release Date: 2009-04-19 | | Type notebook() for the GUI, and license() for information.| -- Memory manager stolen back Closing handle MPolynomialRing_generic.__init__ Doing: omAlloc0(sizeof(char*)*(len(self._names))) Done: omAlloc0(sizeof(char*)*(len(self._names))) Allocating ring ... Unhandled SIGSEGV: A segmentation fault occured in SAGE. This probably occured because a *compiled* component of SAGE has a bug in it (typically accessing invalid memory) or is not properly wrapped with _sig_on, _sig_off. You might want to run SAGE under gdb with 'sage -gdb' to debug this. SAGE will now terminate (sorry). The above messages should be clear once you look into multi_polynomial_libsingular.pyx. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] documentation issues
i have some questions and suggestion on the RestructuredText. I am a ReST-newbie and so maybe these things have been discussed before. * In one of my files i have a line "power_series = series". This produces the full docstring of series to appear twice in the documentation, once under series and once under power_series. How can I exclude the alias ? * Generally I am very happy with the outputs of the documentation using sphinx. But there are some improvement that one could think about. For instance I think there are too many different fonts used, that is a bit ugly. More importantly I think that the examples and the warnings are more emphasized than the actual command that is documented. Also the commands and not well-seperated. To someone who is not used, this might look confusing. Of course, I have absolutely no idea if this can be changed or not. * The docstrings become much longer now that we have to add additional empty lines. This is not very nice when using foo? or tab- completion in the notebook. Also the `` `` are annoying there. Is it not possible that the printing of the docstring there is simplified ? * Where do we put references to books and articles ? Within the function or the header of the file ? With [XY]_ ? * Accents again. I know that we should not put them in the py-files. Could we have a predefined |eacute| maybe ? Chris. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: documentation issues
chris wuthrich wrote: > > i have some questions and suggestion on the RestructuredText. I am a > ReST-newbie and so maybe these things have been discussed before. > > * In one of my files i have a line "power_series = series". This > produces the full docstring of series to appear twice in the > documentation, once under series and once under power_series. How can > I exclude the alias ? > > * Generally I am very happy with the outputs of the documentation > using sphinx. But there are some improvement that one could think > about. For instance I think there are too many different fonts used, > that is a bit ugly. More importantly I think that the examples and the > warnings are more emphasized than the actual command that is > documented. Also the commands and not well-seperated. To someone who > is not used, this might look confusing. Of course, I have absolutely > no idea if this can be changed or not. > > * The docstrings become much longer now that we have to add > additional empty lines. This is not very nice when using foo? or tab- > completion in the notebook. Also the `` `` are annoying there. Is it > not possible that the printing of the docstring there is simplified ? Soon we will have html documentation in the notebook, so this won't be an issue there. On a different note, can we change the background color of examples? In my opinion, that green is just a bit too strong. It's also hard to read the blue text in strings against the green background. (After playing with it for a while) I propose a soft light yellowish off-white color, like #f4. The syntax highlight colors stand out better, and the whole thing is easier to read. Plus, the barely-yellow color matches nicely with the blue-green of the titlebar, etc. Thanks, Jason --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: documentation issues
On Thu, Apr 23, 2009 at 7:03 PM, Jason Grout wrote: > > chris wuthrich wrote: >> >> i have some questions and suggestion on the RestructuredText. I am a >> ReST-newbie and so maybe these things have been discussed before. >> >> * In one of my files i have a line "power_series = series". This >> produces the full docstring of series to appear twice in the >> documentation, once under series and once under power_series. How can >> I exclude the alias ? >> >> * Generally I am very happy with the outputs of the documentation >> using sphinx. But there are some improvement that one could think >> about. For instance I think there are too many different fonts used, >> that is a bit ugly. More importantly I think that the examples and the >> warnings are more emphasized than the actual command that is >> documented. Also the commands and not well-seperated. To someone who >> is not used, this might look confusing. Of course, I have absolutely >> no idea if this can be changed or not. >> >> * The docstrings become much longer now that we have to add >> additional empty lines. This is not very nice when using foo? or tab- >> completion in the notebook. Also the `` `` are annoying there. Is it >> not possible that the printing of the docstring there is simplified ? > > Soon we will have html documentation in the notebook, so this won't be > an issue there. > > > On a different note, can we change the background color of examples? In > my opinion, that green is just a bit too strong. It's not green, it is grey, and I also really don't like it either. > It's also hard to read > the blue text in strings against the green background. (After playing > with it for a while) I propose a soft light yellowish off-white color, > like #f4. The syntax highlight colors stand out better, and the > whole thing is easier to read. Plus, the barely-yellow color matches > nicely with the blue-green of the titlebar, etc. A big +1 to that! William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: documentation issues
William Stein wrote: >> >> On a different note, can we change the background color of examples? In >> my opinion, that green is just a bit too strong. > > It's not green, it is grey, and I also really don't like it either. It's definitely a light green for me in firefox on ubuntu (it's color #EEFFCC, which you can see from the hex has a strong green component). The heading backgrounds are grey. But no matter, at least we agree it ought to be changed. > >> It's also hard to read >> the blue text in strings against the green background. (After playing >> with it for a while) I propose a soft light yellowish off-white color, >> like #f4. The syntax highlight colors stand out better, and the >> whole thing is easier to read. Plus, the barely-yellow color matches >> nicely with the blue-green of the titlebar, etc. > > A big +1 to that! Anyone know where the CSS file is? The color is set in a default.css file, but the only default.css files I see are in _static directories, which sounds like they are automatically generated somehow. Thanks, Jason --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: documentation issues
On Thu, Apr 23, 2009 at 9:19 PM, Jason Grout wrote: > Anyone know where the CSS file is? The color is set in a default.css > file, but the only default.css files I see are in _static directories, > which sounds like they are automatically generated somehow. It comes (originally) from src/sphinx/static/default.css in the sphinx spkg. (No, I don't know the right way to customize it.) Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: documentation issues
Carl Witty wrote: > On Thu, Apr 23, 2009 at 9:19 PM, Jason Grout > wrote: >> Anyone know where the CSS file is? The color is set in a default.css >> file, but the only default.css files I see are in _static directories, >> which sounds like they are automatically generated somehow. > > It comes (originally) from src/sphinx/static/default.css in the sphinx > spkg. (No, I don't know the right way to customize it.) > It looks like 0.6 is easy to theme: http://sphinx.pocoo.org/theming.html We are running 0.5.1. The current release is 0.6.1. Is anyone working on an upgrade? Should it be a drop-in replacement? Mike, you mentioned the autodoc in 0.6 will make some other things easier too. Jason --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: documentation issues
On Apr 23, 9:34 pm, Jason Grout wrote: > Carl Witty wrote: > > On Thu, Apr 23, 2009 at 9:19 PM, Jason Grout > > wrote: > >> Anyone know where the CSS file is? The color is set in a default.css > >> file, but the only default.css files I see are in _static directories, > >> which sounds like they are automatically generated somehow. > > > It comes (originally) from src/sphinx/static/default.css in the sphinx > > spkg. (No, I don't know the right way to customize it.) > > It looks like 0.6 is easy to theme:http://sphinx.pocoo.org/theming.html > > We are running 0.5.1. The current release is 0.6.1. Is anyone working > on an upgrade? Should it be a drop-in replacement? Mike, you mentioned > the autodoc in 0.6 will make some other things easier too. Mike mentioned the update to 0.6 should be easy, but he hadn't done it yet. But I think this should be doable in the 4.0 timeframe. > Jason Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Thu, 23 Apr 2009, Gonzalo Tornaria wrote: > would it make sense to have a small "sage-source" debian package which > depends on the (few) build tools required to build debian and which > upon installation downloads sage, compiles it, and places it in a > (debian specific) standard place in the system? Alternatively, the > package actually comes with the full source code (better for places > with apt caches or debian mirrors). I recall once upon a time there > was a (similar idea) debian package for netscape, which would actually > download it from netscape website and install it. I think the reason Netscape was done that way is actually because it wasn't free software, and so Debian wasn't willing to distribute it directly. In fact, Google suggests the Netscape package was just a script that downloaded the binaries from the website and then installed them. I think it would be hard to avoid violating Debian policy with such a package, and even if it did not, I suspect the Debian community would frown on such an arrangement for a piece of software in the main (free software) section of the archive. -Tim Abbott --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Thu, 23 Apr 2009, William Stein wrote: > >> What do people think about this proposal? > > -1 from me as a goal for 4.0, since we already have a very daunting > challenge to accomplish the current goals for 4.0 in the timeframe we > have set, unless of course you are volunteering to do all of the work > :-). Given how busy I am right now, I probably don't have time to do all of the work for this in the next 3 weeks. I will, however, attempt to determine the extent of the work needed with Sage 3.4.1 soon. > The proposal seems very reasonable post 4.0 though. Yeah, I'm mostly concerned about the long-term issues here. -Tim Abbott --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Thu, 23 Apr 2009, mabshoff wrote: > Another thing: In 3.4.1 we downgraded GAP to 4.4.10 from 4.4.12 that > was upgraded in Sage 3.3 due to a significant number of bugs and > issues in GAP 4.4.12. How would you deal with something like that in > the packaged version of Sage? The whole point about shipping nearly > every dependency in Sage was that we can do things like that because > it is the only way Sage does work reliably and pass doctests. That > does not really work too well with a distribution like Debain with > tens of thousands of packages. While the number of packages depending > on GAP are probably close to zero in Debian for something like NTL > this might be an issue. Actually, NTL wasn't in Debian until I packaged it as part of my effort to get Sage into Debian. So at present all its dependencies are maintained by me. But I understand your point -- GMP, for example, has dozens of dependencies. Upgrades of popular libraries in distributions like Debian are often done with a great deal of staging and care so that problems are discovered before people upgrade in the first place. As for the actual issue of downgrading packages, that can be difficult in a distribution. I have seen it done in Debian in cases where the new release is totally broken -- this is usually done by Debian releasing a version 4.4.12+really4.4.10 or similar. But perhaps instead the Debian maintainer will work with upstream to fix the bugs in the newer release. It's important to understand that distribution release cycles have relatively long freeze periods during which one only fixes bugs, which means one generally has quite a bit of warning when there is a problem that results in a doctest failure, and so one can explore a number of measures for trying to fix the issue before a release goes out. > Another problem is that often we have to put in fixes or use CVS for > non-Linux builds and with the Windows port this will become even more > extreme. So I truly don't see any reasonable hope we will ship clean > upstream anytime soon. Obviously if it is clean upstream and fixes in > patches in the spkg you can just ignore it. Fixes for non-Linux platforms like Solaris or Windows that don't change ABI should be fine in a stable release. There are a lot of Sage patches that add #ifdef CYGWIN ... #endif or similar that can be safely assumed on inspection to be harmless on Linux. If Sage only is applying patches like this, it is easy to just use the upstream release Sage is patching. That's why I stated the goal of cleaning out all ABI-changing patches, not cleaning out all patches altogether. -Tim Abbott --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Apr 23, 10:34 pm, Tim Abbott wrote: > On Thu, 23 Apr 2009, mabshoff wrote: Hi Tim, > > Another thing: In 3.4.1 we downgraded GAP to 4.4.10 from 4.4.12 that > > was upgraded in Sage 3.3 due to a significant number of bugs and > > issues in GAP 4.4.12. How would you deal with something like that in > > the packaged version of Sage? The whole point about shipping nearly > > every dependency in Sage was that we can do things like that because > > it is the only way Sage does work reliably and pass doctests. That > > does not really work too well with a distribution like Debain with > > tens of thousands of packages. While the number of packages depending > > on GAP are probably close to zero in Debian for something like NTL > > this might be an issue. > > Actually, NTL wasn't in Debian until I packaged it as part of my effort to > get Sage into Debian. So at present all its dependencies are maintained > by me. But I understand your point -- GMP, for example, has dozens of > dependencies. Upgrades of popular libraries in distributions like Debian > are often done with a great deal of staging and care so that problems are > discovered before people upgrade in the first place. Sure, NTL might not be the best example here, but say matplotlib. We did not update to an svn release to make life harder for you, but because we needed a patch that was upstreamed and not easily rebasable. I think all the issue can and will be sorted out in the near future after 4.0, but the update to pari-svn will happen. Indeed, it is a surprise that it did not already happen and quite a few bits in Debian outside Sage do use the pari library, i.e. clisp has an optional pari module for example. And there is really no way around that since the stable pari release is buggy in many ways and upstream has also recommended to use svn. Indeed, in a recent email Karim Belabas has actually called the stable pari "pari stale". I am quite supportive of getting all issues you have resolved, but it seems rather hard to get this fixed. I guess you could have a pari-2.3.4.deb (just like there are two different python.debs AFAIK). > As for the actual issue of downgrading packages, that can be difficult in > a distribution. I have seen it done in Debian in cases where the new > release is totally broken -- this is usually done by Debian releasing a > version 4.4.12+really4.4.10 or similar. But perhaps instead the Debian > maintainer will work with upstream to fix the bugs in the newer release. ok. > It's important to understand that distribution release cycles have > relatively long freeze periods during which one only fixes bugs, which > means one generally has quite a bit of warning when there is a problem > that results in a doctest failure, and so one can explore a number of > measures for trying to fix the issue before a release goes out. Sure, we complained, it wasn't fixed. There didn't really seem any compelling reason to have 4.4.12 over 4.4.10, so we downgraded awaiting upstream to fix the problem. > > Another problem is that often we have to put in fixes or use CVS for > > non-Linux builds and with the Windows port this will become even more > > extreme. So I truly don't see any reasonable hope we will ship clean > > upstream anytime soon. Obviously if it is clean upstream and fixes in > > patches in the spkg you can just ignore it. > > Fixes for non-Linux platforms like Solaris or Windows that don't change > ABI should be fine in a stable release. There are a lot of Sage patches > that add > > #ifdef CYGWIN > ... > #endif > > or similar that can be safely assumed on inspection to be harmless on > Linux. If Sage only is applying patches like this, it is easy to just use > the upstream release Sage is patching. That's why I stated the goal of > cleaning out all ABI-changing patches, not cleaning out all patches > altogether. Good. I am not against this, I am just pointing out the other side. > -Tim Abbott Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Thu, 23 Apr 2009, mabshoff wrote: > I doubt this will ever happen. Soon for example we plan to switch to > the svn version of pari which absolutely changes lots of things in > Sage in non-backward compatible ways, so you cannot use the stable > pari release with Sage any more. And given the timeframe the pari devs > do releases this does not bode well for stable releases. Well, how long after Sage switches to this version will it be before a stable pari release with these features comes out? If we're talking 3-6 months, this isn't a real problem. If Sage were going with doing regular stable releases, then it would make sense to talk to the pari developers before upgrading to the SVN version and get a commitment from them that they'll do a release with those features within the next 3-6 months. Obviously we have no control over the pari developers so we would not be able to obtain guarantees, but it seems worth trying to obtain them. This is probably a good example of the process I would use if I were managing the stable releases every 3-6 months. When discussion comes up of upgrading an .spkg to an SVN version, we send a quick note to upstream asking if they are likely to do a release with the features we need within the appropriate timescale. Similarly, when we add an ABI-changing patch against an upstream library, we should immediately send it upstream and ask whether they can commit to releasing with that functionality in the next 3 months. > Also: NTL releases maybe once a year, often less frequent, so the next > time we change something in the interface there won't be a release for > some time. While we will upgrade to NTL 5.5 soon I am not sure it will > be there in time for Sage 4.0. How often does Sage need to patch a rarely releasing project like NTL? As far as I'm aware, Sage has only had one ABI-changing patch against NTL since I started working on Sage in Debian in November 2007. Victor Shoup is a nice guy, I'm sure that we can convince him to do an extra release every couple years so that Sage can have its every-N-months major stable release work with a released version of NTL. > The problem is that some upstream projects release slowly while others > are fast and do a point release when we submit a bugfix. One such > example is FLINT where I get an instant update when we fix something or > complain about a bug (i.e. see FLINT 1.2.3, 1.2.4, 1.2.5 the last two > weeks for build issues for example). I don't think there is any > reasonable way to guarantee that Sage will ship clean upstream every 3 > or 6 months. I am happy to try, but I don't want any rule since fixing > a bug in Sage takes precedence over packaging concerns for me any day. > Sorry. Of course it will be the case that occasionally some upstream is really slow about releasing, and one has to just give up and move on. As Jason Grout points out, even Debian runs SVN versions sometimes when upstream is being really bad about releasing. But on the other side of this coin, I often find that when I contact a Sage upstream about a patch Sage has had against their software for several months that I want merged, they were completely unaware of the patch's existence. Maybe I've been unlucky in my sampling, but I get the sense that Sage development does not currently react to merging a new ABI-changing patch with "we should send this upstream ASAP". -Tim Abbott --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Thu, 23 Apr 2009, mabshoff wrote: > Sure, NTL might not be the best example here, but say matplotlib. We > did not update to an svn release to make life harder for you, but > because we needed a patch that was upstreamed and not easily > rebasable. I think all the issue can and will be sorted out in the > near future after 4.0, but the update to pari-svn will happen. Indeed, > it is a surprise that it did not already happen and quite a few bits > in Debian outside Sage do use the pari library, i.e. clisp has an > optional pari module for example. And there is really no way around > that since the stable pari release is buggy in many ways and upstream > has also recommended to use svn. Indeed, in a recent email Karim > Belabas has actually called the stable pari "pari stale". I am quite > supportive of getting all issues you have resolved, but it seems > rather hard to get this fixed. I guess you could have a pari-2.3.4.deb > (just like there are two different python.debs AFAIK). For libraries Debian often will have multiple versions that are available at a time in order to help with these transitions. It has been done with programs like pari when necessary -- you just have two versions of the pari package that conflict with each other. Generally something to be avoided if possible. It sounds possible that Pari has internal disagreements about releasing that might justify this sort of thing, but I'd need to learn more. -Tim Abbott --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0 release plan
On Apr 23, 10:57 pm, Tim Abbott wrote: > On Thu, 23 Apr 2009, mabshoff wrote: > > I doubt this will ever happen. Soon for example we plan to switch to > > the svn version of pari which absolutely changes lots of things in > > Sage in non-backward compatible ways, so you cannot use the stable > > pari release with Sage any more. And given the timeframe the pari devs > > do releases this does not bode well for stable releases. > > Well, how long after Sage switches to this version will it be before a > stable pari release with these features comes out? No clue, there are usually several years between stable pari releases and so far I don't think there has been anyone able to change their mind to have something more regular/often. > If we're talking 3-6 > months, this isn't a real problem. If Sage were going with doing regular > stable releases, then it would make sense to talk to the pari developers > before upgrading to the SVN version and get a commitment from them that > they'll do a release with those features within the next 3-6 months. > Obviously we have no control over the pari developers so we would not be > able to obtain guarantees, but it seems worth trying to obtain them. Well, we can try. But the whole point is that is someone posts a pari- svn.spkg which fixes bugs in functions Sage does not use and adds functionality that is asked for by people no one will be willing to wait 3 or 6 months to merge that. It might be more feasible to just package Sage before that change and then hope in the next couple months upstream will release. > This is probably a good example of the process I would use if I were > managing the stable releases every 3-6 months. When discussion comes up > of upgrading an .spkg to an SVN version, we send a quick note to upstream > asking if they are likely to do a release with the features we need within > the appropriate timescale. Similarly, when we add an ABI-changing patch > against an upstream library, we should immediately send it upstream and > ask whether they can commit to releasing with that functionality in the > next 3 months. > > > Also: NTL releases maybe once a year, often less frequent, so the next > > time we change something in the interface there won't be a release for > > some time. While we will upgrade to NTL 5.5 soon I am not sure it will > > be there in time for Sage 4.0. > > How often does Sage need to patch a rarely releasing project like NTL? > As far as I'm aware, Sage has only had one ABI-changing patch against NTL > since I started working on Sage in Debian in November 2007. Victor Shoup > is a nice guy, I'm sure that we can convince him to do an extra release > every couple years so that Sage can have its every-N-months major stable > release work with a released version of NTL. Well, you pushed patches upstream that contain GNUisms and I will end up patching it out of the sources again, so I am not too happy about that since upstream way too often does not understand that GNUisms are bad or are totally unaware of the problem in the first place. > > The problem is that some upstream projects release slowly while others > > are fast and do a point release when we submit a bugfix. One such > > example is FLINT where I get an instant update when we fix something or > > complain about a bug (i.e. see FLINT 1.2.3, 1.2.4, 1.2.5 the last two > > weeks for build issues for example). I don't think there is any > > reasonable way to guarantee that Sage will ship clean upstream every 3 > > or 6 months. I am happy to try, but I don't want any rule since fixing > > a bug in Sage takes precedence over packaging concerns for me any day. > > Sorry. > > Of course it will be the case that occasionally some upstream is really > slow about releasing, and one has to just give up and move on. As Jason > Grout points out, even Debian runs SVN versions sometimes when upstream is > being really bad about releasing. > > But on the other side of this coin, I often find that when I contact a > Sage upstream about a patch Sage has had against their software for > several months that I want merged, they were completely unaware of the > patch's existence. I don't know of any patch but the NTL one where this could be the case. We have contacted Victor Shoup several times to speak or visit a Sage days and he has *never* responded. The author of that patch works at NYU, i.e. the same place as Victor and if he never got around to get the patch merged than I can hardly call that our fault. Another author we have contacted via numerous people as well as multiple times is the cddlib author and he has also *never* responded to us. > Maybe I've been unlucky in my sampling, but I get the > sense that Sage development does not currently react to merging a new > ABI-changing patch with "we should send this upstream ASAP". I consider this completely wrong. Can you mention some concrete examples? > -Tim Abbott Cheers, Michael --~--~-~--~---
[sage-devel] Re: [ANN] sage-mode-0.5.3
On 21-Apr-09, at 5:11 PM, Nicolas M. Thiery wrote: > > Dear Nick, > > One more feature request for M-x rerun-sage > > More often than not when I rerun-sage, I am at an ipdb> prompt. > Currently the soft kill (which is much faster than the hard kill!) > does not work in that case. Could the soft kill try to sent twice > 'quit' to sage, so as to first quit from ipdb> and then from sage? Sure! In sage-build.el, find the line (comint-send-eof) (in defun rerun-sage ()) and repeat it a few times. I've folded this in but won't be cutting a new release until I have some more time or emacs frustrations. Nick --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [ANN] sage-mode-0.5.3
> Sure! In sage-build.el, find the line (comint-send-eof) (in defun > rerun-sage ()) and repeat it a few times. I've folded this in but > won't be cutting a new release until I have some more time or emacs > frustrations. Curious: this seems to make sage build and rerun hang on my machine. But it works interactively. I imagine I'm not polling for input correctly. Use with caution, sorry. Nick --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
