I'd work on this while I'm in Seattle.
Martin
--
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF
_www: http://www.informatik.uni-bremen.de/~malb
_jab: martinr...@jabber.ccc.de
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
-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
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
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
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
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
> 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
> >> 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
> 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
> 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
> 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
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.
> 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
> 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
> 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
> 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.
Great! I hope to do some investigation tomorrow as to what other work is
needed in this space.
-Tim Abbott
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 loooong 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
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" <nth...@users.sf.net>
http://Nicolas.Thiery.name/
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
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,
> 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.
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" <nth...@users.sf.net>
http://Nicolas.Thiery.name/
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
>
> 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
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
>
>> 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
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
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
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)
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,
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.
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