[sage-devel] Re: Sage 4.0 release plan ; categories
Dear Craig, David, Mike, Robert:
Good news: I had not look at the unpickling issues outside of the
combinatorics code, thinking they would be similar to those in there,
that is fairly easy to handle. They actually turned out to be all
completely trivial: it's just that the basic categories (Rings/...)
were moved out of the category_types :-)
I should have used the debug = True of unpickle_all far earlier!
Adding a couple calls like:
register_unpickle_override('sage.categories.category', 'Sets', Sets)
did the trick (thanks Carl!). By the way, where in the Sage source
tree should I put those?
So now I do expect 100% doctest pass after the category patches
(though without the getattr hack). I'll confirm this later on when I
won't be draining my battery for this.
Cheers,
Nicolas
--
Nicolas M. Thiéry Isil nthi...@users.sf.net
http://Nicolas.Thiery.name/
--~--~-~--~~~---~--~~
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 ; categories
On Mon, May 25, 2009 at 7:06 PM, Nicolas M. Thiery
nicolas.thi...@u-psud.fr wrote:
Adding a couple calls like:
register_unpickle_override('sage.categories.category', 'Sets', Sets)
did the trick (thanks Carl!). By the way, where in the Sage source
tree should I put those?
Well, obviously we don't have a convention for this yet; but my
suggestion would be that if you rename sage.foo.X to sage.bar.Y, then
you put the register_unpickle_override just after the definition of
class Y in sage/bar.py .
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: Sage 4.0 release plan ; categories
Dear Craig, David, Mike, Robert: Thanks for this week of intensive work together! In the plane, I'll be working on updating the names of the categories (AbelianGroups - CommutativeAdditiveGroup, ...). I'll also give it a shot at the getattr alternative implementation (as we had discussed), so that you can focus on reviewing. Then, I'll be of for the week-end! Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ --~--~-~--~~~---~--~~ 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 ; categories
On Sat, May 23, 2009 at 06:19:35PM -0700, Nicolas Thiéry wrote: Dear Craig, David, Mike, Robert: On Sat, May 23, 2009 at 10:01:47AM -0700, Nicolas Thiéry wrote: I'll also give it a shot at the getattr alternative implementation (as we had discussed), so that you can focus on reviewing. Done for the second one: see categories-getattr_hack-nt.patch that I'll upload tonight to the sage-combinat patch server. IMHO, this is much hackier than inheriting dynamically from the element or parent_class of the category. I am really not a fan of using it, except when there are no other choices yet (extension types). So it's up to you to make it rock solid and optimized! I forgot to mention: the trick of setting __getattr__ in Sets().element_class (resp. Sets().parent_class) to avoid the double lookup does not work, because they are after Parent (resp. Element) in the mro. So we have to test in Parent.__getattr__ that the class of the object does not derive from Sets().parent_class (typically by testing that the class is not a dynamic class, which I do now). Or maybe we want to make sure that Sets().parent_class inherits from Parent (and idem for elements) Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ --~--~-~--~~~---~--~~ 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 ; categories
Dear Craig, David, Mike, Robert: On Sat, May 23, 2009 at 10:01:47AM -0700, Nicolas Thiéry wrote: I'll also give it a shot at the getattr alternative implementation (as we had discussed), so that you can focus on reviewing. Done for the second one: see categories-getattr_hack-nt.patch that I'll upload tonight to the sage-combinat patch server. IMHO, this is much hackier than inheriting dynamically from the element or parent_class of the category. I am really not a fan of using it, except when there are no other choices yet (extension types). So it's up to you to make it rock solid and optimized! Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ --~--~-~--~~~---~--~~ 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 ; categories
Dear Sage / Sage-Combinat developers, I am up and running, fresh and full of energy and hope. And I have a bold plan for getting the core of the category patch in by tomorrow, and the rest in 10 days. Carl, Craig, David, Mike, Robert (B): what about meeting at 3pm to build a consensus around this (or another) plan? Cheers, Nicolas -- This afternoon: - I finish all the renaming things we have discussed - Carl + Craig choose a parent (say SemiGroups().example()) and add a call to pickle_fix on it and on all its categories upon import time. Then disable cPickle-5986-nested-classes-submitted.patch, and check that pickling works. If yes, this means that in the worst case scenario, we can always fall back to this. Yet, I am now 100% convinced that want to avoid this if at all possible. So we do not pursue this way but rather finish reviewing: - cPickle-5986-nested-classes-submitted.patch By the way, they also review: - explain-pickle-v1.patch Or remove the trivial dependency on it. - Robert reviews: - parent-element_constructor-fix-5979-submitted.patch - 5598-coerce-declare.patch - categories-numberfield_homset-nt.patch - David reviews: - dynamic_class-5991-submitted.patch And implements the alternative getattr approach as we have discussed in a patch on top of categories-nt - Rob Beezer (it may need to be someone else!) reviews: - transitive_ideal-6000-submitted.patch - Early tonight, I cut categories-nt.patch into managable chunks. - The chunk about CombinatorialFreeModule get bumped for later This is the one who break code in sage.combinat. Without it, the tests should just fail in a couple of the categories (AlgebrasWithBasis, ...) which use CombinatorialFreeModule's in their examples. This won't break preexisting code, so we just add a temporary 'notest' to silence them. - We meet (for dinner?) and split the work of reviewing the chunks Tonight: - you guys review the chunks. You fix the trivial issues directly in little patches on the sage-combinat server. - I fold them progressively, and take care of the more serious issues to will certainly pop up. Hopefuly, by noon tomorrow we can get a positive review on all of those, and get the main category framework into sage. What remains is combinatorics-related, and we can manage the review process among Sage-Combinat developpers (but outside volunteers are of course very welcome to participate!). Tomorrow: - I review (after a quick discussion) Florent's patches: - family_enumset-fh.patch - enumset_unions-fh.patch - I work on cleaning up the free-modules chunk, and we prereview it. - Mike prereviews with me categories-symmetric_group_algebra-nt.patch - We run a discussion on later cleanups (morphisms, ...) Early next week: - I work with Jason and Mike (we will be at the same conference) to clean up the sf / ncsf patches. We cross review the result. Later this week: - I work with Davis' people, to streamline the root system patch, and we get it reviewed by Anne / Justin Once everything is ready (early the week later?): - We finish uploading everything on trac and set positive reviews. - Michael gets it in whenever he feels it fits well with the Sage release schedule -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ --~--~-~--~~~---~--~~ 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 ; categories
On May 20, 2009, at 2:08 PM, Nicolas M. Thiery wrote: Dear Sage / Sage-Combinat developers, I am up and running, fresh and full of energy and hope. And I have a bold plan for getting the core of the category patch in by tomorrow, and the rest in 10 days. Carl, Craig, David, Mike, Robert (B): what about meeting at 3pm to build a consensus around this (or another) plan? I won't be there by 3:00, but later this afternoon would be good. I would like to build this on top of a nearly-complete 4.0 to do some real testing and not have to do any more rebasing. - 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: Sage 4.0 release plan ; categories
I won't be there by 3:00, but later this afternoon would be good. Sounds good; I did not get food yet, and this is becoming urgent. Just setup a time, and I'll be there! I would like to build this on top of a nearly-complete 4.0 to do some real testing and not have to do any more rebasing. Yup. Which reminds me I should install sage 4 on my machine! Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ --~--~-~--~~~---~--~~ 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 ; categories
On May 20, 3:00 pm, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote: I won't be there by 3:00, but later this afternoon would be good. Sounds good; I did not get food yet, and this is becoming urgent. Just setup a time, and I'll be there! I would like to build this on top of a nearly-complete 4.0 to do some real testing and not have to do any more rebasing. Yup. Which reminds me I should install sage 4 on my machine! 4.0.rc0 should drop before the status report (I hope) since the new pynac is in, but extensive testing scared up some pexpect hangs and some cmp() failures (naughty, naughty, sage: cmp(m,3)\n 1 tsk, tsk - I have complained about this enough). Other than that (and I will do rc0 even without a fix there) my main thing is to fix the libfplll Solaris build issue. So far I had to catch up with $LIFE and run errands for most of yesterday and so far today, but I am done with that more or less before I fly back to Germany tomorrow. Cheers, Nicolas Cheers, Michael -- Nicolas M. Thiéry Isil nthi...@users.sf.nethttp://Nicolas.Thiery.name/ --~--~-~--~~~---~--~~ 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 ; categories
On May 20, 2009, at 3:00 PM, Nicolas M. Thiery wrote: I won't be there by 3:00, but later this afternoon would be good. Sounds good; I did not get food yet, and this is becoming urgent. Just setup a time, and I'll be there! I haven't eaten yet either, will head down to the SCC at 3:20. - 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: Sage 4.0 release plan ; categories
I am up and running, fresh and full of energy and hope. And I have a bold plan for getting the core of the category patch in by tomorrow, and the rest in 10 days. Oh and I forgot the most important part of the plan: once the core is in Sage, we should all go sea kayaking to rejoice about it. Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ --~--~-~--~~~---~--~~ 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 ; categories
On Thu, Apr 30, 2009 at 04:24:31PM -0700, mabshoff wrote: But please: *keep me updated about any such change as soon as possible* so as to limit conflicts. Every late conflict resolution just delays even further the final merge. Seehttp://trac.sagemath.org/sage_trac/ticket/5887 You can always grep for filenames in ~mabshoff/release-cycle-x.z.y/ [alphaX|rcX\final] to see which patches touch that code. It is just too long a list to have it in my mind to be 100% accurate. 50% acurracy is already helpful :-) And for little doc fixes (typos, ...): I would much prefer if they were just mentioned to me, and I would be glad to integrate them directly in my patches. I don't think anyone is fixing small things in patches like that, i.e. there are two big trends going on: There actually have been. But anyway, here I should just focus on getting the damn thing in, rather than how to maintain it longer. Thanks for the tips! and there are already known issues (pickling, cython, dynamic classes) that should have been sorted out a long time ago. Yup. I could have used more help. But we are all busy. Since you will be in Seattle a couple days before SD 15 you might want to book some time with RobertWB, Mike, William and me (and whoever else is interested) so that we can go over the patchset with you and have a clear roadmap to get this merged. This is the exact reason why I am coming :-) I hope to have precise dates by the 4-th of May, when I'll know if I need to fly back to France or not just after SD 15. As is I am doubtful that this patchset will make it into 4.0, but I am more than happy to target this for 4.1, i.e. the first big feature release after probably doing 4.0.1 to fix left over bugs only from 4.0. Good! Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ --~--~-~--~~~---~--~~ 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 ; categories
On Thu, Apr 30, 2009 at 04:12:00PM -0700, mabshoff wrote: On Apr 25, 8:39 am, Nicolas M. Thiery nicolas.thi...@u-psud.fr Before posting the patch to trac, I'll split it up into: - patch with all trivial import updates (the most invasive one) - main patch with the category framework (with updates to parents/morphism/...) and the categories themselves this one is hard to split further - patch updating about 10 existing sage classes with too many interdependencies to be updated later on (morphisms) - patches with applications (combinatorial free modules, sf, ...) But this is really to split the reviewing process by area of expertise. There are a lot of interdependencies, so I don't think we can apply only a subset and still maintain 100% positive tests. Sage probably won't even run without applying all three first patches. Yes, but then only those three patches should be on that ticket, i.e. the applications patch should be on another ticket. Sounds good to me. As is this patch set is approaching 0.5MB and that is never a good sign to have that much code to review. For the record: about 0.2MB are just taken by the standard GPL headers, since I created a lot of new files (one for each category: there are around 80 of them, most of them being currently rather trivial). Once the infrastructure is in merging the applications should not be time critical since collisions with code outside combinat should approach zero. Well, this probably will temporarily break a couple things in combinat. But it should be possible to handle this smoothly. Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ --~--~-~--~~~---~--~~ 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 ; categories
On Sat, Apr 25, 2009 at 08:50:50AM -0700, William Stein wrote: Just for the record, I hate when there is a looming patch over months of time whose main impact on Sage is to keep the rest of Sage from improving in quality. For example, with Bill Furnish working on symoblic for months, the main longterm impact on Sage was that nobody improved any of the calculus doctests. Definitely. But with developers being mostly volunteers with other time constraints this can't be completely avoided without preventing any large scale refactoring. And, as any young software, Sage need some of those. Two days ago I sat down to do some work on implementing general modules over a PID and decided to add some doctests to modules/*. I quickly found a *major* bug in categories/morphisms.py, and you better believe I fixed it and kept adding doctests. Great. I am glad you did! But please: *keep me updated about any such change as soon as possible* so as to limit conflicts. Every late conflict resolution just delays even further the final merge. And for little doc fixes (typos, ...): I would much prefer if they were just mentioned to me, and I would be glad to integrate them directly in my patches. Best, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ --~--~-~--~~~---~--~~ 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 ; categories
On Thu, Apr 30, 2009 at 11:46 AM, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote: On Sat, Apr 25, 2009 at 08:50:50AM -0700, William Stein wrote: Just for the record, I hate when there is a looming patch over months of time whose main impact on Sage is to keep the rest of Sage from improving in quality. For example, with Bill Furnish working on symoblic for months, the main longterm impact on Sage was that nobody improved any of the calculus doctests. Definitely. But with developers being mostly volunteers with other time constraints this can't be completely avoided without preventing any large scale refactoring. And, as any young software, Sage need some of those. You are right. In fact, there are a lot of things that I hate but which can't be avoided... -- William Two days ago I sat down to do some work on implementing general modules over a PID and decided to add some doctests to modules/*. I quickly found a *major* bug in categories/morphisms.py, and you better believe I fixed it and kept adding doctests. Great. I am glad you did! But please: *keep me updated about any such change as soon as possible* so as to limit conflicts. Every late conflict resolution just delays even further the final merge. See http://trac.sagemath.org/sage_trac/ticket/5887 And for little doc fixes (typos, ...): I would much prefer if they were just mentioned to me, and I would be glad to integrate them directly in my patches. Best, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ -- 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 ; categories
On Apr 25, 8:39 am, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote: SNIP Hi Nicolas, Before posting the patch to trac, I'll split it up into: - patch with all trivial import updates (the most invasive one) - main patch with the category framework (with updates to parents/morphism/...) and the categories themselves this one is hard to split further - patch updating about 10 existing sage classes with too many interdependencies to be updated later on (morphisms) - patches with applications (combinatorial free modules, sf, ...) But this is really to split the reviewing process by area of expertise. There are a lot of interdependencies, so I don't think we can apply only a subset and still maintain 100% positive tests. Sage probably won't even run without applying all three first patches. Yes, but then only those three patches should be on that ticket, i.e. the applications patch should be on another ticket. As is this patch set is approaching 0.5MB and that is never a good sign to have that much code to review. Once the infrastructure is in merging the applications should not be time critical since collisions with code outside combinat should approach zero. Cheers, Nicolas -- Cheers, Michael Nicolas M. Thiéry Isil nthi...@users.sf.nethttp://Nicolas.Thiery.name/ --~--~-~--~~~---~--~~ 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 ; categories
On Apr 30, 1:37 pm, William Stein wst...@gmail.com wrote: On Thu, Apr 30, 2009 at 11:46 AM, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote: Hi Nicolas, On Sat, Apr 25, 2009 at 08:50:50AM -0700, William Stein wrote: Just for the record, I hate when there is a looming patch over months of time whose main impact on Sage is to keep the rest of Sage from improving in quality. For example, with Bill Furnish working on symoblic for months, the main longterm impact on Sage was that nobody improved any of the calculus doctests. +1 - I think we learned a lesson from that I hope. Definitely. But with developers being mostly volunteers with other time constraints this can't be completely avoided without preventing any large scale refactoring. And, as any young software, Sage need some of those. Yes, but the patch series is unreviewed and there are already known issues (pickling, cython, dynamic classes) that should have been sorted out a long time ago. Since you will be in Seattle a couple days before SD 15 you might want to book some time with RobertWB, Mike, William and me (and whoever else is interested) so that we can go over the patchset with you and have a clear roadmap to get this merged. As is I am doubtful that this patchset will make it into 4.0, but I am more than happy to target this for 4.1, i.e. the first big feature release after probably doing 4.0.1 to fix left over bugs only from 4.0. You are right. In fact, there are a lot of things that I hate but which can't be avoided... Yep, there is no elegant way to deal with this. -- William Two days ago I sat down to do some work on implementing general modules over a PID and decided to add some doctests to modules/*. I quickly found a *major* bug in categories/morphisms.py, and you better believe I fixed it and kept adding doctests. Great. I am glad you did! But please: *keep me updated about any such change as soon as possible* so as to limit conflicts. Every late conflict resolution just delays even further the final merge. Seehttp://trac.sagemath.org/sage_trac/ticket/5887 You can always grep for filenames in ~mabshoff/release-cycle-x.z.y/ [alphaX|rcX\final] to see which patches touch that code. It is just too long a list to have it in my mind to be 100% accurate. And for little doc fixes (typos, ...): I would much prefer if they were just mentioned to me, and I would be glad to integrate them directly in my patches. I don't think anyone is fixing small things in patches like that, i.e. there are two big trends going on: * raise coverage * get files into the reference manual, i.e. ReSTification Both cause you pain only once, i.e. after that there shouldn't be any major changes to those files afterwards. Since we cannot effectively tell people what to work on (and there are also 100 patches in trac waiting for review, so there is already lots of code there that can cause conflicts) all I can give you is that once the patch is positively reviewed that it will be the first patch to go in into some alpha or rc release, i.e. that way you can rebase it once for a final time and it will break other patches potentially this time :). If you look at what has been happening in schemes, elliptic curves and so on in regard to coverage, bug fixing and ReSTification it has been a constant rebasing and fixing on top of merged patches since many people are working in this area. None of those patches were 500kb (some were quite large, i.e. 200kb or so), but none of them stayed unreviewed for a long time and was always quickly rebased once it had a positive review and I complained about rejects. Best, Nicolas Cheers, Michael -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ -- 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] Re: Sage 4.0 release plan ; categories
On Wed, Apr 22, 2009 at 06:24:38PM -0700, mabshoff wrote: 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 really would want to get the category code in Sage soon (4.0???): - Rebasing the patch after each Sage release is a real pain in the neck - The time frame where I can focus on working on this patch is closing (essentially it has to be done before June) - FPSAC is approaching - My coming to Seattle in a couple weeks is a perfect time to put some hard work on it - I am myself convinced that the patch is mature, and the remaining technical issues can be solved within a reasonable time frame (e.g. up to backward compatibility that just needs to be taken care of, pickling works). Now I need to convince you guys :-) To this end, I created http://sagetrac.org/sage_trac/ticket/5891, which includes a status report. This report also appears in the description header of the patch on the sage-combinat patch server, which I'll try to update on a regular basis. I also started to write a elements/parents/category primer, which I beta tested on the Sage developers in Davis. I will need your help! And to start with a review on #5120 :-) Also, if you really need to modify any of file listed below, please double check the patch and synchronize with me (most of the changes are trivial import updates). Michael: if you spot a patch doing so, please ping me. Cheers, Nicolas M sage/algebras/group_algebra.py M sage/algebras/steenrod_algebra.py M sage/categories/__init__.py M sage/categories/action.pyx M sage/categories/all.py M sage/categories/category.py M sage/categories/category_types.py M sage/categories/functor.pyx M sage/categories/homset.py M sage/categories/map.pyx M sage/categories/morphism.pyx M sage/categories/pushout.py M sage/combinat/combinatorial_algebra.py M sage/combinat/free_module.py M sage/combinat/permutation.py M sage/combinat/schubert_polynomial.py M sage/combinat/species/series.py M sage/combinat/symmetric_group_algebra.py M sage/groups/group.pyx M sage/groups/matrix_gps/homset.py M sage/groups/perm_gps/permgroup.py M sage/groups/perm_gps/permgroup_named.py M sage/matrix/matrix_space.py M sage/misc/misc.py M sage/modular/abvar/homspace.py M sage/modular/hecke/degenmap.py M sage/modular/hecke/hecke_operator.py M sage/modular/hecke/homspace.py M sage/modular/hecke/module.py M sage/modular/hecke/morphism.py M sage/modular/modsym/ambient.py M sage/modules/free_module.py M sage/modules/matrix_morphism.py M sage/modules/module.pyx M sage/probability/random_variable.py M sage/rings/homset.py M sage/rings/integer.pyx M sage/rings/morphism.pyx M sage/rings/residue_field.pyx M sage/rings/ring.pyx M sage/schemes/generic/homset.py M sage/schemes/generic/scheme.py M sage/schemes/generic/spec.py M sage/schemes/hyperelliptic_curves/kummer_surface.py M sage/sets/all.py M sage/sets/set.py M sage/structure/category_object.pyx M sage/structure/element.pyx M sage/structure/parent.pyx M sage/structure/parent_base.pyx M sage/structure/parent_gens.pyx M sage/structure/parent_old.pyx M sage/structure/wrapper_parent.pyx -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ --~--~-~--~~~---~--~~ 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 ; categories
On Apr 25, 12:13 am, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote: On Wed, Apr 22, 2009 at 06:24:38PM -0700, mabshoff wrote: Hi Nicolas, SNIP I really would want to get the category code in Sage soon (4.0???): At this stage I do believe you might have a hard time getting this into 4.0 given the time frame and the ToDo list, but we will see what happens :) - Rebasing the patch after each Sage release is a real pain in the neck Yeah, I can imagine. Is this patch splittable in any sane set of patches, i.e. for coercion the big patch bomb did not go in at once, but only the initial infrastructure, then later one by one classes were converted? If this is possible with this patch or is it all or nothing - The time frame where I can focus on working on this patch is closing (essentially it has to be done before June) - FPSAC is approaching - My coming to Seattle in a couple weeks is a perfect time to put some hard work on it - I am myself convinced that the patch is mature, and the remaining technical issues can be solved within a reasonable time frame (e.g. up to backward compatibility that just needs to be taken care of, pickling works). Now I need to convince you guys :-) To this end, I createdhttp://sagetrac.org/sage_trac/ticket/5891, which includes a status report. This report also appears in the description header of the patch on the sage-combinat patch server, which I'll try to update on a regular basis. I also started to write a elements/parents/category primer, which I beta tested on the Sage developers in Davis. I will need your help! And to start with a review on #5120 :-) Aren't there major design issues like dynamic classes to be discussed first? You mentioned a design document you were writing with Florent - is that around yet? The ToDo list also mentions that you are still working on having this work with Cython classes. Can you elaborate on that a little? Also, if you really need to modify any of file listed below, please double check the patch and synchronize with me (most of the changes are trivial import updates). Michael: if you spot a patch doing so, please ping me. Ok, but I am pretty sure due to many doctesting patches as well as work on ReSTifying documentation many patches will be touched. Cheers, Nicolas 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 ; categories
At this stage I do believe you might have a hard time getting this into 4.0 given the time frame and the ToDo list, but we will see what happens :) I let you pickup the best option. Aren't there major design issues like dynamic classes to be discussed first? You mentioned a design document you were writing with Florent - is that around yet? The discussions at MSRI were pretty useful, so from my point of view there just remains a couple minor design decisions. Of course, I definitely still need to make my point for the decision I have taken :-) This is the current main purpose of the primer (still a draft though). The ToDo list also mentions that you are still working on having this work with Cython classes. Can you elaborate on that a little? I guess 10 lines of code will be worth 10 pages of discussion. I'll try to write a proof of concept next week. Also, if you really need to modify any of file listed below, please double check the patch and synchronize with me (most of the changes are trivial import updates). Michael: if you spot a patch doing so, please ping me. Ok, but I am pretty sure due to many doctesting patches as well as work on ReSTifying documentation many patches will be touched. Precisely: do we really need to doctest right now things that are about to change soon? For example, the recent doctesting of sage/categories/morphisms.py made me loose quite some time. splitting of the patch bomb: Before posting the patch to trac, I'll split it up into: - patch with all trivial import updates (the most invasive one) - main patch with the category framework (with updates to parents/morphism/...) and the categories themselves this one is hard to split further - patch updating about 10 existing sage classes with too many interdependencies to be updated later on (morphisms) - patches with applications (combinatorial free modules, sf, ...) But this is really to split the reviewing process by area of expertise. There are a lot of interdependencies, so I don't think we can apply only a subset and still maintain 100% positive tests. Sage probably won't even run without applying all three first patches. Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ --~--~-~--~~~---~--~~ 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 ; categories
On Sat, Apr 25, 2009 at 8:39 AM, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote: At this stage I do believe you might have a hard time getting this into 4.0 given the time frame and the ToDo list, but we will see what happens :) I let you pickup the best option. Aren't there major design issues like dynamic classes to be discussed first? You mentioned a design document you were writing with Florent - is that around yet? The discussions at MSRI were pretty useful, so from my point of view there just remains a couple minor design decisions. Of course, I definitely still need to make my point for the decision I have taken :-) This is the current main purpose of the primer (still a draft though). The ToDo list also mentions that you are still working on having this work with Cython classes. Can you elaborate on that a little? I guess 10 lines of code will be worth 10 pages of discussion. I'll try to write a proof of concept next week. Also, if you really need to modify any of file listed below, please double check the patch and synchronize with me (most of the changes are trivial import updates). Michael: if you spot a patch doing so, please ping me. Ok, but I am pretty sure due to many doctesting patches as well as work on ReSTifying documentation many patches will be touched. Precisely: do we really need to doctest right now things that are about to change soon? For example, the recent doctesting of sage/categories/morphisms.py made me loose quite some time. Just for the record, I hate when there is a looming patch over months of time whose main impact on Sage is to keep the rest of Sage from improving in quality. For example, with Bill Furnish working on symoblic for months, the main longterm impact on Sage was that nobody improved any of the calculus doctests. Two days ago I sat down to do some work on implementing general modules over a PID and decided to add some doctests to modules/*. I quickly found a *major* bug in categories/morphisms.py, and you better believe I fixed it and kept adding doctests. So I'm against people not fixing and improving code, just because it is in your list. splitting of the patch bomb: Before posting the patch to trac, I'll split it up into: - patch with all trivial import updates (the most invasive one) - main patch with the category framework (with updates to parents/morphism/...) and the categories themselves this one is hard to split further - patch updating about 10 existing sage classes with too many interdependencies to be updated later on (morphisms) - patches with applications (combinatorial free modules, sf, ...) But this is really to split the reviewing process by area of expertise. There are a lot of interdependencies, so I don't think we can apply only a subset and still maintain 100% positive tests. Sage probably won't even run without applying all three first patches. Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ -- 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
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 tabb...@mit.edu 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 --~--~-~--~~~---~--~~ To post to this group, send
[sage-devel] Re: Sage 4.0 release plan
mabshoff wrote: On Apr 23, 6:23 am, Dr. David Kirkby david.kir...@onetel.net wrote: mabshoff wrote: Hello, SNIP 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. But it's pretty much irrelavent if 4.2.2 creates buggy fortan - I assume you have found at least one version which does not. But the point is, whatever method you use to create a tool chain could be scripted. I doubt that script would be that long either. --~--~-~--~~~---~--~~ 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 24, 12:19 am, Dr. David Kirkby david.kir...@onetel.net wrote: mabshoff wrote: SNIP Hi David, 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. But it's pretty much irrelavent if 4.2.2 creates buggy fortan No, it isn't. It took me considerable time to determine that certain doctest failures I saw were compiler issues where code was miscompiled. Right now there is only one toolchain that I will support when push comes to shove on Solaris and that is the one I provide. Other people are free to use whatever they want, but the people who pay me to work on Solaris want to use the latest stable gcc release, i.e. I will switch to gcc 4.4.0 soon. Over time hopefully we can get the SFW tools, other gcc releases and eventually Sun's tool suite to work, but given that I have plenty of other things to fix at the moment that just isn't high priority. By the way: That toolchain I use on an US IIIi today blew up with an internal compiler error on a T2000 (specifically gfortran). Since that machine isn't on SkyNet I will see if gcc 4.3.3 or 4.4.0 fixes the problem and otherwise open a ticket with the gcc folks. But it isn't a high priority item since I have to fix a number of bugs before the 4.0 deadline and I don't have any time for detours :). The sparc binary I produced works on that box, so we will be using that until further notice. - I assume you have found at least one version which does not. But the point is, whatever method you use to create a tool chain could be scripted. I doubt that script would be that long either. No it won't take long for a decent version. I have meant to so that for a while, but to get it working reliably and only with the SFW tools in $PATH will take some work. Since I will rebase my toolchain on gcc 4.4.0 in the next couple days I will see what I can do. In general I have posted 3.4.1 32 bit sparc and x86 tarballs that include the toolchain and should just work on any Solaris 10 build at http://www.sagemath.org/bin/solaris/index.html There are also the stand alone toolchains there in case anyone wants to build Sage, but note that the 3.4.1 binaries contain fixes not yet upstream, so build at least on Sparc will fail while Sympow won't work out of the box as is on x86. Let me know how they work in case anyone does play with them. All known problems are listed at http://wiki.sagemath.org/solaris and the issues that do not have tickets yet will get them in the next couple days. 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: 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. Right, I'm not suggesting Sage wait 3-6 months to merge exciting new code, but instead that one try to get upstream to agree to do a release with those features prior to the next one fo these stable releases. 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. Yes, there were a few early versions of patches to add shared library support written by Francois Bissey and myself that were merged by various upstream library maintainers and did have GNUisms. In more recent work, I've been encouraging upstream library maintainers to use libtool when adding shared library support. NTL is one example of a piece of software that is now doing this. I believe NTL 5.5 supports building a shared library with non-GNU make. If you have any problems with how NTL's shared library support was added, please let me know, as I'm thinking about sending patches replacing the early shared library support that has GNUisms with using libtool. 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. As I understand it, David Harvey isn't physically at NYU yet and nobody had mentioned the patch to Victor prior to my sending it to Victor. 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. The cddlib maintainer has responded to me three or four times, though generally very slowly. But a Fedora guy was unsuccessful in contacting him and ended up emailing me asking how to reach him. I consider this completely wrong. Can you mention some concrete examples? The ones that caused trouble for me are the NTL patch and the NullspaceMP function added to iml. It sounds like you are planning to work to avoid these types of problems in the future, which is all that's important to me 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, Jason Grout wrote: 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. If people have time to do these updates before the Sage 4.0 release, I would be grateful. -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 24, 2:27 pm, Tim Abbott tabb...@mit.edu wrote: On Thu, 23 Apr 2009, Jason Grout wrote: 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. If people have time to do these updates before the Sage 4.0 release, I would be grateful. -Tim Abbott On the issue of using pre-release versions of Sage dependencies, perhaps as a last resort we could ask Debian package maintainers to upload a SVN version to the experimental repository and a reasonably up-to-date version of Sage could be put into experimental while an older version of Sage goes into unstable and later testing whenever it is possible to sync a Sage release to officially versions of its dependencies? And people could get Sage from experimental if they need it. This would also make it possible for Ubuntu and other distros that cherry-pick from experimental to include Sage in their regular releases. The major issue that I can see is that maybe experimental contains a pre-release of gcc or something than an individual does not want but does want Sage from experimental. Perhaps that can be addressed with tight enough versioning of Sage's dependencies, even though Debian sort of frowns on that. Ben --~--~-~--~~~---~--~~ 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 24, 11:27 am, Tim Abbott tabb...@mit.edu wrote: Hi Tim, On Thu, 23 Apr 2009, Jason Grout wrote: 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. If people have time to do these updates before the Sage 4.0 release, I would be grateful. Well, the plan is to get everything up to date in or shortly after 4.0. Due to the time you have available it seems prudent to just get fixes in you find while looking at 4.0.x and to do subsequent releases without merging anything that isn't convenient to you. But that should happen quickly. -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 Apr 24, 2:12 pm, Ben Goodrich goodrich@gmail.com wrote: On Apr 24, 2:27 pm, Tim Abbott tabb...@mit.edu wrote: SNIP Hi Ben, On the issue of using pre-release versions of Sage dependencies, perhaps as a last resort we could ask Debian package maintainers to upload a SVN version to the experimental repository and a reasonably up-to-date version of Sage could be put into experimental while an older version of Sage goes into unstable and later testing whenever it is possible to sync a Sage release to officially versions of its dependencies? And people could get Sage from experimental if they need it. This would also make it possible for Ubuntu and other distros that cherry-pick from experimental to include Sage in their regular releases. The major issue that I can see is that maybe experimental contains a pre-release of gcc or something than an individual does not want but does want Sage from experimental. Perhaps that can be addressed with tight enough versioning of Sage's dependencies, even though Debian sort of frowns on that. Sure. In general anything in Debian stable one day will be woefully out of date by the time the freeze in Debian is over. I think the only viable option to use Sage in Debian is to use it from experimental/testing since any support request for say a year old version of Sage will likely start with the question Can someone reproduce this in the current release. Any patch from our end will only go in the next release unless we decide one day to do support some stable release for a while (and I am honestly not seeing that happening for a while). So having Ubuntu package Sage like in 9.04 and having that distro live for a year (assuming they had packaged something current) seems to be reasonable for the casual user who does not want to live on the bleeding edge of Sage. Ben 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 24, 11:26 am, Tim Abbott tabb...@mit.edu wrote: On Thu, 23 Apr 2009, mabshoff wrote: Hi Tim, SNIP 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. Yes, there were a few early versions of patches to add shared library support written by Francois Bissey and myself that were merged by various upstream library maintainers and did have GNUisms. In more recent work, I've been encouraging upstream library maintainers to use libtool when adding shared library support. Well, according to http://www.shoup.net/ntl/doc/tour-unix.html#shared If you set SHARED=on, then behind the scenes, the procedure used by the makefile changes a bit. In particular, the magical GNU program libtool is used to deal with all idiosyncracies of shared libraries. You may need to set the configuration variable LIBTOOL, to point to another version of libtool. For example, on Mac OSX, the built-in command called libtool is not actually the GNU libtool program; in this case, you will want to set LIBTOOL=glibtool. On other systems, it may be necssary to downlaod and install a fresh copy of the libtool program (which can be obtained from here). Note that if SHARED=on, then in addition to using the libtool program, the makefile relies on features specific to GNU make. Is that correct or are the GNUisms Victor's fault? NTL is one example of a piece of software that is now doing this. I believe NTL 5.5 supports building a shared library with non-GNU make. If you have any problems with how NTL's shared library support was added, please let me know, as I'm thinking about sending patches replacing the early shared library support that has GNUisms with using libtool. Ok. I am specifically thinking of your patch to zn_poly as well as polybori where your patch broke the linking on OSX 10.4 for example. 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. As I understand it, David Harvey isn't physically at NYU yet and nobody had mentioned the patch to Victor prior to my sending it to Victor. Ok. 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. The cddlib maintainer has responded to me three or four times, though generally very slowly. But a Fedora guy was unsuccessful in contacting him and ended up emailing me asking how to reach him. Ok, if you contact upstream about anything Sage related please CC me and William in the future. If the person responds only to you which happens frequently with people being unaware there is a reply-all please either forward the email to me and William or CC me on the reply again. I consider this completely wrong. Can you mention some concrete examples? The ones that caused trouble for me are the NTL patch and the NullspaceMP function added to iml. There is a new upstream-ish release of IML whcih should have this code. It sounds like you are planning to work to avoid these types of problems in the future, which is all that's important to me here. Yes, you just ended up with the patches that fell through the cracks :) My time is limited and if I have written a couple email to upstream and I never got any feedback at all I am just dropping the issue since I have plenty of other things to do. -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 Apr 24, 5:20 pm, mabshoff mabsh...@googlemail.com wrote: On Apr 24, 2:12 pm, Ben Goodrich goodrich@gmail.com wrote: On Apr 24, 2:27 pm, Tim Abbott tabb...@mit.edu wrote: SNIP Hi Ben, On the issue of using pre-release versions of Sage dependencies, perhaps as a last resort we could ask Debian package maintainers to upload a SVN version to the experimental repository and a reasonably up-to-date version of Sage could be put into experimental while an older version of Sage goes into unstable and later testing whenever it is possible to sync a Sage release to officially versions of its dependencies? And people could get Sage from experimental if they need it. This would also make it possible for Ubuntu and other distros that cherry-pick from experimental to include Sage in their regular releases. The major issue that I can see is that maybe experimental contains a pre-release of gcc or something than an individual does not want but does want Sage from experimental. Perhaps that can be addressed with tight enough versioning of Sage's dependencies, even though Debian sort of frowns on that. Sure. In general anything in Debian stable one day will be woefully out of date by the time the freeze in Debian is over. I think the only viable option to use Sage in Debian is to use it from experimental/testing since any support request for say a year old version of Sage will likely start with the question Can someone reproduce this in the current release. Any patch from our end will only go in the next release unless we decide one day to do support some stable release for a while (and I am honestly not seeing that happening for a while). So having Ubuntu package Sage like in 9.04 and having that distro live for a year (assuming they had packaged something current) seems to be reasonable for the casual user who does not want to live on the bleeding edge of Sage. Ben Cheers, Michael Right, anyone (mostly servers) using Debian stable or oldstable is not going to be able to keep up with Sage easily. But what I think Tim is saying is that he can't easily get a recent version of Sage into unstable (and subsequently testing) because unstable and especially testing usually have official releases of things Sage depends on. So, I was just suggesting that we could perhaps convince Debian maintainers of Sage dependencies to put pre-release versions into experimental, in addition to the official versions they maintain for unstable / testing. This would be annoying for them but maybe they would do it if we asked nicely. Then, Tim can get Sage 4.x into experimental when it is convenient for him, while Sage 3.0.x stays in unstable and testing until there is a window to sync some relatively recent version of Sage with 100% officially released dependencies. Experimental, more so than unstable, does tend to have pre-releases of packages. Ben --~--~-~--~~~---~--~~ 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 24, 2:26 pm, Tim Abbott tabb...@mit.edu wrote: As I understand it, David Harvey isn't physically at NYU yet and nobody had mentioned the patch to Victor prior to my sending it to Victor. Actually, I've been physically at NYU since last July, i.e. almost a year. But Victor has been away on sabbatical, I haven't even met him face-to-face yet. david --~--~-~--~~~---~--~~ 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 24, 2:50 pm, Ben Goodrich goodrich@gmail.com wrote: SNIP Hi Ben, Right, anyone (mostly servers) using Debian stable or oldstable is not going to be able to keep up with Sage easily. Agreed, but I think you misjudge the number of people running Debian stable on non-server scenarios. It is also quite common I believe to run a Sage server on distributions which aren't targeted at the desktop. Half a decade ago when there was no Ubuntu this kind of setup (without Sage obviously) was quite common, but these days with Ubuntu and their normal supported life cycle of a year this is less pressing. But I think there is still a significant number of Debian 4 users out there who are only slowly upgrading to Debian 5. When you analyze the download numbers the most prominent Linux version is the 32 bit Ubuntu binary which did surprise me initially since I assumed people would be running 64 bit linux everywhere. The second most popular download for linux was the 32 bit Debian binary, so there is definitely demand for Sage on Ubuntu as well as Debian. But what I think Tim is saying is that he can't easily get a recent version of Sage into unstable (and subsequently testing) because unstable and especially testing usually have official releases of things Sage depends on. Yes, I understand that. So, I was just suggesting that we could perhaps convince Debian maintainers of Sage dependencies to put pre-release versions into experimental, in addition to the official versions they maintain for unstable / testing. This would be annoying for them but maybe they would do it if we asked nicely. Then, Tim can get Sage 4.x into experimental when it is convenient for him, while Sage 3.0.x stays in unstable and testing until there is a window to sync some relatively recent version of Sage with 100% officially released dependencies. Absolutely. Looking at my time table I don't think 100% of the issues will be resolved in 4.0, but we can work with Tim to get it all sorted out in subsequent bug fix releases 4.0.x before going after the pari- svn update for example. So the following packages need to be sorted out: * numpy to 1.3 * scipy to 0.7 (maybe 0.7.1 if it is out by then) * NTL to 5.5 * jquery * matplotlib (I know they have been talking about doing a release and I believe they have a bugfix for the rare (libpng is size zero issue, but I am unclear when they will release) Is there anything else? Experimental, more so than unstable, does tend to have pre-releases of packages. Ben 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 24, 3:07 pm, David Harvey dmhar...@cims.nyu.edu wrote: On Apr 24, 2:26 pm, Tim Abbott tabb...@mit.edu wrote: Hi David, As I understand it, David Harvey isn't physically at NYU yet and nobody had mentioned the patch to Victor prior to my sending it to Victor. Actually, I've been physically at NYU since last July, i.e. almost a year. But Victor has been away on sabbatical, I haven't even met him face-to-face yet. Yeah, I knew about the sabbatical of Victor and you being at NYU already and I think we talked about this at SD 10. I am not blaming you by any means, I just wanted to point out that it takes a substantial amount of determination and/or luck to get an email back from Victor it seems ;) david 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 24, 3:09 pm, mabshoff mabsh...@googlemail.com wrote: On Apr 24, 2:50 pm, Ben Goodrich goodrich@gmail.com wrote: SNIP So the following packages need to be sorted out: * numpy to 1.3 * scipy to 0.7 (maybe 0.7.1 if it is out by then) * NTL to 5.5 * jquery * matplotlib (I know they have been talking about doing a release and I believe they have a bugfix for the rare (libpng is size zero issue, but I am unclear when they will release) Is there anything else? Oops, forgot to mention IML. I have stuffed all this at http://wiki.sagemath.org/debian/sage-4.0.x-in-experimental and I think any info from Tim I missed or he will discover in the future should be added there. I will add ticket link for existing spkg updates and open tickets for the issues that are not in trac yet. 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 Fri, 24 Apr 2009, mabshoff wrote: Is that correct or are the GNUisms Victor's fault? I would assume that is correct. I didn't actually write any of the code for NTL 5.5; Victor did all the work there. That said, I thought his intention was to not require GNU make as he mentioned it as one of his goals when discussing with me; I guess that was only important when SHARED=off. Looking at the code there just seems to be one GNUism in the makefile: $(OBJ:.o=.lo). This is probably removable with a bit of work. One could fix the LIBTOOL=glibtool problem by adding a check for OS X to NTL's wizard. Ok. I am specifically thinking of your patch to zn_poly as well as polybori where your patch broke the linking on OSX 10.4 for example. Work on both of those was early. But I didn't write the patch for polybori that was merged; that was done by the upstream developers using some scons options. Ok, if you contact upstream about anything Sage related please CC me and William in the future. If the person responds only to you which happens frequently with people being unaware there is a reply-all please either forward the email to me and William or CC me on the reply again. Sure, I can do that. Just to be super clear, you want me to do this for all such contact, not just cddlib, right? There is a new upstream-ish release of IML whcih should have this code. Yes, I was able to get iml upstream to do a release with the relevant code; it was just a problem for me at the time. Yes, you just ended up with the patches that fell through the cracks :) My time is limited and if I have written a couple email to upstream and I never got any feedback at all I am just dropping the issue since I have plenty of other things to do. Right, I should expect to have a sampling bias problem where I only notice when the patches don't end up upstream promptly :) -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 24, 3:30 pm, Tim Abbott tabb...@mit.edu wrote: On Fri, 24 Apr 2009, mabshoff wrote: Hi Tim, Is that correct or are the GNUisms Victor's fault? I would assume that is correct. I didn't actually write any of the code for NTL 5.5; Victor did all the work there. That said, I thought his intention was to not require GNU make as he mentioned it as one of his goals when discussing with me; I guess that was only important when SHARED=off. Looking at the code there just seems to be one GNUism in the makefile: $(OBJ:.o=.lo). This is probably removable with a bit of work. Well, don't worry about it too much. As long as freetype deliberately uses gmake features (and refuses to remove them) Sage cannot be build with a pure BSD-ish make anyway. I just want upstream to be aware of the problem and not add to the problem. One could fix the LIBTOOL=glibtool problem by adding a check for OS X to NTL's wizard. Yeah, I am not sure what Victor is talking about. If you install XCode you will have libtool on OSX. It might be that he is using MacPorts or Fink where things are different. Ok. I am specifically thinking of your patch to zn_poly as well as polybori where your patch broke the linking on OSX 10.4 for example. Work on both of those was early. But I didn't write the patch for polybori that was merged; that was done by the upstream developers using some scons options. Sure, but if you wouldn't have complained the code would have never been added ;) Seriously: library versioning matters a lot of distribution packaging, but it seriously annoys me and creates problems, i.e. there is a whole set of of FreeBSD fixes in trac now that I will hopefully all merge in 3.4.2.rc0 today that are caused by libtool friends. None of this is your fault, but there are just two different forces at play here and we need to find an equilibrium. Ok, if you contact upstream about anything Sage related please CC me and William in the future. If the person responds only to you which happens frequently with people being unaware there is a reply-all please either forward the email to me and William or CC me on the reply again. Sure, I can do that. Just to be super clear, you want me to do this for all such contact, not just cddlib, right? Yes, I would like to be CCed on anything offlist to upstream code in Sage related to Debian packaging. Feel free to use your own judgment, i.e. if you feel uncomfortable for any reason just drop me from the CC. In some cases don't expect a reply, but you can assume I will read every email. There is a new upstream-ish release of IML whcih should have this code. Yes, I was able to get iml upstream to do a release with the relevant code; it was just a problem for me at the time. Ok, last time we sat down with Arne there was a problem with OSX, but I will look into this. It is a non-Debian issue, so if we cannot get Arne to do a release we will just conditionally patch it out in the spkg. Yes, you just ended up with the patches that fell through the cracks :) My time is limited and if I have written a couple email to upstream and I never got any feedback at all I am just dropping the issue since I have plenty of other things to do. Right, I should expect to have a sampling bias problem where I only notice when the patches don't end up upstream promptly :) Indeed :) -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 Fri, Apr 24, 2009 at 1:59 AM, Tim Abbott tabb...@mit.edu wrote: 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. Yes, that's correct. It was just a script --- the script was indeed free, so IIRC the package lived in contrib (as a free package which depends on a non-free/out of debian package). 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. I'd assume such a package would enter debian in the contrib section (if at all). I fail to see a reason for it to go to non-free. Still, a package in contrib which downloads and compiles sage would be definitely better than no package, and in some cases even better than an outdated package. Disclaimer: I've been using debian for a lng time, and I only track the main section --- so such a package wouldn't reach me if it lives in contrib --- but (a) I still think it'd be useful for some people (b) I'd frown on such a package being in the main section of debian. 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: 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=getsearch=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: Sage 4.0 release plan
On Apr 23, 1:22 am, Martin Albrecht m...@informatik.uni-bremen.de 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=getsearch=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: 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: 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 tabb...@mit.edu 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
On Thu, Apr 23, 2009 at 12:32 PM, David Roe r...@math.harvard.edu 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 tabb...@mit.edu 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: Sage 4.0 release plan
2009/4/23 Tim Abbott tabb...@mit.edu: 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: Sage 4.0 release plan
On Apr 23, 5:51 am, Georg S. Weber georgswe...@googlemail.com 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: Sage 4.0 release plan
On Apr 23, 6:23 am, Dr. David Kirkby david.kir...@onetel.net wrote: mabshoff wrote: Hello, SNIP 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 mabsh...@googlemail.com wrote: On Apr 23, 6:23 am, Dr. David Kirkby david.kir...@onetel.net wrote: mabshoff wrote: Hello, SNIP 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 wst...@gmail.com wrote: On Thu, Apr 23, 2009 at 12:32 PM, David Roe r...@math.harvard.edu 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 tabb...@mit.edu 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 wst...@gmail.com wrote: On Thu, Apr 23, 2009 at 1:50 PM, mabshoff mabsh...@googlemail.com wrote: SNIP 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 mabsh...@googlemail.com wrote: On Apr 23, 12:57 pm, William Stein wst...@gmail.com wrote: On Thu, Apr 23, 2009 at 12:32 PM, David Roe r...@math.harvard.edu 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 tabb...@mit.edu 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 wst...@gmail.com wrote: On Thu, Apr 23, 2009 at 1:58 PM, mabshoff mabsh...@googlemail.com wrote: SNIP 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 georgswe...@googlemail.com 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: char**omAlloc0(sizeof(char*)*(len(self._names))) Done: char**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] 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 tabb...@mit.edu 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 -~--~~~~--~~--~--~---
