On Wed, Dec 24, 2008 at 9:37 AM, mhampton <hampto...@gmail.com> wrote: > > I mentioned the polymake problem a while ago, with a simple fix (just > changing the version of cddlib it points to), and Michael wanted to do > a more complete/automatic fix, so it rotted quietly for a while. But > I have been installing it off and on since then by manually changing > the spkg install. It builds fine on my intel macs after that. > > The native sage polytope functionality is improving at a pretty good > pace now, hopefully in the next year we can do almost everything that > polymake can. There are a number of nice things that polymake can do > that require non-free java guis, which presumably we would never > include anyway, so some of the remaining gaps in functionality require > us writing new code anyway. That was one of the main reasons I > thought it was worthwhile to work on native sage implementations. > > As long as I'm talking about that, could someone please review #4676?
I think I can do that this week. I wrote a "toric" package for GAP http://sage.math.washington.edu/home/wdj/gap/toric/ and your polyhedra.py module looks like the right place to add it. (Ie, I can add it to the long list of things I want to do but probably will never get around to doing:-) > It didn't make it into 3.2.2 because of no review. > > -Marshall Hampton > > On Dec 24, 8:10 am, mabshoff <mabsh...@googlemail.com> wrote: >> On Dec 23, 11:13 pm, "William Stein" <wst...@gmail.com> wrote: >> >> > On Tue, Dec 23, 2008 at 11:02 PM, William Stein <wst...@gmail.com> wrote: >> > > Hi, >> >> Hi, >> >> > > I propose moving the polymake spkg to be experimental instead of >> > > optional. If anybody cares, please respond to this email. It's >> > > crystal clear having looked at the polymake spkg tonight that not a >> > > single person has successfully installed polymake in several months. >> >> Not true, it is that the version in the repo has been broken :) >> >> > > See: http://trac.sagemath.org/sage_trac/ticket/4868 >> >> Seehttp://sage.math.washington.edu/home/mabshoff/polymake-2.2.p5.spkg >> and the ticket #3640. Polymake is a prime example where sticking >> things into the optional or experimental spkg repo without proper >> review and an active maintainer is wrong. >> >> > Hi, just responding to myself here, the following optional spkg's all >> > fail to install on sage.math (a standard Ubuntu box): >> >> > dvipng-1.8 >> > gcc-4.2.1 >> > hermes-0.9.4-linux >> > jmol-11.5.2-src-v2 >> > polymake-2.2.p4 >> >> > I would like to deprecate all of them to experimental. Reasoning: >> >> > * dvipng-1.8 -- available on any linux/os x system via standard >> > package tools; has nothing to do with sage >> >> Delete it completely. The dependencies are insane and people just >> install the distributions version.. >> >> > * gcc-4.2.1 -- this spkg exists only because Michael made it so I >> > could try to build sage on some weird systems where the system-wide >> > compilers were crap. It doesn't build on sage.math now, and it's not >> > something almost anybody should use. >> >> Well, that is because Sage seems to be missing 32 bit userspace. That >> is an installation issue, but I am fine with moving it to experimental >> or even deleting it. I have a gcc 4.3.2.spkg, but I am sure that will >> also fail currently on sage.math. But monkeying around and custom >> fitting things for sage.math is just wrong, i.e if dependencies are >> missing it just won't work. >> >> > * jmol-11.5.2-src-v2 -- this spkg exists to demonstrate that in >> > theory jmol can be built from source. I don't think anybody actually >> > has ever used it. Better would be a web page that contains the spkg >> > and instructions on how to use it to make the binary spkg. >> >> This probably fails because because the Sun Java JDK isn't installed. >> jmol never worked with the gcj toolchain, so no surprise here. >> >> > * hermes-0.9.4-linux -- a binary-only spkg that doesn't (and doesn't >> > fail gracefully) on any system I have. I don't even know what it >> > does. I don't know where it came from. It hasn't been touched in >> > nearly three years. >> >> This was discussed in another thread and we should just remove it. >> >> > * polymake-2.2.p4 -- I don't know if this builds on anything. See >> > above. Since Sage doesn't binary link to polymake at all, it is >> > better if polymake is installed from some official polymake binaries >> > or whatever completely independent of sage. >> >> Well, I fixed it. >> >> > I want the Sage "optional" packages to *all* install fine on every >> > system that we officially support Sage on. >> >> No chance this is going to work. >> >> > There should be a single >> > command to easily install *all* of them, and another easy way to run >> > all relevant optional doctests (that depend on all the free optional >> > spkg's). >> >> That won't work either. All we can shoot for is to get them all >> working on sage.math. There are also optional doctests in sage that >> depend on experimental spkgs like M2. And M2 does not build on Solaris >> as is for example. >> >> > -- William >> >> Cheers, >> >> Mihcael > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---