Sage 4.0 release plan
mabshoff
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
Martin Albrecht
Z/nZ) to the list: this is basically equivalent to updating to Singular 3.1
and getting some interface code right. Still, for some application this would
mean the world ;)
I'd work on this while I'm in Seattle.
Martin
--
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF
_www: http://www.informatik.uni-bremen.de/~malb
_jab: martinr...@jabber.ccc.de
mabshoff
On Apr 23, 1:22 am, Martin Albrecht <m...@informatik.uni-bremen.de>
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.
William and I spend an evening on the current OSX 64 bit problem - see
#5862. We fixed one issue that is caused by different dlopen behavior
by explicitly using dlsym() to get siInit() since it wasn't executed
at all on 64 bit OSX.
But fixing that issue still does not fix the segfault at startup. What
is happening is oMalloc not being properly initialized and going boom
the first time a ring is instantiated. I tried compiling oMalloc's
check target on OSX in 64 bit mode, but failed after only spending 5
minutes on the problem. Turning on debugging did not help for any of
the oMalloc issues. It seems that the initialization for oMalloc
mysteriously works for some releases while it is completely broken for
other releases, so we need an oMalloc expert to fix this :). Reverting
the fix GSW did for the mmap vs. sbrk problem did not revert the
problem either, so I am fresh out of ideas :(
> Martin
Cheers,
Michael
> --
> name: Martin Albrecht
> _pgp:http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
> _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF
> _www:http://www.informatik.uni-bremen.de/~malb
Georg S. Weber
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
Dr. David Kirkby
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
Tim Abbott
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
David Roe
David
William Stein
-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
Gonzalo Tornaria
>
> 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
mabshoff
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/
> ?
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.
building 64 bit binaries. It is indeed the main test box for us to do
so.
> Cheers,
> gsw
Cheers,
Michael
Jason Grout
>
> 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
mabshoff
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?
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/gtar xf gcc-a.b.c.tar.gz
>
> To say
>
> "It builds on skynet"
>
> is not too helpful to people.
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."
> 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
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.
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.
Sunfreware since I prefer building from source or using binaries
delivered via tarball that work without the need to be root.
> Dave
Cheers,
Michael
William Stein
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
mabshoff
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
>
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
mabshoff
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.
http://sage.math.washington.edu/home/mabshoff/solaris-binaries/
And they "just" work since Solaris has excellent binary
compatibility :)
> william
Cheers,
Michael
William Stein
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
mabshoff
On Apr 23, 2:04 pm, William Stein <wst...@gmail.com> wrote:
> > 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.
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
mabshoff
> the singular spkg I put a while ago at
> http://sage.math.washington.edu/home/weberg/spkg/
> ?
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
Tim Abbott
> 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
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
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
mabshoff
> > 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.
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.
> 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.
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.
> -Tim Abbott
Cheers,
Michael
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
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
mabshoff
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?
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.
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.
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.
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".
examples?
> -Tim Abbott
Cheers,
Michael
Dr. David Kirkby
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.
mabshoff
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
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.
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
Tim Abbott
> 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
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
Ben Goodrich
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
mabshoff
On Apr 24, 11:27 am, Tim Abbott <tabb...@MIT.EDU> wrote:
Hi Tim,
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
mabshoff
On Apr 24, 2:12 pm, Ben Goodrich <goodrich....@gmail.com> wrote:
> On Apr 24, 2:27 pm, Tim Abbott <tabb...@MIT.EDU> wrote:
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.
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
mabshoff
<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.
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.
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.
> > 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.
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.
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.
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
Ben Goodrich
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
David Harvey
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.
year. But Victor has been away on sabbatical, I haven't even met him
face-to-face yet.
david
mabshoff
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.
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.
> 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.
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
Michael
mabshoff
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:
> > 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.
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
mabshoff
On Apr 24, 3:09 pm, mabshoff <mabsh...@googlemail.com> wrote:
> On Apr 24, 2:50 pm, Ben Goodrich <goodrich....@gmail.com> wrote:
<SNIP>
>
> * 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?
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
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
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
mabshoff
> > 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.
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.
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.
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?
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.
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 :)
> -Tim Abbott
Cheers,
Michael
Gonzalo Tornaria
>
> 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 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
Nicolas M. Thiery
> 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" <nth...@users.sf.net>
http://Nicolas.Thiery.name/
mabshoff
On Apr 25, 12:13 am, "Nicolas M. Thiery" <Nicolas.Thi...@u-psud.fr>
wrote:
<SNIP>
> I really would want to get the category code in Sage soon (4.0???):
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
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 :-)
>
> 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 :-)
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.
work on ReSTifying documentation many patches will be touched.
> Cheers,
> Nicolas
Cheers,
Michael
Nicolas M. Thiery
> 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
William Stein
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" <nth...@users.sf.net>
> http://Nicolas.Thiery.name/
>
> >
>
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
Nicolas M. Thiery
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,
William Stein
<Nicolas...@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.
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.
>
> 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" <nth...@users.sf.net>
> http://Nicolas.Thiery.name/
>
> >
>
mabshoff
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.
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.net>http://Nicolas.Thiery.name/
mabshoff
On Apr 30, 1:37 pm, William Stein <wst...@gmail.com> wrote:
> On Thu, Apr 30, 2009 at 11:46 AM, Nicolas M. Thiery
>
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.
> > 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.
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...
> -- 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
>
[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.
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>
Nicolas M. Thiery
> On Apr 25, 8:39 am, "Nicolas M. Thiery" <Nicolas.Thi...@u-psud.fr>
> >
> > - 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.
Nicolas M. Thiery
> > > 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" <nth...@users.sf.net>
http://Nicolas.Thiery.name/
Nicolas M. Thiery
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
Robert Bradshaw
>
> 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
Nicolas M. Thiery
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
mabshoff
On May 20, 3:00 pm, "Nicolas M. Thiery" <Nicolas.Thi...@u-psud.fr>
wrote:
>
> 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!
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.net>http://Nicolas.Thiery.name/
Robert Bradshaw
>
>> 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
Nicolas M. Thiery
> 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. Thiery
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. Thiery
> Dear Craig, David, Mike, Robert:
>
> > I'll also give it a shot at the getattr alternative implementation
> > (as we had discussed), so that you can focus on reviewing.
>
> 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)
Nicolas M. Thiery
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 M. Thiery
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.
Carl Witty
<Nicolas...@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