Re: [sage-devel] Re: sage-4.3.1.rc0 released!
On Jan 22, 2010, at 9:31 AM, Dima Pasechnik wrote: Robert, the advantage is that it will simplify the *development* of Sage. Ironically, I personally find shipping all our dependancies makes development easier--I don't have to worry about someone else using different version than I have, and it's easy to look at and, if need be, patch the source directly. Right now lots of stoppers seem to come from upstream packages. For porting, yes. Whether or not depending on people to build their own upstream packages, then dealing with the issuing dependancy issues is a gain is up for debate. Probably depends on the package. I also do not see a real problem with specific versions of packages. Somehow, all the other open-source math projects seem to be able to manage this well, e.g. Singular manages to coordinate with GMP. As well, lots of things like needlessly tying Sage up to a very particular version or an environment can be sorted out simply by using autoconf properly... Some packages, like GMP, have a well defined and strongly backwards compatible API. Other packages, like GAP and maxima, aren't even considered libraries, and freely make changes that are semantically inconsequential but change how they interact with the user (which in this case is a pexpect interface, not a human who won't notice when a question is re-phrased). Even when changing versions doesn't give errors or bad results, often doctests will fail. (For example, the Debian port fails doctests all over the place, and trac is full of examples where bumping to a newer upstream version involves non- trivial work.) Still other packages are arcane, specialized sets of C files that where the author has little or no interest (or ability) in getting into or maintaining as part of a mainstream repository archive (if it would even be accepted). I'd love for someone to be able to do apt-get sage, and get a reasonably modern, fully working version (without too much redundancy with what's on their system, especially if that helps us get into debian, etc.) As a concrete goal towards that end, I'd suggest making a stripped version of sage that omits easy packages such as bzip2, zlib, maybe even gmp/mpir that still passes all doctests, modifying the prereq script appropriately. - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: sage-4.3.1.rc0 released!
Robert, On Jan 24, 5:29 pm, Robert Bradshaw rober...@math.washington.edu wrote: On Jan 22, 2010, at 9:31 AM, Dima Pasechnik wrote: Robert, the advantage is that it will simplify the *development* of Sage. Ironically, I personally find shipping all our dependancies makes development easier--I don't have to worry about someone else using different version than I have, and it's easy to look at and, if need be, patch the source directly. Well, a side-effect of this is Sage shipping old buggy upstream packages (cf. GAP). Right now lots of stoppers seem to come from upstream packages. For porting, yes. Whether or not depending on people to build their own upstream packages, then dealing with the issuing dependancy issues is a gain is up for debate. Probably depends on the package. I also do not see a real problem with specific versions of packages. Somehow, all the other open-source math projects seem to be able to manage this well, e.g. Singular manages to coordinate with GMP. As well, lots of things like needlessly tying Sage up to a very particular version or an environment can be sorted out simply by using autoconf properly... Some packages, like GMP, have a well defined and strongly backwards compatible API. Other packages, like GAP and maxima, aren't even considered libraries, and freely make changes that are semantically inconsequential but change how they interact with the user (which in this case is a pexpect interface, not a human who won't notice when a question is re-phrased). Even when changing versions doesn't give errors or bad results, often doctests will fail. (For example, the Debian port fails doctests all over the place, and trac is full of examples where bumping to a newer upstream version involves non- trivial work.) Still other packages are arcane, specialized sets of C files that where the author has little or no interest (or ability) in getting into or maintaining as part of a mainstream repository archive (if it would even be accepted). I'd love for someone to be able to do apt-get sage, and get a reasonably modern, fully working version (without too much redundancy with what's on their system, especially if that helps us get into debian, etc.) As a concrete goal towards that end, I'd suggest making a stripped version of sage that omits easy packages such as bzip2, zlib, maybe even gmp/mpir that still passes all doctests, modifying the prereq script appropriately. this looks like a good start. Dmitrii - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: sage-4.3.1.rc0 released!
On Jan 24, 2010, at 2:48 AM, Dima Pasechnik wrote: Robert, On Jan 24, 5:29 pm, Robert Bradshaw rober...@math.washington.edu wrote: On Jan 22, 2010, at 9:31 AM, Dima Pasechnik wrote: Robert, the advantage is that it will simplify the *development* of Sage. Ironically, I personally find shipping all our dependancies makes development easier--I don't have to worry about someone else using different version than I have, and it's easy to look at and, if need be, patch the source directly. Well, a side-effect of this is Sage shipping old buggy upstream packages (cf. GAP). For sure. But given that we weren't able to just drop in a more recent upstream and have it just work, doesn't that indicate people's Sage have broken if they were depending on a system-wide one was updated? Right now lots of stoppers seem to come from upstream packages. For porting, yes. Whether or not depending on people to build their own upstream packages, then dealing with the issuing dependancy issues is a gain is up for debate. Probably depends on the package. I also do not see a real problem with specific versions of packages. Somehow, all the other open-source math projects seem to be able to manage this well, e.g. Singular manages to coordinate with GMP. As well, lots of things like needlessly tying Sage up to a very particular version or an environment can be sorted out simply by using autoconf properly... Some packages, like GMP, have a well defined and strongly backwards compatible API. Other packages, like GAP and maxima, aren't even considered libraries, and freely make changes that are semantically inconsequential but change how they interact with the user (which in this case is a pexpect interface, not a human who won't notice when a question is re-phrased). Even when changing versions doesn't give errors or bad results, often doctests will fail. (For example, the Debian port fails doctests all over the place, and trac is full of examples where bumping to a newer upstream version involves non- trivial work.) Still other packages are arcane, specialized sets of C files that where the author has little or no interest (or ability) in getting into or maintaining as part of a mainstream repository archive (if it would even be accepted). I'd love for someone to be able to do apt-get sage, and get a reasonably modern, fully working version (without too much redundancy with what's on their system, especially if that helps us get into debian, etc.) As a concrete goal towards that end, I'd suggest making a stripped version of sage that omits easy packages such as bzip2, zlib, maybe even gmp/mpir that still passes all doctests, modifying the prereq script appropriately. this looks like a good start. Are you volunteering? :) - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: sage-4.3.1.rc0 released!
Hi Dmitrii, OK, I oversimplified. As far as a practical step towards having more flexibility: Presently Sage does not have any mechanism allowing for virtual packages (I am stealing from Debian/Fink here) that would allow for using the already installed, somewhere on the system, non-Sage part of a Sage spkg. It would check if what's already installed satisfies the prerequisites, and if not, (sage -install, say) would pull a replacing full spkg from a Sage repository. Of course in some cases the pre-requisites check is quite tricky, but there are trivial cases, like bzip and mercurial, too... How hard would it be to have such a thing? See below ... Sage has a cross-platform build system and environment. One question that is related to the discussion in this thread is what the situation is with other cross-platform build environments. Of course I know about Debian/Fink/Cygwin/etc., which are specific to different operating systems. Does anybody know of *any* good cross-platform build environments besides Sage? Python + (distutils+distribute+whatever) is such a thing to some extent... Debian packaging/build system is used in Fink (for people unfamiliar with MacOSX:http://www.finkproject.org/) and there is also a FreeBSD port that uses Debian:http://www.debian.org/ports/kfreebsd-gnu/ Thus, yes, Debian is one such cross-platform system. OK, yes, it still needs some OS-specific glue, but not too much, and it runs atop of a Unix shell. By the way, In Haskell there is a build environment (Cabal ?) similar to the Python's... Dmitrii Caution, there's more than meets the eye. I don't get around to write some Wiki page (which is overdue, sigh), so I write it here: Firstly, Sage has a relocatability or prefix-ability, i.e. one can install Sage anywhere in the file system tree where you like. For reasons why one should want this to do in general, read about Case 1 in the following article: http://www.gentoo.org/proj/en/gentoo-alt/prefix/usecases.xml In contrast, official Debian packages want to put their content into fixed locations. Of course, e.g. many autotool-based packages allow for some option --with_prefix= There are even package/install systems to allow for that on a broad scale, like the Tcl-written Darwinports (the brother of Fink), or the Gentoo/Alt prefix project (from which I took the link above). But for Sage, this simply is not enough. Since secondly, this relocatability or prefix-ability of Sage even works after installation! One can install Sage in one subdirectory, and then move its whole subtree elsewhere, and start it up there. After some bookkeeping actions, Sage will work! This is important if you e.g. distribute binary versions of Sage --- you'll never know where the users are going to put it. In this case, Sage is not built from source, and the sources of all the non-core spkgs are not contained in the Sage binary distributions, so you just can't re- install issuing another ./configure --with_prefix=SOME_OTHER_PLACE make make install sequences. Some users of Sage don't even have a C compiler installed anywhere on their system --- and they don't need to, in order to use Sage! This double nature of Sage being distributable both as source as well as pure binary is quite challenging, but rewarding. I hope you understand now, that the notion of virtual packages does not fit too well in the Sage eco-system. OTOH, such a kind of flexibility should be possible of course ... but not as easily as it might seem. Cheers, Georg -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: sage-4.3.1.rc0 released!
Hi Georg, On Jan 24, 1:24 am, Georg S. Weber georgswe...@googlemail.com wrote: Hi Dmitrii, OK, I oversimplified. As far as a practical step towards having more flexibility: Presently Sage does not have any mechanism allowing for virtual packages (I am stealing from Debian/Fink here) that would allow for using the already installed, somewhere on the system, non-Sage part of a Sage spkg. It would check if what's already installed satisfies the prerequisites, and if not, (sage -install, say) would pull a replacing full spkg from a Sage repository. Of course in some cases the pre-requisites check is quite tricky, but there are trivial cases, like bzip and mercurial, too... How hard would it be to have such a thing? See below ... Sage has a cross-platform build system and environment. One question that is related to the discussion in this thread is what the situation is with other cross-platform build environments. Of course I know about Debian/Fink/Cygwin/etc., which are specific to different operating systems. Does anybody know of *any* good cross-platform build environments besides Sage? Python + (distutils+distribute+whatever) is such a thing to some extent... Debian packaging/build system is used in Fink (for people unfamiliar with MacOSX:http://www.finkproject.org/) and there is also a FreeBSD port that uses Debian:http://www.debian.org/ports/kfreebsd-gnu/ Thus, yes, Debian is one such cross-platform system. OK, yes, it still needs some OS-specific glue, but not too much, and it runs atop of a Unix shell. By the way, In Haskell there is a build environment (Cabal ?) similar to the Python's... Dmitrii Caution, there's more than meets the eye. I don't get around to write some Wiki page (which is overdue, sigh), so I write it here: Firstly, Sage has a relocatability or prefix-ability, i.e. one can install Sage anywhere in the file system tree where you like. For reasons why one should want this to do in general, read about Case 1 in the following article: http://www.gentoo.org/proj/en/gentoo-alt/prefix/usecases.xml In contrast, official Debian packages want to put their content into fixed locations. Of course, e.g. many autotool-based packages allow for some option --with_prefix= There are even package/install systems to allow for that on a broad scale, like the Tcl-written Darwinports (the brother of Fink), or the Gentoo/Alt prefix project (from which I took the link above). But for Sage, this simply is not enough. well, this does not mean that upstream packages, the source of which cannot be modified by sage, must migrate with the Sage installation... If you make a soft link to, say, /usr/lib/blah in a directory /tmp/z, and then move or copy /tmp/z somewhere, the link survives. Since secondly, this relocatability or prefix-ability of Sage even works after installation! One can install Sage in one subdirectory, and then move its whole subtree elsewhere, and start it up there. After some bookkeeping actions, Sage will work! This is important if you e.g. distribute binary versions of Sage --- you'll never know where the users are going to put it. In this case, Sage is not built from source, and the sources of all the non-core spkgs are not contained in the Sage binary distributions, so you just can't re- install issuing another ./configure --with_prefix=SOME_OTHER_PLACE make make install sequences. I don't see how this makes impossible for, say, a Linux x86 binary Sage distro to use bzip installed system-wide... Some users of Sage don't even have a C compiler installed anywhere on their system --- and they don't need to, in order to use Sage! This double nature of Sage being distributable both as source as well as pure binary is quite challenging, but rewarding. I hope you understand now, that the notion of virtual packages does not fit too well in the Sage eco-system. OTOH, such a kind of flexibility should be possible of course ... but not as easily as it might seem. Cheers, Georg best, Dmitrii -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: sage-4.3.1.rc0 released!
On 2010-Jan-22 02:09:05 -0200, Gonzalo Tornaria torna...@math.utexas.edu wrote: If it could be done with gfortran, it can be done with other dependencies. Well, gfortran was included for some targets only. Having to include gfortran (and support libraries) for all supported targets would definitely and unnecessarily bloat Sage. On 2010-Jan-22 06:41:33 +, Dr. David Kirkby david.kir...@onetel.net wrote: But tell me what perl modules are needed. If 1) There is some agreeemnt to exit if they do not exist AND If they are necessary for Sage to build, the sooner Sage dies the better. 2) There is some reasonably simple way of checking for them, server% perl -e 'eval use strict;1; ? print Yes\n : print No\n;' Yes server% perl -e 'eval use Foo:Bar;1; ? print Yes\n : print No\n;' No server% if perl -e 'exit eval use Foo::Bar;1;' ; then echo Not Found ;else echo Found;fi Not Found server% if perl -e 'exit eval use strict;1;' ; then echo Not Found ;else echo Found;fi Found server% -- Peter Jeremy pgpyujVrOnuwf.pgp Description: PGP signature
Re: [sage-devel] Re: sage-4.3.1.rc0 released!
William Stein wrote:
But tell me what perl modules are needed. If
1) There is some agreeemnt to exit if they do not exist AND
2) There is some reasonably simple way of checking for them,
IIRC, the only place perl is used in all of Sage is for the PARI and
NTL build systems.
I don't know what that implies about needed modules though.
This is incorrect. R needs perl of at least 5.8.0
configure.ac has:
if test ${r_cv_prog_perl_v5} != yes; then
AC_MSG_ERROR([Building R requires Perl = 5.8.0])
fi
Since that was released in 2002, there should be no problem with people having
that.
Dave
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
[sage-devel] Re: sage-4.3.1.rc0 released!
Robert, the advantage is that it will simplify the *development* of Sage. Right now lots of stoppers seem to come from upstream packages. I also do not see a real problem with specific versions of packages. Somehow, all the other open-source math projects seem to be able to manage this well, e.g. Singular manages to coordinate with GMP. As well, lots of things like needlessly tying Sage up to a very particular version or an environment can be sorted out simply by using autoconf properly... IMHO... Dmitrii On Jan 22, 4:05 am, Robert Bradshaw rober...@math.washington.edu wrote: On Jan 21, 2010, at 6:31 AM, Gonzalo Tornaria wrote: On Wed, Jan 20, 2010 at 5:47 PM, Peter Jeremy peterjer...@acm.org wrote: My personal feeling is that it would be nice if some of the more generic packages (eg bzip, zlib, readline, mercurial) were moved out of sage and made explicit requirements. +1 I think Sage is mature enough now to slowly migrate toward this. Besides, there can still be spkgs for those packages, and there could be a sage-with-batteries-included tarball with dependencies included. What would be the advantage? The easier it is for users to go from a standard distro/OS X box to a running Sage the better. Also, there's the much more important Windows port to consider. One of the reasons we ship our own of so much stuff is that we require specific versions (e.g. you can't just drop in a new version of pari, maxima, or gap, and have it Just Work). Is that an issue for any of the above packages? Also, we require the dev versions of the above packages, not just binaries (which is what many systems come with). - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: sage-4.3.1.rc0 released!
On Fri, Jan 22, 2010 at 9:31 AM, Dima Pasechnik dimp...@gmail.com wrote: Robert, the advantage is that it will simplify the *development* of Sage. Right now lots of stoppers seem to come from upstream packages. I also do not see a real problem with specific versions of packages. Somehow, all the other open-source math projects seem to be able to manage this well, e.g. Singular manages to coordinate with GMP. As well, lots of things like needlessly tying Sage up to a very particular version or an environment can be sorted out simply by using autoconf properly... I so wish you were right!The programs you refer to like Singular are very simple and tiny compared to Sage. If things were so easy as you think, somebody would already have set things up so one can do things that way. Nothing is stopping anyway from doing that now. Let me repeat my remark to Gonzalo, but to you -- how would we actually do what you're suggesting? Could you lay out a somewhat detailed step-by-step plan, with estimates of how much work each step would be to carry out and maintain in the long run, which platforms would be supported, which packages would be removed when, etc.? -- William IMHO... Dmitrii On Jan 22, 4:05 am, Robert Bradshaw rober...@math.washington.edu wrote: On Jan 21, 2010, at 6:31 AM, Gonzalo Tornaria wrote: On Wed, Jan 20, 2010 at 5:47 PM, Peter Jeremy peterjer...@acm.org wrote: My personal feeling is that it would be nice if some of the more generic packages (eg bzip, zlib, readline, mercurial) were moved out of sage and made explicit requirements. +1 I think Sage is mature enough now to slowly migrate toward this. Besides, there can still be spkgs for those packages, and there could be a sage-with-batteries-included tarball with dependencies included. What would be the advantage? The easier it is for users to go from a standard distro/OS X box to a running Sage the better. Also, there's the much more important Windows port to consider. One of the reasons we ship our own of so much stuff is that we require specific versions (e.g. you can't just drop in a new version of pari, maxima, or gap, and have it Just Work). Is that an issue for any of the above packages? Also, we require the dev versions of the above packages, not just binaries (which is what many systems come with). - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: sage-4.3.1.rc0 released!
William Stein wrote: On Fri, Jan 22, 2010 at 9:31 AM, Dima Pasechnikdimp...@gmail.com wrote: Robert, the advantage is that it will simplify the *development* of Sage. Right now lots of stoppers seem to come from upstream packages. I also do not see a real problem with specific versions of packages. Somehow, all the other open-source math projects seem to be able to manage this well, e.g. Singular manages to coordinate with GMP. As well, lots of things like needlessly tying Sage up to a very particular version or an environment can be sorted out simply by using autoconf properly... I so wish you were right!The programs you refer to like Singular are very simple and tiny compared to Sage. If things were so easy as you think, somebody would already have set things up so one can do things that way. Nothing is stopping anyway from doing that now. Happens that Singular is a stumbling stone in the port of Sage to Open Solaris 64 bit! As it comes to building libsingular I have no clue at the moment. Jaap -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: sage-4.3.1.rc0 released!
Jaap Spies wrote:
William Stein wrote:
On Fri, Jan 22, 2010 at 9:31 AM, Dima Pasechnikdimp...@gmail.com
wrote:
Robert,
the advantage is that it will simplify the *development* of Sage.
Right now lots of stoppers seem to come from upstream packages.
I also do not see a real problem with specific versions of
packages. Somehow,
all the other open-source math projects seem to be able to manage this
well,
e.g. Singular manages to coordinate with GMP.
As well, lots of things like needlessly tying Sage up to a very
particular version or
an environment can be sorted out simply by using autoconf properly...
I so wish you were right!The programs you refer to like Singular
are very simple and tiny compared to Sage. If things were so easy as
you think, somebody would already have set things up so one can do
things that way. Nothing is stopping anyway from doing that now.
Happens that Singular is a stumbling stone in the port of Sage to
Open Solaris 64 bit! As it comes to building libsingular I have no clue at
the moment.
Jaap
I'll help you on that, but I need to sort out the 'prereq' script and now feel I
need to devote some time to trying to fix this issue created somewhere between
4.3 and 4.3.1, where the SPARC port got broken.
It looks like there are plenty of patches to singular: spkg-install contains
patch()
{
# work-around patches
cp patches/mminit.cc src/kernel/
cp patches/assert.h src/factory/
cp patches/kernel.rmodulon.cc src/kernel/rmodulon.cc
cp patches/src.Singular.Makefile.in src/Singular/Makefile.in
cp patches/Singular.libsingular.h src/Singular/libsingular.h
cp patches/factory.GNUmakefile.in src/factory/GNUmakefile.in
cp patches/libfac.charset.alg_factor.cc src/libfac/charset/alg_factor.cc
cp patches/kernel.Makefile.in src/kernel/Makefile.in
cp patches/Singular.Makefile.in src/Singular/Makefile.in
cp patches/Singular.tesths.cc src/Singular/tesths.cc
#cp patches/Singular.configure src/Singular/configure
#cp patches/Singular.configure.in src/Singular/configure.in
}
I suspect some of them have GNUisms in them, though this does build 32-bit
SPARC.
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
[sage-devel] Re: sage-4.3.1.rc0 released!
Dr. David Kirkby wrote:
Jaap Spies wrote:
William Stein wrote:
On Fri, Jan 22, 2010 at 9:31 AM, Dima Pasechnikdimp...@gmail.com
wrote:
Robert,
the advantage is that it will simplify the *development* of Sage.
Right now lots of stoppers seem to come from upstream packages.
I also do not see a real problem with specific versions of
packages. Somehow,
all the other open-source math projects seem to be able to manage this
well,
e.g. Singular manages to coordinate with GMP.
As well, lots of things like needlessly tying Sage up to a very
particular version or
an environment can be sorted out simply by using autoconf properly...
I so wish you were right! The programs you refer to like Singular
are very simple and tiny compared to Sage. If things were so easy as
you think, somebody would already have set things up so one can do
things that way. Nothing is stopping anyway from doing that now.
Happens that Singular is a stumbling stone in the port of Sage to
Open Solaris 64 bit! As it comes to building libsingular I have no
clue at
the moment.
Jaap
I'll help you on that, but I need to sort out the 'prereq' script and
now feel I need to devote some time to trying to fix this issue created
somewhere between 4.3 and 4.3.1, where the SPARC port got broken.
It looks like there are plenty of patches to singular: spkg-install
contains
patch()
{
# work-around patches
cp patches/mminit.cc src/kernel/
cp patches/assert.h src/factory/
cp patches/kernel.rmodulon.cc src/kernel/rmodulon.cc
cp patches/src.Singular.Makefile.in src/Singular/Makefile.in
cp patches/Singular.libsingular.h src/Singular/libsingular.h
cp patches/factory.GNUmakefile.in src/factory/GNUmakefile.in
cp patches/libfac.charset.alg_factor.cc src/libfac/charset/alg_factor.cc
cp patches/kernel.Makefile.in src/kernel/Makefile.in
cp patches/Singular.Makefile.in src/Singular/Makefile.in
cp patches/Singular.tesths.cc src/Singular/tesths.cc
#cp patches/Singular.configure src/Singular/configure
#cp patches/Singular.configure.in src/Singular/configure.in
}
I suspect some of them have GNUisms in them, though this does build
32-bit SPARC.
Hi,
Singular as such is no problem. It is building libsingular that fails!
malb to the rescue?
Good luck with the SPARC port!
Jaap
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Re: sage-4.3.1.rc0 released!
On Fri, Jan 22, 2010 at 10:37 AM, Jaap Spies j.sp...@hccnet.nl wrote: William Stein wrote: On Fri, Jan 22, 2010 at 9:31 AM, Dima Pasechnikdimp...@gmail.com wrote: Robert, the advantage is that it will simplify the *development* of Sage. Right now lots of stoppers seem to come from upstream packages. I also do not see a real problem with specific versions of packages. Somehow, all the other open-source math projects seem to be able to manage this well, e.g. Singular manages to coordinate with GMP. As well, lots of things like needlessly tying Sage up to a very particular version or an environment can be sorted out simply by using autoconf properly... I so wish you were right! The programs you refer to like Singular are very simple and tiny compared to Sage. If things were so easy as you think, somebody would already have set things up so one can do things that way. Nothing is stopping anyway from doing that now. Happens that Singular is a stumbling stone in the port of Sage to Open Solaris 64 bit! As it comes to building libsingular I have no clue at the moment. Even things that are relative simple aren't very simple. Sage has a cross-platform build system and environment. One question that is related to the discussion in this thread is what the situation is with other cross-platform build environments. Of course I know about Debian/Fink/Cygwin/etc., which are specific to different operating systems. Does anybody know of *any* good cross-platform build environments besides Sage?Python + (distutils+distribute+whatever) is such a thing to some extent... William -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: sage-4.3.1.rc0 released!
On Fri, Jan 22, 2010 at 10:37 AM, Jaap Spies j.sp...@hccnet.nl wrote: William Stein wrote: On Fri, Jan 22, 2010 at 9:31 AM, Dima Pasechnikdimp...@gmail.com wrote: Robert, the advantage is that it will simplify the *development* of Sage. Right now lots of stoppers seem to come from upstream packages. I also do not see a real problem with specific versions of packages. Somehow, all the other open-source math projects seem to be able to manage this well, e.g. Singular manages to coordinate with GMP. As well, lots of things like needlessly tying Sage up to a very particular version or an environment can be sorted out simply by using autoconf properly... I so wish you were right! The programs you refer to like Singular are very simple and tiny compared to Sage. If things were so easy as you think, somebody would already have set things up so one can do things that way. Nothing is stopping anyway from doing that now. Happens that Singular is a stumbling stone in the port of Sage to Open Solaris 64 bit! As it comes to building libsingular I have no clue at the moment. Even things that are relative simple aren't very simple. Sage has a cross-platform build system and environment. One question that is related to the discussion in this thread is what the situation is with other cross-platform build environments. Of course I know about Debian/Fink/Cygwin/etc., which are specific to different operating systems. Does anybody know of *any* good cross-platform build environments besides Sage?Python is such a thing to some extent... William -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: sage-4.3.1.rc0 released!
William Stein wrote: On Fri, Jan 22, 2010 at 10:37 AM, Jaap Spies j.sp...@hccnet.nl wrote: William Stein wrote: On Fri, Jan 22, 2010 at 9:31 AM, Dima Pasechnikdimp...@gmail.com wrote: Robert, the advantage is that it will simplify the *development* of Sage. Right now lots of stoppers seem to come from upstream packages. I also do not see a real problem with specific versions of packages. Somehow, all the other open-source math projects seem to be able to manage this well, e.g. Singular manages to coordinate with GMP. As well, lots of things like needlessly tying Sage up to a very particular version or an environment can be sorted out simply by using autoconf properly... I so wish you were right!The programs you refer to like Singular are very simple and tiny compared to Sage. If things were so easy as you think, somebody would already have set things up so one can do things that way. Nothing is stopping anyway from doing that now. Happens that Singular is a stumbling stone in the port of Sage to Open Solaris 64 bit! As it comes to building libsingular I have no clue at the moment. Even things that are relative simple aren't very simple. Sage has a cross-platform build system and environment. One question that is related to the discussion in this thread is what the situation is with other cross-platform build environments. Of course I know about Debian/Fink/Cygwin/etc., which are specific to different operating systems. Does anybody know of *any* good cross-platform build environments besides Sage?Python is such a thing to some extent... Not really what you want, but you should be aware of http://en.wikipedia.org/wiki/OpenSUSE_Build_Service which, despite the name, is meant for targeting multiple Linux distributions at once. David C. of NumPy sees this as the big way of distributing scientific Python software in the future. Of course, that's not quite cross-platform enough for Sage, but it is in the same ballpark, and the fundamental problem that is dealt with is probably close enough that perhaps one could extend it to Cygwin and Mac. I don't know if anything related comes out of the http://www.snakebite.org/ project (which I haven't heard about for some time), but I guess that's more about hardware access than the build problem as such. -- Dag Sverre -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: sage-4.3.1.rc0 released!
Dag Sverre Seljebotn wrote: William Stein wrote: On Fri, Jan 22, 2010 at 10:37 AM, Jaap Spies j.sp...@hccnet.nl wrote: William Stein wrote: On Fri, Jan 22, 2010 at 9:31 AM, Dima Pasechnikdimp...@gmail.com wrote: Robert, the advantage is that it will simplify the *development* of Sage. Right now lots of stoppers seem to come from upstream packages. I also do not see a real problem with specific versions of packages. Somehow, all the other open-source math projects seem to be able to manage this well, e.g. Singular manages to coordinate with GMP. As well, lots of things like needlessly tying Sage up to a very particular version or an environment can be sorted out simply by using autoconf properly... I so wish you were right!The programs you refer to like Singular are very simple and tiny compared to Sage. If things were so easy as you think, somebody would already have set things up so one can do things that way. Nothing is stopping anyway from doing that now. Happens that Singular is a stumbling stone in the port of Sage to Open Solaris 64 bit! As it comes to building libsingular I have no clue at the moment. Even things that are relative simple aren't very simple. Sage has a cross-platform build system and environment. One question that is related to the discussion in this thread is what the situation is with other cross-platform build environments. Of course I know about Debian/Fink/Cygwin/etc., which are specific to different operating systems. Does anybody know of *any* good cross-platform build environments besides Sage?Python is such a thing to some extent... Not really what you want, but you should be aware of http://en.wikipedia.org/wiki/OpenSUSE_Build_Service which, despite the name, is meant for targeting multiple Linux distributions at once. David C. of NumPy sees this as the big way of distributing scientific Python software in the future. Of course, that's not quite cross-platform enough for Sage, but it is in the same ballpark, and the fundamental problem that is dealt with is probably close enough that perhaps one could extend it to Cygwin and Mac. Ahemm...and Solaris! Sorry (talk about bad timing...) I don't know if anything related comes out of the http://www.snakebite.org/ project (which I haven't heard about for some time), but I guess that's more about hardware access than the build problem as such. -- Dag Sverre -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: Re: [sage-devel] Re: sage-4.3.1.rc0 released!
CC to [libsingular-devel] to make the Singular development team (which has
been incredibly helpful and supportive in the past!) aware of this discussion.
I so wish you were right!The programs you refer to like Singular
are very simple and tiny compared to Sage. If things were so easy as
you think, somebody would already have set things up so one can do
things that way. Nothing is stopping anyway from doing that now.
Happens that Singular is a stumbling stone in the port of Sage to
Open Solaris 64 bit! As it comes to building libsingular I have no clue
at the moment.
Jaap
I'll help you on that, but I need to sort out the 'prereq' script and now
feel I need to devote some time to trying to fix this issue created
somewhere between 4.3 and 4.3.1, where the SPARC port got broken.
It looks like there are plenty of patches to singular: spkg-install
contains
patch()
{
# work-around patches
cp patches/mminit.cc src/kernel/
cp patches/assert.h src/factory/
cp patches/kernel.rmodulon.cc src/kernel/rmodulon.cc
cp patches/src.Singular.Makefile.in src/Singular/Makefile.in
cp patches/Singular.libsingular.h src/Singular/libsingular.h
cp patches/factory.GNUmakefile.in src/factory/GNUmakefile.in
cp patches/libfac.charset.alg_factor.cc
src/libfac/charset/alg_factor.cc cp patches/kernel.Makefile.in
src/kernel/Makefile.in
cp patches/Singular.Makefile.in src/Singular/Makefile.in
cp patches/Singular.tesths.cc src/Singular/tesths.cc
#cp patches/Singular.configure src/Singular/configure
#cp patches/Singular.configure.in src/Singular/configure.in
}
I suspect some of them have GNUisms in them, though this does build 32-bit
SPARC.
A lot of this is me being lazy and not submitting out fixes upstream. The
development model right now is that I patch whatever I deem necessary for
libsingular to work (e.g. include more header files etc.) and my changes are
then reviewed and (when accepted) applied upstream. This long list indicates,
that I should submit a batch of patches again.
Martin
--
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF
_www: http://www.informatik.uni-bremen.de/~malb
_jab: martinralbre...@jabber.ccc.de
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Re: sage-4.3.1.rc0 released!
Martin Albrecht wrote:
It looks like there are plenty of patches to singular: spkg-install
contains
patch()
{
# work-around patches
cp patches/mminit.cc src/kernel/
cp patches/assert.h src/factory/
cp patches/kernel.rmodulon.cc src/kernel/rmodulon.cc
cp patches/src.Singular.Makefile.in src/Singular/Makefile.in
cp patches/Singular.libsingular.h src/Singular/libsingular.h
cp patches/factory.GNUmakefile.in src/factory/GNUmakefile.in
cp patches/libfac.charset.alg_factor.cc
src/libfac/charset/alg_factor.cc cp patches/kernel.Makefile.in
src/kernel/Makefile.in
cp patches/Singular.Makefile.in src/Singular/Makefile.in
cp patches/Singular.tesths.cc src/Singular/tesths.cc
#cp patches/Singular.configure src/Singular/configure
#cp patches/Singular.configure.in src/Singular/configure.in
}
I suspect some of them have GNUisms in them, though this does build 32-bit
SPARC.
A lot of this is me being lazy and not submitting out fixes upstream. The
development model right now is that I patch whatever I deem necessary for
libsingular to work (e.g. include more header files etc.) and my changes are
then reviewed and (when accepted) applied upstream. This long list indicates,
that I should submit a batch of patches again.
Martin
Thank you for owning up!
Could you check over them, and make sure there is nothing that makes assumptions
about GNU compilers, 32-bit, 64-bit, Linux, or anything else that will messes
up portability. Though I gather the issue is with building the library.
Dave
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
[sage-devel] Re: sage-4.3.1.rc0 released!
William, On Jan 23, 3:37 am, William Stein wst...@gmail.com wrote: On Fri, Jan 22, 2010 at 10:37 AM, Jaap Spies j.sp...@hccnet.nl wrote: William Stein wrote: On Fri, Jan 22, 2010 at 9:31 AM, Dima Pasechnikdimp...@gmail.com wrote: Robert, the advantage is that it will simplify the *development* of Sage. Right now lots of stoppers seem to come from upstream packages. I also do not see a real problem with specific versions of packages. Somehow, all the other open-source math projects seem to be able to manage this well, e.g. Singular manages to coordinate with GMP. As well, lots of things like needlessly tying Sage up to a very particular version or an environment can be sorted out simply by using autoconf properly... I so wish you were right! The programs you refer to like Singular are very simple and tiny compared to Sage. If things were so easy as you think, somebody would already have set things up so one can do things that way. Nothing is stopping anyway from doing that now. OK, I oversimplified. As far as a practical step towards having more flexibility: Presently Sage does not have any mechanism allowing for virtual packages (I am stealing from Debian/Fink here) that would allow for using the already installed, somewhere on the system, non-Sage part of a Sage spkg. It would check if what's already installed satisfies the prerequisites, and if not, (sage -install, say) would pull a replacing full spkg from a Sage repository. Of course in some cases the pre-requisites check is quite tricky, but there are trivial cases, like bzip and mercurial, too... How hard would it be to have such a thing? Happens that Singular is a stumbling stone in the port of Sage to Open Solaris 64 bit! As it comes to building libsingular I have no clue at the moment. Even things that are relative simple aren't very simple. Sage has a cross-platform build system and environment. One question that is related to the discussion in this thread is what the situation is with other cross-platform build environments. Of course I know about Debian/Fink/Cygwin/etc., which are specific to different operating systems. Does anybody know of *any* good cross-platform build environments besides Sage? Python + (distutils+distribute+whatever) is such a thing to some extent... Debian packaging/build system is used in Fink (for people unfamiliar with MacOSX: http://www.finkproject.org/) and there is also a FreeBSD port that uses Debian: http://www.debian.org/ports/kfreebsd-gnu/ Thus, yes, Debian is one such cross-platform system. OK, yes, it still needs some OS-specific glue, but not too much, and it runs atop of a Unix shell. By the way, In Haskell there is a build environment (Cabal ?) similar to the Python's... Dmitrii William -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: sage-4.3.1.rc0 released!
On Wed, Jan 20, 2010 at 5:47 PM, Peter Jeremy peterjer...@acm.org wrote: My personal feeling is that it would be nice if some of the more generic packages (eg bzip, zlib, readline, mercurial) were moved out of sage and made explicit requirements. +1 I think Sage is mature enough now to slowly migrate toward this. Besides, there can still be spkgs for those packages, and there could be a sage-with-batteries-included tarball with dependencies included. Gonzalo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: sage-4.3.1.rc0 released!
On Jan 21, 2010, at 6:31 AM, Gonzalo Tornaria wrote: On Wed, Jan 20, 2010 at 5:47 PM, Peter Jeremy peterjer...@acm.org wrote: My personal feeling is that it would be nice if some of the more generic packages (eg bzip, zlib, readline, mercurial) were moved out of sage and made explicit requirements. +1 I think Sage is mature enough now to slowly migrate toward this. Besides, there can still be spkgs for those packages, and there could be a sage-with-batteries-included tarball with dependencies included. What would be the advantage? The easier it is for users to go from a standard distro/OS X box to a running Sage the better. Also, there's the much more important Windows port to consider. One of the reasons we ship our own of so much stuff is that we require specific versions (e.g. you can't just drop in a new version of pari, maxima, or gap, and have it Just Work). Is that an issue for any of the above packages? Also, we require the dev versions of the above packages, not just binaries (which is what many systems come with). - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: sage-4.3.1.rc0 released!
On Thu, Jan 21, 2010 at 12:05 PM, Robert Bradshaw rober...@math.washington.edu wrote: On Jan 21, 2010, at 6:31 AM, Gonzalo Tornaria wrote: On Wed, Jan 20, 2010 at 5:47 PM, Peter Jeremy peterjer...@acm.org wrote: My personal feeling is that it would be nice if some of the more generic packages (eg bzip, zlib, readline, mercurial) were moved out of sage and made explicit requirements. +1 I think Sage is mature enough now to slowly migrate toward this. Besides, there can still be spkgs for those packages, and there could be a sage-with-batteries-included tarball with dependencies included. What would be the advantage? The easier it is for users to go from a standard distro/OS X box to a running Sage the better. Also, there's the much more important Windows port to consider. One of the reasons we ship our own of so much stuff is that we require specific versions (e.g. you can't just drop in a new version of pari, maxima, or gap, and have it Just Work). Is that an issue for any of the above packages? Also, we require the dev versions of the above packages, not just binaries (which is what many systems come with). - Robert +1 to Robert's comments. I can't tell you how many people just in the last few days have told me that they use (and work on!) Sage *only* because when they try to build it on their computer it just worked. If it hadn't, they definitely wouldn't be involved with Sage now. Removing bzip, zlib, readline, mercurial, etc. is simply going to greatly reduce the chances for such people. I see my goal with the Sage project as *not* to compete with Pari or Singular or Macaulay2 or to try to get users that would otherwise use those systems. My goal is that Sage can compete with programs such as Mathematica which are self-contained and easy to install on many platforms. I want to make Sage something that appeals to users who do not currently use systems like Pari, Singular, etc., because they find installation and usability of those systems too icky. I think http://sagenb.org (and the notebook in general) is a little first step in that direction, but there are many other steps. Make building Sage from source more difficult isn't a good step though. -- William -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: sage-4.3.1.rc0 released!
On Thu, Jan 21, 2010 at 6:05 PM, Robert Bradshaw rober...@math.washington.edu wrote: On Jan 21, 2010, at 6:31 AM, Gonzalo Tornaria wrote: On Wed, Jan 20, 2010 at 5:47 PM, Peter Jeremy peterjer...@acm.org wrote: My personal feeling is that it would be nice if some of the more generic packages (eg bzip, zlib, readline, mercurial) were moved out of sage and made explicit requirements. +1 I think Sage is mature enough now to slowly migrate toward this. Besides, there can still be spkgs for those packages, and there could be a sage-with-batteries-included tarball with dependencies included. What would be the advantage? The easier it is for users to go from a standard distro/OS X box to a running Sage the better. Also, there's the much more important Windows port to consider. In the long run, I think it's way easier if sage actually *comes* with the standard distro / fink / etc. If it could be done with gfortran, it can be done with other dependencies. We didn't see mountains crumbling because of that (I was annoyed as others, but only because the prereq didn't warn me, and because the change was made in the last 24 hours before release). One of the reasons we ship our own of so much stuff is that we require specific versions (e.g. you can't just drop in a new version of pari, maxima, or gap, and have it Just Work). Is that an issue for any of the above packages? Also, we require the dev versions of the above packages, not just binaries (which is what many systems come with). Agreed. The OP didn't suggest to drop those out of sage. I didn't either (not at this stage, anyway). But some of the more generic packages could **slowly** migrate toward this. I don't think there are very specific version needs for bzip, zlib, readline, mercurial, etc. (possibly a newer-than version check, and readline may be icky, etc). If sage could just work with my own distro dev libraries for some of those, that would be a huge step forward, IMO. Once it's doable with a few, the rest will follow at its own pace. Plus, there can *still* be spkgs for all the dependencies. And there could be a sage-with-batteries-included tarball which works just as it does now. And another sage-reduced-for-expert-developers-and-distros tarball which doesn't include the spkgs which can be replaced by distro packages. Even the prereq script could actually *check* the dependencies, and (offer to) download the required spkg !!! (then the tarballs could be named sage-full-install vs. sage-net-install.) IMO sage is mature enough now. Best, Gonzalo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: sage-4.3.1.rc0 released!
On Thu, Jan 21, 2010 at 7:11 PM, William Stein wst...@gmail.com wrote: +1 to Robert's comments. I can't tell you how many people just in the last few days have told me that they use (and work on!) Sage *only* because when they try to build it on their computer it just worked. Do people tell you when they just skip sage because of the massive download and prospect of compiling it? Download 600Mb binary? That's 20% of the monthly allowance for some common adsl plans around here (and I think we have one of the higher levels of internet penetration in latin-america, if not the highest). Getting mathematica is almost cheaper here. Note that I *love* the fact that most of the time I can type make and it just works. Thumbs up for that!!! If it hadn't, they definitely wouldn't be involved with Sage now. Removing bzip, zlib, readline, mercurial, etc. is simply going to greatly reduce the chances for such people. I see my goal with the Sage project as *not* to compete with Pari or Singular or Macaulay2 or to try to get users that would otherwise use those systems. My goal is that Sage can compete with programs such as Mathematica which are self-contained and easy to install on many platforms. I want to make Sage something that appeals to users who do not currently use systems like Pari, Singular, etc., because they find installation and usability of those systems too icky. I think apt-get install pari-gp is the trivialest thing... I haven't compiled pari for eons. Especially because when software matures, it won't affect me as much to not have the bleeding edge release. And hey, compiling pari *also* just worked most of the time. It's not only about being easy to build --- it's also about convincing people it's easy to build, despite the scary looking size of the tarball, and moreover covincing people it's easy to develop, and worth giving code back to the commons!!! Another two thumbs up for that (and metcalfe's law). http://sagenb.org (and the notebook in general) is a little first step More like a big leap, IMO. in that direction, but there are many other steps. Make building Sage from source more difficult isn't a good step though. You are jumping to conclusions. Nobody wants to make building sage from source more difficult. Move back two spaces and read again. It was really meant to be constructive. Best, Gonzalo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: sage-4.3.1.rc0 released!
Gonzalo Tornaria wrote: Plus, there can *still* be spkgs for all the dependencies. And there could be a sage-with-batteries-included tarball which works just as it does now. And another sage-reduced-for-expert-developers-and-distros tarball which doesn't include the spkgs which can be replaced by distro packages. Even the prereq script could actually *check* the dependencies, and (offer to) download the required spkg !!! (then the tarballs could be named sage-full-install vs. sage-net-install.) IMO sage is mature enough now. Best, Gonzalo I was just going to say that in principle there is nothing stopping sage finding out what it needs, then automatically downloading packages from the sage web site. But I realised you had said it!! But yes, it could be done. But sorting out whether the version of libraries on a system are suitable, can be tricky. Even having the right versions does not guarantee they will be found in preference to some other version. I can see some advantages in not shipping basic things, but I can see that one might need to spend a LOT of time developing the build system to do this. If you are only going to shave off 20 MB or so from the source code, it might be more hassle than it is worth. If you could cut the download time by 30%, then I could see it would probably be worth the effort in doing this. But I'm not so sure you would be able to do that. Too many packages are probably too specialised. An obvious question is whether there would be anyone willing to take on the task of changing this? I for one would not want to. Would anyone else ?? Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: sage-4.3.1.rc0 released!
On Thu, Jan 21, 2010 at 8:09 PM, Gonzalo Tornaria torna...@math.utexas.edu wrote: I think Sage is mature enough now to slowly migrate toward this. Besides, there can still be spkgs for those packages, and there could be a sage-with-batteries-included tarball with dependencies included. What would be the advantage? The easier it is for users to go from a standard distro/OS X box to a running Sage the better. Also, there's the much more important Windows port to consider. In the long run, I think it's way easier if sage actually *comes* with the standard distro / fink / etc. It would be great if you could work on updating the Debian packages for Sage. See http://wiki.sagemath.org/devel/DebianSage Thanks, -- William -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: sage-4.3.1.rc0 released!
On Fri, Jan 22, 2010 at 3:24 AM, Dr. David Kirkby david.kir...@onetel.net wrote: But sorting out whether the version of libraries on a system are suitable, can be tricky. Even having the right versions does not guarantee they will be found in preference to some other version. Sure. We already have related issues. For example, the prereq checks perl is installed, but it doesn't check for some perl modules which are required (but not part of debian's perl-base --- not really needed for anything except building sage). As long as it builds with libraries in current debian / fedora / ubuntu, it's ok. If you are only going to shave off 20 MB or so from the source code, it might be more hassle than it is worth. If you could cut the download time by 30%, then I could see it would probably be worth the effort in doing this. But I'm not so sure you would be able to do that. Too many packages are probably too specialised. sage 3.0.5 was 188MB, but the debian package (binary) was only 42MB. The source for the debian package is 57.6MB. Gonzalo -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: sage-4.3.1.rc0 released!
On Fri, 22 Jan 2010 19:27:56 Gonzalo Tornaria wrote: If you are only going to shave off 20 MB or so from the source code, it might be more hassle than it is worth. If you could cut the download time by 30%, then I could see it would probably be worth the effort in doing this. But I'm not so sure you would be able to do that. Too many packages are probably too specialised. sage 3.0.5 was 188MB, but the debian package (binary) was only 42MB. The source for the debian package is 57.6MB. That's an unfair comparison and you know it. To make a good comparison you have to include all the pulled dependencies that are part of sage. Some like python are probably part of your base system so you are indeed saving on them, but pari, flint, singular those are not really software that will come by default. Francois -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: sage-4.3.1.rc0 released!
Gonzalo Tornaria wrote: On Fri, Jan 22, 2010 at 3:24 AM, Dr. David Kirkby david.kir...@onetel.net wrote: But sorting out whether the version of libraries on a system are suitable, can be tricky. Even having the right versions does not guarantee they will be found in preference to some other version. Sure. We already have related issues. For example, the prereq checks perl is installed, but it doesn't check for some perl modules which are required (but not part of debian's perl-base --- not really needed for anything except building sage). I've made quite a few changes to 'prereq' recently, so I'm probably the best person to make any more changes. I'm certainly willing to do the one to check for Fortran. But tell me what perl modules are needed. If 1) There is some agreeemnt to exit if they do not exist AND 2) There is some reasonably simple way of checking for them, then I can implement a test. As long as it builds with libraries in current debian / fedora / ubuntu, it's ok. Does every Linux user always update to have the latest versions? I doubt it. In some cases, they will not have root access and so can't update. The build process will need to handle properly the cases where the libraries are not right. I think actually testing them might be VERY difficult. If you are only going to shave off 20 MB or so from the source code, it might be more hassle than it is worth. If you could cut the download time by 30%, then I could see it would probably be worth the effort in doing this. But I'm not so sure you would be able to do that. Too many packages are probably too specialised. sage 3.0.5 was 188MB, but the debian package (binary) was only 42MB. The source for the debian package is 57.6MB. Gonzalo I suspect the extra packages added to Sage since 3.0.5 are probably more specialised, so I suspect the saving as a percentage will be a lot less. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: sage-4.3.1.rc0 released!
On Thu, Jan 21, 2010 at 10:41 PM, Dr. David Kirkby david.kir...@onetel.net wrote: Gonzalo Tornaria wrote: On Fri, Jan 22, 2010 at 3:24 AM, Dr. David Kirkby david.kir...@onetel.net wrote: But sorting out whether the version of libraries on a system are suitable, can be tricky. Even having the right versions does not guarantee they will be found in preference to some other version. Sure. We already have related issues. For example, the prereq checks perl is installed, but it doesn't check for some perl modules which are required (but not part of debian's perl-base --- not really needed for anything except building sage). I've made quite a few changes to 'prereq' recently, so I'm probably the best person to make any more changes. I'm certainly willing to do the one to check for Fortran. Thanks! But tell me what perl modules are needed. If 1) There is some agreeemnt to exit if they do not exist AND 2) There is some reasonably simple way of checking for them, IIRC, the only place perl is used in all of Sage is for the PARI and NTL build systems. I don't know what that implies about needed modules though. then I can implement a test. As long as it builds with libraries in current debian / fedora / ubuntu, it's ok. Does every Linux user always update to have the latest versions? I doubt it. In some cases, they will not have root access and so can't update. I agree. In fact, I would guess that the vast majority of Linux accounts on Linux systems are not admin accounts. Such users will then have to build the relevant libraries (such as readline, etc.) in their own $HOME/local tree, succeed in getting Sage to recognize their non-standard libraries, etc. The build process will need to handle properly the cases where the libraries are not right. I think actually testing them might be VERY difficult. Yes, that worries me too. Incidentally, when I used to hang out with John Cannon and have discussions in which I tried to convince him to open source Magma, one of his biggest concerns was that supporting thousands of users building Magma from source would be too difficult. Magma is about half the size of Sage (in terms of lines of code). Gonzalo, how would we actually do what you're suggesting? Could you lay out a somewhat detailed step-by-step plan, with estimates of how much work each step would be to carry out and maintain in the long run, which platforms would be supported, which packages would be removed when, etc.? I'm worried that this discussion is going nowhere due to lack of specifics and all sides being worried about nebulous unclear fears. -- William -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: sage-4.3.1.rc0 released!
On 2010-Jan-17 04:53:11 +, Dr. David Kirkby david.kir...@onetel.net wrote: Could an argument not be made to the Debian people that the code is gap singular etc, but patched versions of them. Call them Foo and Bar if necessary! No seriously, I can understand them not wanting 'standard' things packaged, but if the items are significantly modified from the 'standard' distribution, then there seems to be an valid argument for it being available. The key phrase here is significantly modified. The FreeBSD ports system works in much the same way: The basic idea is that application dependencies get factored out so that you have (eg) one copy of Python installed instead of every app that wants Python installing its own. The benefit is that you don't wind up with a tree full of dozens of copies of perl, python etc _and_ you don't wind up with the libgcrypt problems that Solaris is suffering because Sage is getting confused as to which libgcrypt it is supposed to be using. The downside is that if something like Sage relies on the idiosyncracies of a particular version of the application, it can cause problems when a different generic version is installed. As for the patches, they fall into two categories: a) patches to make the application run on the OS b) patches to make the application interface to Sage The former category is irrelevant because the OS version of the package will have similar patches. The latter category _can_ be an issue. Currently, Sage includes most (but not all) of the packages it needs (bash, gnu make and a Fortran compiler are the most obvious exceptions). Whilst this helps with integration, it makes Sage bigger and slower to build or download, as well as requiring someone who is porting Sage to re-engineer all the OS-dependent patches. My personal feeling is that it would be nice if some of the more generic packages (eg bzip, zlib, readline, mercurial) were moved out of sage and made explicit requirements. -- Peter Jeremy pgp4h8gNfaYgn.pgp Description: PGP signature
[sage-devel] Re: sage-4.3.1.rc0 released!
I understand that Debian support is on hold. AFAIK, a proper Debian requires a complete refactoring of the code, in particular removing all the things that are not really Sage, e.g. mercurial, gap, singular, etc etc etc. I understand it has been done at some point for Sage 3, but then the main person who did that got a real job and dropped out. One can certainly package Sage as a .deb, but does this make much sense? Best, Dmitrii On Jan 17, 12:22 am, ma...@mendelu.cz ma...@mendelu.cz wrote: [...] Thanks. Binaries for current Debian are not available from (I think) Sage 4.3. Is Debian still supported? Will you build Sage 4.3.1 binaries for Debian Lenny? Thanks Robert Marik -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: sage-4.3.1.rc0 released!
Dima Pasechnik wrote: I understand that Debian support is on hold. AFAIK, a proper Debian requires a complete refactoring of the code, in particular removing all the things that are not really Sage, e.g. mercurial, gap, singular, etc etc etc. I understand it has been done at some point for Sage 3, but then the main person who did that got a real job and dropped out. One can certainly package Sage as a .deb, but does this make much sense? Best, Dmitrii Could an argument not be made to the Debian people that the code is gap singular etc, but patched versions of them. Call them Foo and Bar if necessary! No seriously, I can understand them not wanting 'standard' things packaged, but if the items are significantly modified from the 'standard' distribution, then there seems to be an valid argument for it being available. In the case of Mercical, there is probably some logic to not distributing that. I assume it is only of need to developers, and it is pretty easy to install. drkir...@hawk:~/sage-4.3.1.rc0/spkg/standard$ ls *.spkg | wc 93 932065 drkir...@hawk:~/sage-4.3.1.rc0/spkg/standard$ ls *.p[0-9].spkg | wc 67 671507 shows 67 of the 93 packages in standard are patched. But in many cases, even those that have no patch number will have patches. Ultimately, if you make a .deb, and someone wants to install it, should you really care what the Debian maintainers feel? -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: sage-4.3.1.rc0 released!
2010/1/16 Dima Pasechnik dimp...@gmail.com: I understand that Debian support is on hold. AFAIK, a proper Debian requires a complete refactoring of the code, in particular removing all the things that are not really Sage, e.g. mercurial, gap, singular, etc etc etc. I understand it has been done at some point for Sage 3, but then the main person who did that got a real job and dropped out. One can certainly package Sage as a .deb, but does this make much sense? You're answering the wrong question. Sage fully supports Debian through binaries we build. We just don't provide deb's integrated into their distro. William Best, Dmitrii On Jan 17, 12:22 am, ma...@mendelu.cz ma...@mendelu.cz wrote: [...] Thanks. Binaries for current Debian are not available from (I think) Sage 4.3. Is Debian still supported? Will you build Sage 4.3.1 binaries for Debian Lenny? Thanks Robert Marik -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: sage-4.3.1.rc0 released!
On Jan 17, 12:53 pm, Dr. David Kirkby david.kir...@onetel.net wrote: Dima Pasechnik wrote: I understand that Debian support is on hold. AFAIK, a proper Debian requires a complete refactoring of the code, in particular removing all the things that are not really Sage, e.g. mercurial, gap, singular, etc etc etc. I understand it has been done at some point for Sage 3, but then the main person who did that got a real job and dropped out. One can certainly package Sage as a .deb, but does this make much sense? Best, Dmitrii Could an argument not be made to the Debian people that the code is gap singular etc, but patched versions of them. Call them Foo and Bar if necessary! No seriously, I can understand them not wanting 'standard' things packaged, but if the items are significantly modified from the 'standard' distribution, then there seems to be an valid argument for it being available. unfortunately, some items, e.g. GAP, are not just modified, but old and buggy. On GAP support lists noone would take questions on GAP 4.4.10, the release currently used by Sage. Try to sell this to Debian... [well, what I do in GAP is affected by the upgade to 4.4.12 that has not made it into Sage yet, so I can't so that's perhaps why I sound too agitated on this...] Moreover, I want to call cvxopt with data obtained in GAP (and get some answers back). But cvxopt in Sage is also old and buggy! They had gone to version 1 already quite a while ago, and all the documentation now is for version 1. Well, this, unlike GAP, requires some substantial porting in few places; but still, I am stuck documentation-less, at least... By the way, both lastest GAP and latest cvxopt are in Debian (unstable). - And inclusion of, e.g. bzip, or python itself, is just bizzare... In the case of Mercical, there is probably some logic to not distributing that. I assume it is only of need to developers, and it is pretty easy to install. drkir...@hawk:~/sage-4.3.1.rc0/spkg/standard$ ls *.spkg | wc 93 93 2065 drkir...@hawk:~/sage-4.3.1.rc0/spkg/standard$ ls *.p[0-9].spkg | wc 67 67 1507 shows 67 of the 93 packages in standard are patched. But in many cases, even those that have no patch number will have patches. Ultimately, if you make a .deb, and someone wants to install it, should you really care what the Debian maintainers feel? surely, .deb format is free, you are welcome to use it... Dmitrii -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: sage-4.3.1.rc0 released!
2010/1/16 Dima Pasechnik dimp...@gmail.com: On Jan 17, 12:53 pm, Dr. David Kirkby david.kir...@onetel.net wrote: Dima Pasechnik wrote: I understand that Debian support is on hold. AFAIK, a proper Debian requires a complete refactoring of the code, in particular removing all the things that are not really Sage, e.g. mercurial, gap, singular, etc etc etc. I understand it has been done at some point for Sage 3, but then the main person who did that got a real job and dropped out. One can certainly package Sage as a .deb, but does this make much sense? Best, Dmitrii Could an argument not be made to the Debian people that the code is gap singular etc, but patched versions of them. Call them Foo and Bar if necessary! No seriously, I can understand them not wanting 'standard' things packaged, but if the items are significantly modified from the 'standard' distribution, then there seems to be an valid argument for it being available. unfortunately, some items, e.g. GAP, are not just modified, but old and buggy. On GAP support lists noone would take questions on GAP 4.4.10, the release currently used by Sage. Try to sell this to Debian... A fully debianized Sage would (does?) use whatever Gap version is in Debian. [well, what I do in GAP is affected by the upgade to 4.4.12 that has not made it into Sage yet, so I can't so that's perhaps why I sound too agitated on this...] Two weeks ago GAP was broken. You worked on it (thanks!!!), and learned that there was a major bug that impacted one of our fully supported architectures. Steve Linton fixed the bug and issued a patch, which you helped integrate in Sage. We haven't released the next version of Sage yet, but it should I hope contain the new version of GAP. Moreover, I want to call cvxopt with data obtained in GAP (and get some answers back). But cvxopt in Sage is also old and buggy! They had gone to version 1 already quite a while ago, and all the documentation now is for version 1. Well, this, unlike GAP, requires some substantial porting in few places; but still, I am stuck documentation-less, at least... Why do you think it will take substantial porting in few places to get cvxopt to work with Sage? It sounds like you've worked on this. Thanks! Like with GAP, your contributions would be greatly appreciated in getting cvxopt updated. The only reasons it hasn't been updated so far is because there haven't been any really serious sage + cvxopt users yet... but with you now there is one.You're the guy to update that. William -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
