Re: [sage-devel] Re: Upstream projects
Dear Marteen, On Tue, Sep 06, 2011 at 03:17:38PM -0700, Maarten Derickx wrote: >On Tuesday, September 6, 2011 4:47:22 PM UTC+2, Nicolas M. ThiA(c)ry >wrote: > > Actually that post highlights quite well our motivations for switching > development model from a library on top of a system (as was > MuPAD-Combinat w.r.t. MuPAD) to a bunch of patches, most of whom are > intended to be eventually merged in the system (Sage-Combinat on top > of Sage). > >Interesting. For completeness, did the motivations turn out to be valid? >I.e. is the current model with staying more closely updated with sage more >workable then the situation with MuPad. I'm really interested to hear your >personal experiences on this front. As Florent often puts it: before switching, we were about to run hard into a wall. Now, we don't see a wall in front of us any more, but we are also going much faster :-) Seriously speaking: it's not as smooth as I would like it to be. We are making a much better work at creating and developping new patches (containing new features, bug fixes and refactorization) than at finalizing and reviewing them (and I take a good share of the blame on that). By consequence, the patches tend to accumulate in our queue beyond really reasonable. In particular, there are a bunch of patches about categories, morphisms, tutorials that overlap with the amazing job that Simon is currently doing, with increasing risks of conflicts. That being said, we still manage to get an average of 25 patches in Sage in every release, which is not so bad. Also, the more time passes, the more the patches are on the periphery rather than on the core features. Due to that, they tend to overlap and conflict less with each other, and with Sage ongoing development. So it is not as vital to get them merged swiftly. Cheers, Nicolas -- Nicolas M. Thiéry "Isil" http://Nicolas.Thiery.name/ -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Upstream projects
On Tuesday, September 6, 2011 4:47:22 PM UTC+2, Nicolas M. Thiéry wrote: > > Actually that post highlights quite well our motivations for switching > development model from a library on top of a system (as was > MuPAD-Combinat w.r.t. MuPAD) to a bunch of patches, most of whom are > intended to be eventually merged in the system (Sage-Combinat on top > of Sage). > > Interesting. For completeness, did the motivations turn out to be valid? I.e. is the current model with staying more closely updated with sage more workable then the situation with MuPad. I'm really interested to hear your personal experiences on this front. > Cheers, > Nicolas > -- > Nicolas M. Thi�ry "Isil" > http://Nicolas.Thiery.name/ > > -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Upstream projects
On Sun, Sep 04, 2011 at 03:09:31AM -0700, Maarten Derickx wrote: >I'm also curious for wich project sage is considered upstream, of course >there is psage but are there any others? Sage-Combinat? Actually that post highlights quite well our motivations for switching development model from a library on top of a system (as was MuPAD-Combinat w.r.t. MuPAD) to a bunch of patches, most of whom are intended to be eventually merged in the system (Sage-Combinat on top of Sage). Cheers, Nicolas -- Nicolas M. Thiéry "Isil" http://Nicolas.Thiery.name/ -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Upstream projects
On 5 Sep., 07:32, Julien Puydt wrote: > Le 05/09/2011 02:41, leif a crit : > > > One shouldn't upgrade packages just for the sake of higher version > > numbers in Sage though, and there are packages where upgrading is > > indeed non-trivial, because of functional changes in upstream, or a > > lot of changes made by Sage to its current version. > > I can't help but notice that last part of the sentence is part of Dave > Neary's point. :-) That wasn't unintential. (Meaning it isn't all perfect in Sage, or we partially do have such problems.) There are changes we make that are specific to Sage, i.e. won't have any chance to get into upstream. But there are also patches to work around deficiencies (at least in Sage's "current" versions) that are either fixed (not necessarily in the same way) in newer upstream versions, or could be reported or submitted upstream. And some fixes submitted upstream didn't get merged, also sometimes because upstream chose to solve things in an inappropriate or insufficient way. -leif -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Upstream projects
> On Mon, 2011-09-05 at 07:32 +0200, Julien Puydt wrote: > Python is up to version 3.2.2 which is incompatible with 2.7. > Plus, there is no standard for the language. It is clear that > Sage is losing ground on the upstream development path. What > happens when the python-based spkgs, such as SciPy, convert to > 3.x? The time will come when all published materials about > Python use 3.x syntax and semantics, at which point Sage will > no longer be programmed in "Python". It happened to many > languages (e.g. Fortran, C, Lisp, etc.). > > I don't believe that Python allows you to redefine standard > Python functions and it doesn't have a macro facility so neither > path used by Axiom is available for Sage. > > As pointed out in the article, the longer this continues, the > harder, more expensive, and more disruptive the changes will be. > I can talk about the python upgrade since I have basically took charge here. Sage is basically currently using python-2.6.4 with some patch. At the present stage, after some patch that I pushed we probably could safely go to 2.6.7. I am currently working on getting sage to python-2.7 and think of it as a first landing point on the way to python-3. For both python-2.7 and python-3 my opinion is that sage is now the main drag. All python dependencies of sage work under python-2.7. I cannot think from the top of my head of something that doesn't work with python-3, may be sage-latex... So, at the present time the big thing preventing us to move to a later python is sage itself. Once we managed to clean the stuff related to #9958 and #11139 we can start cleaning the stuff for python-3. There are a lot of get/set/delslice that look like dead/unfinished code to me. That would be a first step to python-3. I don't wish to expand too much on upgrading stuff. While we don't want to upgrade for the sake of upgrading on the other hand we don't want to get problem with rot. So keeping up to date should still be done on a regular basis unless there is a good reason not to. Francois This email may be confidential and subject to legal privilege, it may not reflect the views of the University of Canterbury, and it is not guaranteed to be virus free. If you are not an intended recipient, please notify the sender immediately and erase all copies of the message and any attachments. Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more information. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Upstream projects
On Monday, September 5, 2011 8:29:46 AM UTC+2, TimDaly wrote: > > I see Sage efforts to keep up with OS changes (e.g. Lion) and > package changes (e.g. Maxima) but I am unaware of any work > to keep up with Python. > There are plans to move to python 3.x somewhere in the future (at least I heard William and Robert Bradshaw discuss on the last bugdays when we should start thinking about switching). IIRC there hasn't been any work on changing to python3 because not all the things on wich sage depends work in python3 yet, once enough dependancy's work with python3 we will start switching. This will take a lot of effort tough. > I don't believe that Python allows you to redefine standard > Python functions and it doesn't have a macro facility so neither > path used by Axiom is available for Sage. > You can redefine any standard python function! Even to something witch is not a function. sage: len = "lol" sage: print len lol The only thing in python you cannot redefine are the keywords such as class, def, yield, return, etc. Even tough I'm pointing out that this is possible, this doesn't mean I'm a huge fan of doing this. And I don't think overwriting standard functions is the way to go when changing from python 2 to python 3. > As pointed out in the article, the longer this continues, the > harder, more expensive, and more disruptive the changes will be. > Yes, I think think the article was very usefull for making us more aware of the "dept" you create by not keeping up to date with upstream. > Tim Daly > > > -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Upstream projects
On Mon, 2011-09-05 at 07:32 +0200, Julien Puydt wrote: > Le 05/09/2011 02:41, leif a écrit : > > One shouldn't upgrade packages just for the sake of higher version > > numbers in Sage though, and there are packages where upgrading is > > indeed non-trivial, because of functional changes in upstream, or a > > lot of changes made by Sage to its current version. > > I can't help but notice that last part of the sentence is part of Dave > Neary's point. > > Snark on #sagemath > Tracking upstream changes and feeding back bug reports and fixes takes time. Axiom has only one upstream package (GCL) and it is a major step to upgrade but it is done on a reasonably regular basis. We are fortunate that Camm tests GCL's changes by, among other things, compiling Axiom, Maxima, and other large packages. The other advantage is that Common Lisp is a standard so it is reasonably clear whether the failure is GCL or Axiom. Historically Axiom was written in MacLisp, then LispVM, and then Common Lisp. Since I had expertise in all three of these languages I did a fair amount of the porting and rewriting to Common Lisp. I have to say that it was not easy. The key advantage of Common Lisp is that we could change LispVM functions into either Common Lisp functions or macros without changing the code everywhere. If the new function implemented the LispVM or MacLisp semantics properly everything else "just worked". I see Sage efforts to keep up with OS changes (e.g. Lion) and package changes (e.g. Maxima) but I am unaware of any work to keep up with Python. Python is up to version 3.2.2 which is incompatible with 2.7. Plus, there is no standard for the language. It is clear that Sage is losing ground on the upstream development path. What happens when the python-based spkgs, such as SciPy, convert to 3.x? The time will come when all published materials about Python use 3.x syntax and semantics, at which point Sage will no longer be programmed in "Python". It happened to many languages (e.g. Fortran, C, Lisp, etc.). I don't believe that Python allows you to redefine standard Python functions and it doesn't have a macro facility so neither path used by Axiom is available for Sage. As pointed out in the article, the longer this continues, the harder, more expensive, and more disruptive the changes will be. Tim Daly -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Upstream projects
Le 05/09/2011 02:41, leif a écrit : One shouldn't upgrade packages just for the sake of higher version numbers in Sage though, and there are packages where upgrading is indeed non-trivial, because of functional changes in upstream, or a lot of changes made by Sage to its current version. I can't help but notice that last part of the sentence is part of Dave Neary's point. Snark on #sagemath -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Upstream projects
On 4 Sep., 21:52, "Georg S. Weber" wrote: > nice post. Let's look at two absolute core components of Sage, the > versions of which shipped with the current Sage-4.7.1 release are > outdated: MPIR and Python. > > Regarding MPIR, the relations with upsteam are cordial, but > nevertheless Sage-4.7.1 still ships MPIR v1.2.2. > Of course work is ongoing for more than one and a half year now, > leading to trac #8664 (update to use MPIR v2.1.3 in Sage) waiting to > be integrated in Sage-4.7.2. But MPIR upstream has meanwhile released > quite a few versions newer than that, the current MPIR is v2.4.0 from > June 2011 --- three months ago (see http://www.mpir.org/). FWIW, on that ticket, we discovered at least three bugs in MPIR, and fixed them and/or reported them upstream such that they got fixed. (Also now nearly a year ago. We started with MPIR 2.1.1 IIRC.) There are other reasons, unrelated to upstream, that MPIR 2.1.x didn't get merged last year, when that version was current. (The ticket also depends on #5847 / GMP-ECM, where we also discovered an upstream bug, which didn't really get fixed upstream, i.e., they now apply an IMHO dumb work-around.) There's meanwhile a follow-up ticket, #11616, upgrading MPIR to 2.4.0 (or, as a fallback, 2.3.1). MPIR 2.5.0, originally planned to be released on September 1st, has been postponed for a month, in order to get more things into that release. There are a couple of other spkgs with outdated upstream versions, where for many it seems the main "problem" is that simply no-one attempts to upgrade them, i.e., lack of time or interest. One shouldn't upgrade packages just for the sake of higher version numbers in Sage though, and there are packages where upgrading is indeed non-trivial, because of functional changes in upstream, or a lot of changes made by Sage to its current version. -leif -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Upstream projects
On 4 Sep., 08:47, daly wrote: > The Cost of Going it Alone by Dave > Nearyhttp://blogs.gnome.org/bolsh/2011/09/01/the-cost-of-going-it-alone/ Yeah, nice post. Let's look at two absolute core components of Sage, the versions of which shipped with the current Sage-4.7.1 release are outdated: MPIR and Python. Regarding MPIR, the relations with upsteam are cordial, but nevertheless Sage-4.7.1 still ships MPIR v1.2.2. Of course work is ongoing for more than one and a half year now, leading to trac #8664 (update to use MPIR v2.1.3 in Sage) waiting to be integrated in Sage-4.7.2. But MPIR upstream has meanwhile released quite a few versions newer than that, the current MPIR is v2.4.0 from June 2011 --- three months ago (see http://www.mpir.org/ ). Regarding Python, that one "must-have" fix necessary for pickling is still open: http://bugs.python.org/issue7689 (this bug report was created in January 2010). "Downstream" the bugfix is applied (for Mandriva see http://lists.mandriva.com/bugs/2010-02/msg00501.php ; I don't have a pointer at hand for Sage-on-Gentoo) to Python, but there do not seem to be any close connections between the Sage project and "upstream" Python (the closest being indirectly via the Cython project, I guess). Which is a pity. Since the version shipped in Sage of Python is v2.6.4 (outdated for many months), and even if the upgrade to v2.7.x is being worked on (thanks to Francois Bissey and others, see http://trac.sagemath.org/sage_trac/ticket/9958 ), the upgrade to Python 3 might necessitate tighter developer interaction and eventually a fix or two to upstream (i.e. to Python 3) for Sage to work, which are more intrusive than the (still open, mind you) pickling issue7689 mentioned above. Are there any Python developers reading this (Sage) list? Cheers, Georg -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Upstream projects
On Sun, 04 Sep 2011 03:09:31 Maarten Derickx wrote: > Nice post. Altough it's really written from a commercial point of view, so > not everything is directly applicable to sage. > > Also I clearly feel how much work it takes to get, "a small fix" merged > upstream is very dependent on the particular upstream in question. In his > article he sais it's such a big amount effort that it's basically not worth > it. But my experience is that small fixes are most of the time not that hard > to get merged upstream. > > The article also made me wonder for wich sage packages we don't have sage > developers wich are also developers upstream. > > I'm also curious for wich project sage is considered upstream, of course > there is psage but are there any others? Well I consider sage to be upstream for sage-on-gentoo. The position of psage is more ambigous I think. My understanding is that psage is a lab for William to conduct experiments. So in some way it is downstream and some other it may be upstream. Historically small fixes haven't been too hard to get fixed in sage. But it depends on the part of sage and sometimes of the release manager. I am very involved in sage nowadays so a lot of applicable sage-on-gentoo stuff gets in. Francois This email may be confidential and subject to legal privilege, it may not reflect the views of the University of Canterbury, and it is not guaranteed to be virus free. If you are not an intended recipient, please notify the sender immediately and erase all copies of the message and any attachments. Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more information. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Upstream projects
Nice post. Altough it's really written from a commercial point of view, so not everything is directly applicable to sage. Also I clearly feel how much work it takes to get, "a small fix" merged upstream is very dependent on the particular upstream in question. In his article he sais it's such a big amount effort that it's basically not worth it. But my experience is that small fixes are most of the time not that hard to get merged upstream. The article also made me wonder for wich sage packages we don't have sage developers wich are also developers upstream. I'm also curious for wich project sage is considered upstream, of course there is psage but are there any others? -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
