#6456: Upgrade cvxopt in sage from 0.9 to 1.1.2
--------------------------------+-------------------------------------------
Reporter: was | Owner: mabshoff
Type: defect | Status: needs_work
Priority: major | Milestone: sage-4.5.2
Component: packages | Keywords:
Author: schilly, dimpase | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
--------------------------------+-------------------------------------------
Comment(by drkirkby):
Replying to [comment:74 dimpase]:
> Replying to [comment:72 pjeremy]:
> > Replying to [comment:71 drkirkby]:
> > > * Try an earlier release (i.e newer than 0.9, but not the latest)
> >
> > I don't see any benefit in this. The only justification I can find
mentioned in this thread for updating cvxopt is that the current version
is "ancient". Unless someone comes up with a more compelling reason for
updating, I would suggest sticking to the current spkg until problems with
cvxopt-1.1.2 are resolved.
> >
> > > * Contact the author, making him aware of the bug Peter found -
i.e. passing 64-bit pointers when the code is expecting 32-bit ones. Also
point out there are a lot of variables declared, which are never used.
> >
> > To be precise, the code is passing pointers to 64-bit objects to
functions expecting pointers to 32-bit objects.
> >
> > I started to look at how difficult it would be to fix this morning but
ran out of train journey before I got very far.
> >
> > Also, whilst reading through the revision history for cvxopt, I notice
that there have been a couple of changes that don't appear to be backward
compatible: The `cvxopt.random` module was deleted in 0.9.2 and the
definition of `bool(A)` (where `A` is a matrix) was changed in 1.1. Are
these changes likely to impact other components of Sage?
>
> I am not aware of any Sage component that uses cvxopt. Surely, upgrading
from 0.9 to 1.1 will break some code using cvxopt, but this is to be
expected. The structure of the library has changed somewhat, so some
imports might need to be fixed.
>
> Regarding random, cvxopt has switched to using external random sources
before 0.9.8, which is the currently used in Sage 4.5.1 spkg version. So I
do not see why this is relevant at this point at all.
The pointer problem could potentially cause segfaults and data corruption.
That's my single biggest concern. Not a single test passed on my Solaris
build.
There appears to be a split view on this ticket
* Those that want it updated for the functionality.
* Those that don't want the current code updated because they feel it's a
regression.
How about making the updated version an optional or experimental package?
(Personally I feel the latter is more appropriate). Those that feel they
need the update can use it, whilst those that consider it makes Sage less
stable will simply not bother installing it.
I think Peter's comments about the:
''"release it now, we'll make it work later" mentality'''
is very true here.
Dave
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/6456#comment:76>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
