Upgrade cvxopt in sage from 0.9 to 1.1.3

[williamstein]

We are shipping an ancient version of cvxopt in sage. It's worse than Debian shipping sage-3.0.5!

Note that upgrading cvxopt should be fairly easy, since basically nothing in Sage depends on cvxopt.

New spkg: http://sage.math.washington.edu/home/dima/packages/cvxopt-1.1.3.spkg and the patch to use the interface to GLPK : https://github.com/sagemath/sage/files/ticket6456/6456-cvxopt-glpk-interface.patch.gz

Upstream: Completely fixed; Fix reported upstream

Component: packages: standard

Author: Harald Schilly, Dmitrii Pasechnik

Reviewer: Mike Hansen, Karl-Dieter Crisman

Merged: sage-4.6.1.alpha2

Issue created by migration from https://trac.sagemath.org/ticket/6456

[wdjoyner]

comment:1

Fly in the ointment: The recent version has this statement on its license page http://abel.ee.ucla.edu/cvxopt/copyright.html:

CVXOPT is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version.

Older versions apparently did not have that.

[haraldschilly]

comment:2

I've recently upgraded it for me to 1.1.2. The problem is, that the sources from them did not compile on my ubuntu 9.10 machine. So I went to the ubuntu packges db for lucid and grabbed their version. I don't know what they did in their patch, but I guess it's non trivial...

My spkg is here.

The only remaining modification I had to made to run the examples from the cvxopt website in %python mode was to replace

from random import ...

to

from sage.misc.prandom import ...

in ./src/src/python/__init__.py at several places.

Q:

1. what's the usual/best mechanism to avoid using Sage's random and switch back to python's random?!
2. i have no idea what the solaris patches did in the older version, neither do i know how to get it building on another system :(

[haraldschilly]

comment:3

I've created an updated p1 spkg.

Using the 1.1.2 sources directly, I get this error site-packages/cvxopt/base.so: undefined symbol: _g95_stop_blank ... I also fiddled around with the setup.py file.

cvxopt 1.1.2 p1 spkg is here

[7c09a680-e216-4024-bb8e-9bfd4aa7f313]

comment:4

Ticket #1620 is a duplicate of this one.

[dimpase]

comment:5

Replying to @haraldschilly:

I've created an updated p1 spkg.

Using the 1.1.2 sources directly, I get this error site-packages/cvxopt/base.so: undefined symbol: _g95_stop_blank ... I also fiddled around with the setup.py file.

cvxopt 1.1.2 p1 spkg is here

sage -t "devel/sage-work/sage/numerical/optimize.py"

bumps out essentially due to:

sage: from cvxopt import cholmod
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)

/home/dima/sage/devel/sage-work/sage/<ipython console> in <module>()

ImportError: /home/dima/sage/local/lib/python2.6/site-packages/cvxopt/cholmod.so: undefined symbol: _g95_filename
sage: 

Can you reproduce this on a stand-alone build of cvxopt?

[dimpase]

Attachment: trac-6456.patch.gz

patch for cvxopt-1.1.2.p1/src/src/setup.py

[dimpase]

comment:6

Replying to @haraldschilly:

I've created an updated p1 spkg.

Using the 1.1.2 sources directly, I get this error site-packages/cvxopt/base.so: undefined symbol: _g95_stop_blank ... I also fiddled around with the setup.py file.

cvxopt 1.1.2 p1 spkg is here

please check the patch I just uploaded. It fixes this problem; you just had to link against more dynamic libs...

[haraldschilly]

comment:7

Replying to @dimpase:

please check the patch I just uploaded. It fixes this problem; you just had to link against more dynamic libs...

Thanks, I knew that it is something with that! Works now!!! ;)

I've uploaded 1.1.1.p2 here

Next I'll try if using the debian/ubuntu version of it was really necessary.

For everyone who wants to try this, don't forget that you have to disable the preparser in Sage via preparser(False) ... otherwise there are unknown types when you try to create a matrix with cvxopt's matrix command.

[dimpase]

comment:8

Replying to @haraldschilly:

I've uploaded 1.1.1.p2 here

Next I'll try if using the debian/ubuntu version of it was really necessary.

please take out f77blas all over in setup.py, for this is apparently obsolete and not needed - and also nukes the installation on Mac OS X (ppc) -- (otherwise it works on the latter platform)

[dimpase]

comment:9

Replying to @haraldschilly:

I think that really what remains to be done is to remove dependencies on obsolete fortrans (f77), see my other comment on this. Let's get it done!

Replying to @dimpase:

please check the patch I just uploaded. It fixes this problem; you just had to link against more dynamic libs...

Thanks, I knew that it is something with that! Works now!!! ;)

I've uploaded 1.1.1.p2 here

Next I'll try if using the debian/ubuntu version of it was really necessary.

I don't see a necessity to try non-debian/ubunty version. If you look at the debian patches, you see that all they changed is the source were slight tweaks in setup.py

For everyone who wants to try this, don't forget that you have to disable the preparser in Sage via preparser(False) ... otherwise there are unknown types when you try to create a matrix with cvxopt's matrix command.

Does this mean that we should think of importing cvxopt's matrix into Sage under some other name? I don't know what the usual Sage's way to deal with such things, i.e. name clashes between packages, is.

[bac7d3ea-3f1b-4826-8464-f0b53d5e12d2]

comment:10

• Have the license issue been resolved?
  • Has this been tested on Solaris?

[dimpase]

comment:11

Replying to @sagetrac-drkirkby:

• Have the license issue been resolved?

it is GPL v3 or later. Does it matter? I suppose I can ask the authors to tweak it, if it is really necessary.

• Has this been tested on Solaris?

no, but I can try on one of Skynet's machines (perhaps you can tell me which one is most likely to work :)), or you can try it yourself. (I don't have a ready Solaris install anywhere).

[bac7d3ea-3f1b-4826-8464-f0b53d5e12d2]

comment:12

You better check the license issue with William. Code should be GPL 2 or GPL2+, but there are exceptions if a package is optional and some other conditions - I've never fully understood under what conditions code can be GLP 3. But you might find you can only use the latest version which is GPL 2, and not a GPL 3 version.

sage: license()

says all code except jsmath is GPL2, and apparently jsmath is ok, as Sage does not link to it.

The code will not build on skynet, as there are no SPARC machines there. It should build it on 't2' easily though.

I suggest you download sage 4.3.0.1 from one of the mirrors

http://www.sagemath.org/download-solaris.html

Use the following settings.

kirkby@t2:[~] $ echo $PATH
/usr/local/gcc-4.4.1-sun-linker/bin:/usr/local/bin2:/usr/bin:/usr/ccs/bin:/usr/local/bin:/usr/sfw/bin:/bin:/usr/sbin
kirkby@t2:[~] $ echo $LD_LIBRARY_PATH
/usr/local/gcc-4.4.1-sun-linker/lib:=/usr/local/gcc-4.4.1-sun-linker/lib/sparcv9:/usr/local/lib

type make, and build Sage, then try your package.

There is also a binary of Sage on the mirrors. You could download that. I'm not precisely sure what you then need to do to build just your package using the binary as a starting point.

The latest Sage source will not build on Solaris, but 4.3.0.1 will.

Dave

[dimpase]

comment:13

Replying to @sagetrac-drkirkby:

You better check the license issue with William. Code should be GPL 2 or GPL2+, but there are exceptions if a package is optional and some other conditions - I've never fully understood under what conditions code can be GLP 3. But you might find you can only use the latest version which is GPL 2, and not a GPL 3 version.

Well, cvxopt is an optional package, so it must be in the same boat as jmath, or some gap packages, that are also not GPL 2.

sage: license()

says all code except jsmath is GPL2, and apparently jsmath is ok, as Sage does not link to it.

The code will not build on skynet, as there are no SPARC machines there. It should build it on 't2' easily though.

hmm, isn't this a sparc/solaris?

SunOS mark2 5.10 Generic_127111-01 sun4u sparc SUNW,Sun-Blade-2500

Dima

[bac7d3ea-3f1b-4826-8464-f0b53d5e12d2]

comment:14

Replying to @dimpase:

Replying to @sagetrac-drkirkby:

You better check the license issue with William. Code should be GPL 2 or GPL2+, but there are exceptions if a package is optional and some other conditions - I've never fully understood under what conditions code can be GLP 3. But you might find you can only use the latest version which is GPL 2, and not a GPL 3 version.

Well, cvxopt is an optional package, so it must be in the same boat as jmath, or some gap packages, that are also not GPL 2.

Fair enough.

sage: license()

says all code except jsmath is GPL2, and apparently jsmath is ok, as Sage does not link to it.

The code will not build on skynet, as there are no SPARC machines there. It should build it on 't2' easily though.

hmm, isn't this a sparc/solaris?

SunOS mark2 5.10 Generic_127111-01 sun4u sparc SUNW,Sun-Blade-2500

Dima

Yes, it is. Sorry, I was not aware of the existance of that machine.

However, I do not know how the compilers and paths are configured on that machine. You need to have GNU make & GNU tar in your path before the Sun ones, and you need to have the Sun linker (/usr/ccs/bin/ld) in your path before any GNU ones. There are some general instructions on building Sage on Solaris at http://wiki.sagemath.org/solaris which you would need to follow.

I've written some somewhat simpler instructions at http://wiki.sagemath.org/devel/Building-Sage-on-the-T5240-t2 on how to build Sage on 't2'. They are simpler, as I have already put the right tools in the right locations.

The Sun Blade 2500 (mark2) should be quicker than the T5240 (t2) at building Sage. However it would require some setting up of the build environment to build Sage. If you just want an easy solution, 't2' will just work, albeit not as quickly as the Sun Blade 2500.

Dave

[dimpase]

comment:15

Replying to @sagetrac-drkirkby:

hmm, isn't this a sparc/solaris?

SunOS mark2 5.10 Generic_127111-01 sun4u sparc SUNW,Sun-Blade-2500

Dima

Yes, it is. Sorry, I was not aware of the existance of that machine.

However, I do not know how the compilers and paths are configured on that machine. You need to have GNU make & GNU tar in your path before the Sun ones, and you need to have the Sun linker (/usr/ccs/bin/ld) in your path before any GNU ones. There are some general instructions on building Sage on Solaris at http://wiki.sagemath.org/solaris which you would need to follow.

well, on Skynet there is /usr/local/skynet_bash_profile that you can source upon login (from .bashrc, or just manually), and this gives you the ready setup to build Sage.

I don't have an account on t2, it seems to me. By the way, absent-mindedly I started building 4.3.3.alpha on there, and it went till gnutls, where it stopped... I noticed that gnutls is over 2 years old, version 2.2.2, whereas the current one is 2.8.5. Shouldn't one upgrade to this one, before even trying to fix this?

Dima

[dimpase]

comment:16

Replying to @sagetrac-drkirkby:

You better check the license issue with William. Code should be GPL 2 or GPL2+, but there are exceptions if a package is optional and some other conditions - I've never fully understood under what conditions code can be GLP 3. But you might find you can only use the latest version which is GPL 2, and not a GPL 3 version.

I emailed William about this, and he said it's OK in this case, it can be v3.

[bac7d3ea-3f1b-4826-8464-f0b53d5e12d2]

comment:17

Replying to @dimpase:

Replying to @sagetrac-drkirkby:

However, I do not know how the compilers and paths are configured on that machine. You need to have GNU make & GNU tar in your path before the Sun ones, and you need to have the Sun linker (/usr/ccs/bin/ld) in your path before any GNU ones. There are some general instructions on building Sage on Solaris at http://wiki.sagemath.org/solaris which you would need to follow.

well, on Skynet there is /usr/local/skynet_bash_profile that you can source upon login (from .bashrc, or just manually), and this gives you the ready setup to build Sage.

I'm not however aware of anyone building Sage on there recently, so I don't know if the environment is set up suitably. Quite a few Solaris-specific changes have been made in the last year, and some of them might not be compatible with the build system on there. I don't know. Specifically, if

gcc -v 

shows gcc was configured with the GNU linker, then the GNU linker must be in your path before the Sun linker. (Basically, whatever linker gcc uses, must be in your path first, as some code makes the assumption the first linker in your path is the one gcc uses, which might not be true.) I'm not aware of a foolproof test of this.

There should be something like

--with-ld=/usr/ccs/bin/ld

if the Sun linker was used, or

--with-ld=/path/to/gnu/ld

if the GNU linker was used.

Certainly, I've never had a problem with gnutls failing on 't2'.

I don't have an account on t2, it seems to me.

I've emailed William to ask if you can have an account on t2, as that might be the simplest solution, though that Blade 2500 would be significantly faster than 't2'.

By the way, absent-mindedly I started building 4.3.3.alpha on there, and it went till gnutls, where it stopped... I noticed that gnutls is over 2 years old, version 2.2.2, whereas the current one is 2.8.5. Shouldn't one upgrade to this one, before even trying to fix this?

Dima

I can see your point about upgrading, though I'm not aware of any particular issues with the version in Sage. That version will build on Solaris. You could try appending /usr/sfw/lib to your LD_LIBRARY_PATH. I have known of issues with gnutls on OpenSolaris, but not on Solaris 10.

I see your post about the GPL 3. That bit is sorted out then.

Dave

[dimpase]

comment:18

Replying to @dimpase:

Replying to @haraldschilly:

Here is an updated version, that also works on Solaris (this needed copying sun_complex.h from old cvxopt-0.9 and patching cvxopt.h). I also turned on building GSL-extension (by turning on the appropriate option in setup.py, and supplying right include and lib-paths)

http://boxen.math.washington.edu/home/dima/packages/cvxopt-1.1.2.p3.spkg

[haraldschilly]

comment:19

hi, great work, your 1.1.2.p3.spkg works for me on intel core2 duo with ubuntu 9.04 running 4.3.4.rc0.

It's just that the name shouldn't have the .p3, the SPKG.txt is not correct (your name missing), the patches aren't yours but still mine and there is no mention what you have really done with the *.h files for solaris. where is a good page to read about the spkg policies?!?

[haraldschilly]

Reviewer: schilly

[dimpase]

comment:20

Replying to @haraldschilly:

hi, great work, your 1.1.2.p3.spkg works for me on intel core2 duo with ubuntu 9.04 running 4.3.4.rc0.

It's just that the name shouldn't have the .p3, the SPKG.txt is not correct (your name missing), the patches aren't yours but still mine and there is no mention what you have really done with the *.h files for solaris. where is a good page to read about the spkg policies?!?

OK, finally here comes an update: http://boxen.math.washington.edu/home/dima/packages/cvxopt-1.1.2.spkg

Fixed SPKG.txt, added all the patches in patches/, further changes as we discussed by email (see SPKG.txt). Tested (with Sage 4.3.4) on Linux x86 and x86_64, Solaris (t2) and on MacOSX 10.5 PPC (G4)

[haraldschilly]

comment:21

Replying to @dimpase:

Fixed SPKG.txt

spkg works for me on ubuntu 9.04, intel core2 duo and sage 4.3.4. I've just further cleaned up the SPKG.txt file since only the net changes are relevant and now there is also a title plus a description.

final spkg is here

[dimpase]

comment:22

Replying to @haraldschilly:

Replying to @dimpase:

Fixed SPKG.txt

spkg works for me on ubuntu 9.04, intel core2 duo and sage 4.3.4. I've just further cleaned up the SPKG.txt file since only the net changes are relevant and now there is also a title plus a description.

final spkg is here

OK, great, thanks! How do we finalise this? Should I make myself the owner? Should I make you (and/or myself?) the author?

[haraldschilly]

comment:23

Replying to @dimpase:

OK, great, thanks! How do we finalise this? Should I make myself the owner? Should I make you (and/or myself?) the author?

Uhm, we both are the authors and well, we need a thrid party to give us a positive review ;)

[haraldschilly]

Changed reviewer from schilly to none

[haraldschilly]

Author: schilly, dimpase

[6bdad4c1-1e26-4f2f-a442-a01a2292c181]

comment:24

Hello !!!

This patch applies, the spkg compiles fine and is well built, everything runs in the end and the doctest using it passes !!!

The only trouble I could find is the need to disable the preparser (mentionned by Harald earlier) to use regular CVXOPT scripts in Sage, but this is not new and could be adressed later. Clearly, this is an improvement for Sage :-)

Thank you for your work !!!

Nathann

P.S. : what would you think of creating another ticket to add a line about this perparsing bug somewhere there : http://www.sagemath.org/doc/numerical_sage/cvxopt.html ?

[haraldschilly]

comment:25

Replying to @nathanncohen:

P.S. : what would you think of creating another ticket to add a line about this perparsing bug somewhere there : http://www.sagemath.org/doc/numerical_sage/cvxopt.html ?

That's not a bug, the examples in that tutorial redefine Integer as int and similar workarounds. I prefer disabling the preparser or switching to pure python mode. However, maybe this could be done automatically somehow (as with numpy arrays?) but that's not the scope of this ticket.

[haraldschilly]

trival changes to the cvxopt chapter in the numerical sage tutorial

[jhpalmieri]

comment:26

Attachment: 6456-numerical_sage_cvxopt.patch.gz

Any ideas why the new spkg is so much smaller than the old one?

-rw-r--r-- 1 palmieri palmieri 2463336 2010-02-11 08:56 spkg/standard/cvxopt-0.9.p8.spkg
-rw-r--r-- 1 palmieri palmieri  733213 2010-03-24 09:49 spkg/standard/cvxopt-1.1.2.spkg

[haraldschilly]

comment:27

Replying to @jhpalmieri:

Any ideas why the new spkg is so much smaller than the old one?

iirc we have removed documentation and examples. They are not exposed in any way or not used at all (tex sources).

[mwhansen]

comment:28

I don't think this is ready to go in. Some issues:

1. I don't think there should be a patches-old directory. If people need them for historical reasons, then they should get them from the hg repo since that's what it is there for.

2. Files are modified in place in the src/ directory. That should be as close to clean as vanilla upstream as possible. The modified files should be copied over from patches/

3. In the patches directory, the patches should be unified diffs (diff -Naur).

4. In spkg-install, you should just remove the old, unnecessary code instead of just commenting it out. Also, I don't think the SAGE_LOCAL check is necessary.

[dimpase]

comment:29

Replying to @mwhansen:

I don't think this is ready to go in. Some issues:

1. I don't think there should be a patches-old directory. If people need them for historical reasons, then they should get them from the hg repo since that's what it is there for.

OK, this is clear. We need to check if we didn't nuke the old .hg/, and put it back, if necessary.

2. Files are modified in place in the src/ directory. That should be as close to clean as vanilla upstream as possible. The modified files should be copied over from patches/

OK, this is clear too (although this seems to be against the historic way cvxopt spkg was created)

3. In the patches directory, the patches should be unified diffs (diff -Naur).

I don't get this. Are you saying that patches cannot be just files that are ready to be copied, that they must be diffs, and the spkg-install must be patching rather than copying?

4. In spkg-install, you should just remove the old, unnecessary code instead of just commenting it out. Also, I don't think the SAGE_LOCAL check is necessary.

we'll see.

[mwhansen]

comment:30

Replying to @dimpase:

I don't get this. Are you saying that patches cannot be just files that are ready to be copied, that they must be diffs, and the spkg-install must be patching rather than copying?

You should have both the patched file and the diff in the patches/ directory. The diff is useful when upgrading the spkg.

[dimpase]

comment:31

Replying to @mwhansen:

Replying to @dimpase:

I don't get this. Are you saying that patches cannot be just files that are ready to be copied, that they must be diffs, and the spkg-install must be patching rather than copying?

You should have both the patched file and the diff in the patches/ directory. The diff is useful when upgrading the spkg.

This seems to be an unnecessary duplication of information. The diffs can be trivially created, if needed.

[mwhansen]

comment:32

Replying to @dimpase:

This seems to be an unnecessary duplication of information. The diffs can be trivially created, if needed.

They can be recreated if you have the correct version of the source from which the patched file was created. It's easier if the actual diff is in the version control.

[dimpase]

comment:33

Replying to @mwhansen:

Replying to @dimpase:

This seems to be an unnecessary duplication of information. The diffs can be trivially created, if needed.

They can be recreated if you have the correct version of the source from which the patched file was created. It's easier if the actual diff is in the version control.

I should have time next week to fix this, finally... Dima

[mwhansen]

comment:34

There is also the issue at #9525 which needs to be taken care of.

[bac7d3ea-3f1b-4826-8464-f0b53d5e12d2]

Attachment: 6456-error-check-while-installing.patch.gz

Check for errors while installing cvxopt. Note there is still no spkg-check file. That may or may not be useful - it depends on the source code whether it supports tests.

[dimpase]

comment:35

Replying to @mwhansen:

I don't think this is ready to go in. Some issues:

1. I don't think there should be a patches-old directory. If people need them for historical reasons, then they should get them from the hg repo since that's what it is there for.

2. Files are modified in place in the src/ directory. That should be as close to clean as vanilla upstream as possible. The modified files should be copied over from patches/

3. In the patches directory, the patches should be unified diffs (diff -Naur).

4. In spkg-install, you should just remove the old, unnecessary code instead of just commenting it out. Also, I don't think the SAGE_LOCAL check is necessary.

the update, that takes your comments into account, is here http://boxen.math.washington.edu/home/dima/packages/cvxopt-1.1.2.spkg

Please have a look, hopefully it is OK now. Dima

[NathanDunfield]

comment:36

This ticket should be coordinated with #9598, which adds GLPK support to cvxopt.

[haraldschilly]

comment:37

spkg looks fine for me, builds and also solves some randomly choosen example from the user guide. additionally, i tested if my patch for the documentation 6456-numerical_sage_cvxopt.patch still works and yes, it does.

regarding glpk, Dima are you able to enable the glpk flag and try building it? if it works i can test it again and see if that's fine - if it doesn't build and you run into bigger problems, we should finally update this spkg anyways and postpone glpk support in cvxopt.

[NathanDunfield]

comment:38

Replying to @haraldschilly:

regarding glpk, Dima are you able to enable the glpk flag and try building it? if it works i can test it again and see if that's fine - if it doesn't build and you run into bigger problems, we should finally update this spkg anyways and postpone glpk support in cvxopt.

There's a patch for glpk for the old cvxopt 0.9 at #9598. The changes there should work find for cvxopt 1.1 as well.

[bac7d3ea-3f1b-4826-8464-f0b53d5e12d2]

comment:39

Looking in

cvxopt-1.1.2/src

I see

drwxr-xr-x   3 drkirkby staff          5 Mar 24 11:40 cvxopt-1.1.2
lrwxrwxrwx   1 drkirkby staff         16 Jul 26 16:10 src -> cvxopt-1.1.2/src

It is certainly unusual to do this. Normally the top level src directory contains the source, not another directory with a link like this. I know of no other package like this.

I'm also puzzled why we have this:

# Solaris-specific patches
cp -p patches/sun_complex.h src/src/C/
cp -p patches/cvxopt.h src/src/C/

There is no file src/src/C/sun_complex.h so the first line just creates copies the file /usr/include/complex.h from Solaris to the patches directory. That file is from Sun, and its doubtful we can legally distribute /usr/include/complex.h

The second patch, patches/cvxopt.h differs from src/src/C/cvxopt.h by very little. A diff shows:

drkirkby@hawk:~/sage-4.5.2.alpha0/spkg/optional/cvxopt-1.1.2$ diff -u src/src/C/cvxopt.h patches/cvxopt.h
--- src/src/C/cvxopt.h  Mon Jul 26 11:16:09 2010
+++ patches/cvxopt.h    Mon Jul 26 10:58:48 2010
@@ -26,7 +26,14 @@
 /* ANSI99 complex is disabled during build of CHOLMOD */

 #ifndef NO_ANSI99_COMPLEX
+
+/* work around Solaris 10 specific problem in complex.h */
+#if defined (__sun)
+#include "sun_complex.h"
+#else
 #include "complex.h"
+#endif
+
 #define MAT_BUFZ(O)  ((complex *)((matrix *)O)->buffer)
 #endif

If I'm not mistaken, all these two patches achieve is to

• Add a file /usr/include/complex.h to Sage taken from Solaris, that it is doubtful we can legally include, though I doubt Sun (now Oracle) will complain.
• Change a file patches/cvxopt.h to include the file we have just illegally copied.

It would to me at least be a lot easier to just change the second file so it had

#ifdef if defined __sun /* Need to check if that's the best one */ 
#include <complex.h>
#endif

Why are we bothering to copy a system file from Solaris, rather than just not use #include <complex.h>?

Dave

[bac7d3ea-3f1b-4826-8464-f0b53d5e12d2]

comment:40

I should add, /usr/include/complex.h is included in the first release of Solaris 10 (released in March 2005) and also in the latest OpenSolaris build. There seems little point in doing what we are doing, espeically given it is doubtful if this is legal - the header is not released under the GPL.

Dave

[haraldschilly]

comment:41

Replying to @sagetrac-drkirkby:

Why are we bothering to copy a system file from Solaris, rather than just not use #include <complex.h>?

Because that's the way it was done in 0.9 and nobody of us knows about this in such a detail.

[dimpase]

comment:42

Replying to @NathanDunfield:

This ticket should be coordinated with #9598, which adds GLPK support to cvxopt.

please see

http://boxen.math.washington.edu/home/dima/packages/cvxopt-1.1.2.p1.spkg

This incorporates the #9598 in 1.1.2. Only tested on Linux Debian 32bit. I won't be having much internet until after tomorrow.

Dima

[haraldschilly]

comment:43

Replying to @dimpase:

This incorporates the #9598 in 1.1.2.

I tested it again and also tried to use glpk as an lp solver and it worked:

sage: from cvxopt import matrix, solvers
sage: c = matrix([-4., -5.])
sage: G = matrix([[2., 1., -1., 0.], [1., 2., 0., -1.]])
sage: h = matrix([3., 3., 0., 0.])
sage: sol = solvers.lp(c, G, h, solver='glpk')
GLPK Simplex Optimizer, v4.44
4 rows, 2 columns, 6 non-zeros
Preprocessing...
2 rows, 2 columns, 4 non-zeros
Scaling...
 A: min|aij| =  1.000e+00  max|aij| =  2.000e+00  ratio =  2.000e+00
Problem data seem to be well scaled
Constructing initial basis...
Size of triangular part = 2
*     0: obj =   0.000000000e+00  infeas =  0.000e+00 (0)
*     2: obj =  -9.000000000e+00  infeas =  0.000e+00 (0)
OPTIMAL SOLUTION FOUND

---

dear release manager, please don't forget to include GLPL as a dependency for cvxopt in the spkg/standard/deps file according to this comment.

[NathanDunfield]

comment:44

This incorporates the #9598 in 1.1.2. Only tested on Linux Debian 32bit.

Works fine on OS X Leopard, used same test as shilly above.