Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
Le 21/02/2015 11:15, Volker Braun a écrit : I agree that we should have some user configuration mechanism to customize how we build packages (including replacing sage packages with distro dependencies), but going about it by patching Sage or adding $DISTRO subdirectories everywhere are crap. Something like yaml config files (e.g. hashdist) is imho the way to go. Felix Salfelder did a GSOC about using a configure script. Snark on #sagemath -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
On Saturday, February 21, 2015 at 3:09:58 PM UTC+1, Felix Salfelder wrote: as it seems, hardly anybody (and about zero of the core developers) from the sage community wants to make use of system-installed packages (except for maybe gcc, ssl and whatnot). That is not true. What is true is that none of the core developers wants to make their life even more difficult so that the debian packages have less to do. At the bottom of it, it is a social rather than a technical problem. You need to convince people that you have a better way, and be able to listen to upstream projects. Trying to rip out cythonize() because automake doesn't do wildcards? And you are surprised that this did not make it upstream? Are you also surprised that our tanks were not received with open arms on the streets of Baghdad? ;-) -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
On Saturday, February 21, 2015 at 3:42:28 AM UTC+1, Michael Orlitzky wrote: On 02/20/2015 11:02 AM, kcrisman wrote: I no longer use sage for my day-to-day work, but when I was and I had to e.g. give a presentation, it was infuriating to find sage broken AGAIN ??? I assume this is because you updated some dependency and Sage didn't work quite properly somewhere in its bowels with that? I've never once had that happen with Sage on Mac, since it is a distribution by necessity there. To me that sounds like an argument for installing sage-the-distribution, because I assume this could happen with any software that has a dependency, before upstream had repackaged based on that updated dependency. I may be misunderstanding something in your argument, though. It happens when I update something that is a sage dependency, but for which there is no spkg. All of the C code that we ship depends on glibc, but we don't ship an spkg for glibc. When I update glibc, sage begins to segfault until I rebuild every spkg and the sage library. There are two ways to fix that: first, we could bundle literally an entire Linux distribution down to the kernel. Or, we could make sage play nice with package managers and let the package manager reinstall (i.e. rebuild) any parts of sage that are broken by the update. The first solution duplicates an enormous amount of effort that Linux distros have already put forth. It makes the sage download half a gigabyte instead of a few megabytes. It creates security problems -- now I have two version of openssl on my machine, and nobody updates the sage copy. It causes the sage build process to take 4 hours instead of 5 minutes. It makes installation much harder for users who are used to doing yum install sage. It ensures that system administrators won't go near it, so sage can't be installed once globally on the department server. The second has none of those problems, but we can't depend on silent forks of packages. I don't think there are very many packages where we really need to have a full-fledged fork. Pari may be one of them, who knows. But if we need to fork it we should just fork it and rename all of the libs and get it over with. I find that really surprising! I run Arch linux so more or less all packages are upgraded on a weekly to monthly basis. Besides the package manager, I keep a stable installation of Sage that I don't touch so often, maybe for 6-9 months at a time, so that I always have something on which to do computations. I have never once experienced segfaults as you describe... -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
I agree that we should have some user configuration mechanism to customize how we build packages (including replacing sage packages with distro dependencies), but going about it by patching Sage or adding $DISTRO subdirectories everywhere are crap. Something like yaml config files (e.g. hashdist) is imho the way to go. On Saturday, February 21, 2015 at 3:42:28 AM UTC+1, Michael Orlitzky wrote: minutes. It makes installation much harder for users who are used to doing yum install sage $ yum info sagemath [...] Available Packages Name: sagemath Arch: i686 Version : 6.3 Release : 5.fc21 Size: 150 k Repo: updates/21/x86_64 Summary : A free open-source mathematics software system URL : http://www.sagemath.org License : ASL 2.0 and BSD and GPL+ and GPLv2+ and LGPLv2+ and MIT and Public Domain Description : Sage is a free open-source mathematics software system licensed : under the GPL. It combines the power of many existing open-source : packages into a common Python-based interface. Name: sagemath Arch: x86_64 Version : 6.3 Release : 5.fc21 Size: 150 k Repo: updates/21/x86_64 Summary : A free open-source mathematics software system URL : http://www.sagemath.org License : ASL 2.0 and BSD and GPL+ and GPLv2+ and LGPLv2+ and MIT and Public Domain Description : Sage is a free open-source mathematics software system licensed : under the GPL. It combines the power of many existing open-source : packages into a common Python-based interface. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
Hi Volker. actually i anticipate that you know better. anyway i reply. again. just for the record. On Sat, Feb 21, 2015 at 06:55:26AM -0800, Volker Braun wrote: That is not true. What is true is that none of the core developers wants to make their life even more difficult so that the debian packages have less to do. this is *not* *about* *debian*. only about 1/3 of linux installations are debian based. a lot of distributions are not even based on any other. sage does not only run on linux. go figure. At the bottom of it, it is a social rather than a technical problem. You need to convince people that you have a better way, and be able to listen to upstream projects. at no time did i have a better way to do what you do. i wanted to try something else. somehing more straightforward. i listened to upstream and i have dropped the idea (see my last mail). still i do not know which other way might have done the trick. for the very least i did not try to move to portage. conversation could have been more productive. Trying to rip out cythonize() because automake doesn't do wildcards? i fell back to automake, because cythonize does not support dependency tracking. does it today? don't know. needless to say that i have asked for alternatives. out-of-tree builds solved a different set of problems. afaik, the recompile-everything-everytime issue stroke back a few months ago... while i tried to address some of these issues (yes, the technical side), i learned that - modularisation is evil - libgap is necessary and must pretend to be gap - tabs are bad and so are makefiles - autotools releases must be pulled from git - capitalization is important and maybe other surprising or interesting things that i forgot about (still, thanks for the useful input!). and again: in which way does autotools not support wildcards? i guess you are pointing to the fact that i did not want to rely on them. just add it to the list above. And you are surprised that this did not make it upstream? no. should i? this was never complete nor will it be of any use for the better-bootstrap-the-universe folks. it is not your obligation to support or even think any of this. sage is a great/interesting piece of software. sure, attempts to package (with or without help from upstream) will not die down. it is a matter of how to deal with external ideas, needs and resources. hopefully, my project will serve as a warning to others and eventually justify a fork that avoids sage-the-distribution completely. just sagelib alone is considerably simpler to deal with. for packaging you don't need dependency tracking *hint hint*. all the best felix -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
Followups to sage-flame please... On Saturday, February 21, 2015 at 6:14:33 PM UTC+1, Felix Salfelder wrote: Hi Volker. actually i anticipate that you know better. anyway i reply. again. just for the record. On Sat, Feb 21, 2015 at 06:55:26AM -0800, Volker Braun wrote: That is not true. What is true is that none of the core developers wants to make their life even more difficult so that the debian packages have less to do. this is *not* *about* *debian*. only about 1/3 of linux installations are debian based. a lot of distributions are not even based on any other. sage does not only run on linux. go figure. At the bottom of it, it is a social rather than a technical problem. You need to convince people that you have a better way, and be able to listen to upstream projects. at no time did i have a better way to do what you do. i wanted to try something else. somehing more straightforward. i listened to upstream and i have dropped the idea (see my last mail). still i do not know which other way might have done the trick. for the very least i did not try to move to portage. conversation could have been more productive. Trying to rip out cythonize() because automake doesn't do wildcards? i fell back to automake, because cythonize does not support dependency tracking. does it today? don't know. needless to say that i have asked for alternatives. out-of-tree builds solved a different set of problems. afaik, the recompile-everything-everytime issue stroke back a few months ago... while i tried to address some of these issues (yes, the technical side), i learned that - modularisation is evil - libgap is necessary and must pretend to be gap - tabs are bad and so are makefiles - autotools releases must be pulled from git - capitalization is important and maybe other surprising or interesting things that i forgot about (still, thanks for the useful input!). and again: in which way does autotools not support wildcards? i guess you are pointing to the fact that i did not want to rely on them. just add it to the list above. And you are surprised that this did not make it upstream? no. should i? this was never complete nor will it be of any use for the better-bootstrap-the-universe folks. it is not your obligation to support or even think any of this. sage is a great/interesting piece of software. sure, attempts to package (with or without help from upstream) will not die down. it is a matter of how to deal with external ideas, needs and resources. hopefully, my project will serve as a warning to others and eventually justify a fork that avoids sage-the-distribution completely. just sagelib alone is considerably simpler to deal with. for packaging you don't need dependency tracking *hint hint*. all the best felix -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
On Feb 21, 2015 9:32 AM, Volker Braun vbraun.n...@gmail.com wrote: Followups to sage-flame please... I strongly agree. On Saturday, February 21, 2015 at 6:14:33 PM UTC+1, Felix Salfelder wrote: Hi Volker. actually i anticipate that you know better. anyway i reply. again. just for the record. On Sat, Feb 21, 2015 at 06:55:26AM -0800, Volker Braun wrote: That is not true. What is true is that none of the core developers wants to make their life even more difficult so that the debian packages have less to do. this is *not* *about* *debian*. only about 1/3 of linux installations are debian based. a lot of distributions are not even based on any other. sage does not only run on linux. go figure. At the bottom of it, it is a social rather than a technical problem. You need to convince people that you have a better way, and be able to listen to upstream projects. at no time did i have a better way to do what you do. i wanted to try something else. somehing more straightforward. i listened to upstream and i have dropped the idea (see my last mail). still i do not know which other way might have done the trick. for the very least i did not try to move to portage. conversation could have been more productive. Trying to rip out cythonize() because automake doesn't do wildcards? i fell back to automake, because cythonize does not support dependency tracking. does it today? don't know. needless to say that i have asked for alternatives. out-of-tree builds solved a different set of problems. afaik, the recompile-everything-everytime issue stroke back a few months ago... while i tried to address some of these issues (yes, the technical side), i learned that - modularisation is evil - libgap is necessary and must pretend to be gap - tabs are bad and so are makefiles - autotools releases must be pulled from git - capitalization is important and maybe other surprising or interesting things that i forgot about (still, thanks for the useful input!). and again: in which way does autotools not support wildcards? i guess you are pointing to the fact that i did not want to rely on them. just add it to the list above. And you are surprised that this did not make it upstream? no. should i? this was never complete nor will it be of any use for the better-bootstrap-the-universe folks. it is not your obligation to support or even think any of this. sage is a great/interesting piece of software. sure, attempts to package (with or without help from upstream) will not die down. it is a matter of how to deal with external ideas, needs and resources. hopefully, my project will serve as a warning to others and eventually justify a fork that avoids sage-the-distribution completely. just sagelib alone is considerably simpler to deal with. for packaging you don't need dependency tracking *hint hint*. all the best felix -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
On Saturday, February 21, 2015 at 12:26:26 PM UTC+1, Snark wrote: Felix Salfelder did a GSOC about using a configure script. You keep saying that but it still doesn't work. Nor is it a particularly good way of exposing a lot of configuration options (at least one per package). -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
On Sat, Feb 21, 2015 at 03:58:29AM -0800, Volker Braun wrote: [..] it still doesn't work. you keep saying that. but does it matter? the configuration worked pretty good as a proof-of-concept. i am sorry if your expectations were higher. note that this particular part was just optional within the project ([1] part 2, last item), no more no less. as it seems, hardly anybody (and about zero of the core developers) from the sage community wants to make use of system-installed packages (except for maybe gcc, ssl and whatnot). yet, i did not expect that much headwind. after all the mere attempt of a straightforward bypass implementation has been pretty pointless. in the meantime, i have dropped the top-level part to concentrate on making just sage (the library, the software, the essential part) work for non-(sage-the-distribution or OSX-based) software distributions. the effort makes no sense for sage-the-distribution, where all paths are to stay static and hardcoded. forks are evil and all that, but the build/install now works if the build dependencies are available. it's lagging behind at 6.3-something, i don't use sage currently, and i have other things to do. Nor is it a particularly good way of exposing a lot of configuration options (at least one per package). the intent was to have exactly one option per package. this (would have) allowed to install/develop sage-the-distribution with all foreign packages disabled except pari (hey, this is not even off topic!). may anyone find a better way. good luck felix [1] https://www.google-melange.com/gsoc/project/details/google/gsoc2013/felixs/5779342353235968 -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
Hi, Le 20/02/2015 01:22, William Stein a écrit : On Thu, Feb 19, 2015 at 12:51 PM, Francesco Biscani bluesca...@gmail.com wrote: On 19 February 2015 at 18:05, Julien Puydt julien.pu...@laposte.net wrote: All distributions have thousands of packages, and deps are not a big issue. Sage-the-distribution has about a hundred, and it's a big issue. This is something I have failed to understand so far. What is it that makes Sage require such special handling of dependencies (i.e., package everything in one monolithic blob and with ad-hoc patching)? See http://wiki.sagemath.org/faq/bigsagerant for another past Sage release manager's rant on this topic from long ago (maybe 2008?). == Wouldn't it be way better if Sage did not ship as a gigantic bundle? == This has been discussed over and over again and it plainly doesn't work. The Sage in Debian does not pass doctests, not even close. In general the combinatorial explosion of configurations to debug is way too large and it is next to impossible to find any distribution where the version numbers even remotely match. We updated to GAP 4.4.12 in Sage 3.3 and the doctests involving GAP will in certain files be broken with any previous GAP release. If you used the Debian packages for Singular Sage won't work since we patch NTL and when those NTL libs come in conflict either Sage doesn't compile or Singular blows up. I can go on and on and on about similar issues and that is only the stuff I know about right on top of my head. I have never taken the time to go out and do dumb things to break Sage :) In the near future we plan to upgrade to a svn release of the development version of pari and then closely track it as bugs we report are often only fixed in pari-2.4.3svn. There is *no* way any distribution can track this without potentially breaking other code dependent on pari and you will be royally screwed if you want to use pari 2.3.4 in Sage (the stable release at this point) since Sage won't even build. We will fix all in tree code that gets broken with the new pari-svn and push it back upstream, but until that shows up in a distribution we will long have shipped Sage 4.0. The way we do it is the only way and I have doubts that any distribution packaged Sage will even be able to keep up with the official release given that I (=Michael Abshoff) spend working full time as the Sage release manager :) Yes, the same drama as usual : - sage is incredibly complex = FACTS: all distributions are orders of magnitude more complex - sage has extremely special needs because it's mathematics = FACTS: all software has special needs, and being about mathematics doesn't make it worse -- just put unit tests, we'll run them after the build and no package failing them will get out the door (eclib and flint come to mind as example of good-behaving mathematics software packages) - sage is on the bleeding edge = FACTS: there are quite a few packages where sage can barely keep up with upstream -- see https://people.debian.org/~thansen/debian-sage-dev-status.html - sage needs to be able to use dev versions = FACTS: you can, and please do! But : (1) label them clearly as not upstream versions, and make sure you stay compatible with upstream dev versions so the next upstream stable will be a drop-in replacement to your stuff (pari) (2) if you (plan to) stay away from upstream long, then actually fork upstream with a clear name so we can package in a co-installable form (libgap and cddlib) - debian's sage sucks = FACTS: it did, and now there is none. When there will be, no package won't get out of the door if it doesn't pass doctests. Of course, some of them will be disabled, like those checking paths, or checking that the available color maps in matplotlib is some short list, but that shouldn't matter. There's a lot of complex software around with long dependency chains (Firefox, Chrome, KDE, GNOME, OpenOffice, ...) and it seems like most Linux distributions are able to deal with this, without too many issues, via system-wide libraries. Those are a different domain of software engineering. Mathematics software is fundamentally different than word processing, graphical desktop, and web browser software. It doesn't matter much if a line in a UI is off by one pixel. In mathematics, being off by 1 can result in major bugs all over Sage. Off by one can be a crash in word processing, graphical desktop, web browser software and pretty much anything else : it does matter everywhere. Packagers routinely run make check in their build scripts so they don't ship clearly broken software. The Sage distribution model, which has frequently been attacked every single year for nearly a decade, is one of the most important reasons for Sage's success. Is it a good reason to push third-party packagers around like second-class citizens? Let me quote François Bissey : But some of us would like to be given some consideration. That said,
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
On 2015-02-19 18:54, Michael Orlitzky wrote: On 02/19/2015 11:24 AM, Jeroen Demeyer wrote: On 2015-02-19 16:55, Michael Orlitzky wrote: It's not incompatibility with Debian that's the problem. Having dependencies like whatever was in the git repo at 11:00 on 2015-02-19 UTC-5 leads to madness. Why madness? If you try to have sage coexist with *any* other piece of software on the system, it's going to conflict. Every other package in the ecosystem depends on something like =pari-1.0 and pari-2.0. Even if Sage depends on a stable version, it will require a specific version. In fact, this whole was started because of doctest failures with PARI-2.7.2 while Sage has (a patched version of) PARI-2.7.1 But if you don't require all doctests to pass, the dependency will usually just be at least version X. But sage requires EXACTLY commit (say) 02a793ab4325. First of all, nobody knows how to resolve that (is 02a793ab4325 bigger than 1.0?). Second, it restricts the solution space so much that an installation plan will be impossible once a few packages are involved. Most likely, these other packages can just work with the latest PARI. If the change is big The change is huge. That's precisely why I care so much: there are tons of very useful features in PARI-master. we should probably wait for a full release anyway to make sure we're working against the real, eventual API. Usually, the API converges. It's not like they try a certain API today and then a completely different API tomorrow. In fact, that could be soon as an argument in favour of upgrading to PARI-master: the API of the next stable release will surely be closer to what's currently in PARI-master than to the current stable release. Therefore, upgrading to PARI-master now will make the upgrade to the next stable release easier. If it comes down to it, we could always fork pari and make a release. But we have to call it sage-pari or something else If calling it sage-pari makes everybody happy, that's fine for me. Jeroen. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
Hello William, On 20 February 2015 at 01:22, William Stein wst...@gmail.com wrote: This has been discussed over and over again and it plainly doesn't work. The Sage in Debian does not pass doctests, not even close. In general the combinatorial explosion of configurations to debug is way too large and it is next to impossible to find any distribution where the version numbers even remotely match. We updated to GAP 4.4.12 in Sage 3.3 and the doctests involving GAP will in certain files be broken with any previous GAP release. If you used the Debian packages for Singular Sage won't work since we patch NTL and when those NTL libs come in conflict either Sage doesn't compile or Singular blows up. I can go on and on and on about similar issues and that is only the stuff I know about right on top of my head. I have never taken the time to go out and do dumb things to break Sage :) In the near future we plan to upgrade to a svn release of the development version of pari and then closely track it as bugs we report are often only fixed in pari-2.4.3svn. There is *no* way any distribution can track this without potentially breaking other code dependent on pari and you will be royally screwed if you want to use pari 2.3.4 in Sage (the stable release at this point) since Sage won't even build. We will fix all in tree code that gets broken with the new pari-svn and push it back upstream, but until that shows up in a distribution we will long have shipped Sage 4.0. The way we do it is the only way and I have doubts that any distribution packaged Sage will even be able to keep up with the official release given that I (=Michael Abshoff) spend working full time as the Sage release manager :) With due respect, all these points indicate software engineering deficiencies (e.g., the inability to guarantee a stable API, variations in the results of identical commands from one version to another, etc.). Those are a different domain of software engineering. Mathematics software is fundamentally different than word processing, graphical desktop, and web browser software. It doesn't matter much if a line in a UI is off by one pixel. In mathematics, being off by 1 can result in major bugs all over Sage. I disagree with this argument. Mathematics software is exactly the same as any other software. I am pretty sure that off-by-one errors are taken pretty seriously, e.g., in the Linux kernel, in GCC, Glibc, Python or the cryptographic code in Firefox or Chrome. Also, your statement here seems to be at odds with he paragraph above, where Michael laments that changing the versions of software changes the result of computations? The point was about handling long dependency chains (so I picked as examples a bunch of projects with a long dependency list). Why is it that I can expect to be able upgrade seamlessly, on my linux box, a library like libpng or openssl - on which hundreds of other packages depend - without breaking any of them? Again, this has only to do with software engineering best practices. The Sage distribution model, which has frequently been attacked every single year for nearly a decade, is one of the most important reasons for Sage's success. Still, after ten years it is still not possible to do yum install sage or apt-get ... . I would say that this is a barrier for a lot of people to use sage. That said, if somebody had the energy to make and maintain a branch/fork of Sage that could easily integrate with Linux distros, more power to them. I'd be happy to host it, point to it on the sage website, etc. If I had infinite resources (money) I would definitely hire somebody to create and maintain such a thing. It wouldn't even be a question.The problem is that right now we have *extremely* limited resources and have to make choices. In all honesty, I think you should throw golden bridges to people like Julien and Francois who are doing all this heavy-lifting work on the software engineering side of things. I think that having sage integrating with distro packages would not only be a benefit from the point of view of expanding the userbase, I think it would also greatly increase the software engineering quality of sage and related packages. Cheers, Francesco. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
On 02/20/2015 11:02 AM, kcrisman wrote: I no longer use sage for my day-to-day work, but when I was and I had to e.g. give a presentation, it was infuriating to find sage broken AGAIN ??? I assume this is because you updated some dependency and Sage didn't work quite properly somewhere in its bowels with that? I've never once had that happen with Sage on Mac, since it is a distribution by necessity there. To me that sounds like an argument for installing sage-the-distribution, because I assume this could happen with any software that has a dependency, before upstream had repackaged based on that updated dependency. I may be misunderstanding something in your argument, though. It happens when I update something that is a sage dependency, but for which there is no spkg. All of the C code that we ship depends on glibc, but we don't ship an spkg for glibc. When I update glibc, sage begins to segfault until I rebuild every spkg and the sage library. There are two ways to fix that: first, we could bundle literally an entire Linux distribution down to the kernel. Or, we could make sage play nice with package managers and let the package manager reinstall (i.e. rebuild) any parts of sage that are broken by the update. The first solution duplicates an enormous amount of effort that Linux distros have already put forth. It makes the sage download half a gigabyte instead of a few megabytes. It creates security problems -- now I have two version of openssl on my machine, and nobody updates the sage copy. It causes the sage build process to take 4 hours instead of 5 minutes. It makes installation much harder for users who are used to doing yum install sage. It ensures that system administrators won't go near it, so sage can't be installed once globally on the department server. The second has none of those problems, but we can't depend on silent forks of packages. I don't think there are very many packages where we really need to have a full-fledged fork. Pari may be one of them, who knows. But if we need to fork it we should just fork it and rename all of the libs and get it over with. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
I no longer use sage for my day-to-day work, but when I was and I had to e.g. give a presentation, it was infuriating to find sage broken AGAIN ??? I assume this is because you updated some dependency and Sage didn't work quite properly somewhere in its bowels with that? I've never once had that happen with Sage on Mac, since it is a distribution by necessity there. To me that sounds like an argument for installing sage-the-distribution, because I assume this could happen with any software that has a dependency, before upstream had repackaged based on that updated dependency. I may be misunderstanding something in your argument, though. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
There is no deceit, libgap is the gap source made useable as a shared libary. Its not like git/libgit who don't share a line of code... On Friday, February 20, 2015 at 8:23:20 AM UTC+1, Snark wrote: Hi, Le 20/02/2015 01:07, Volker Braun a écrit : On Thursday, February 19, 2015 at 6:36:38 PM UTC+1, Snark wrote: Sage's libgap and cddlib are problems : they correspond to upstreams That is not correct, there is no upstream library interface to gap. So there is no conflict. However, Debian invented a gap-library package. The package is actually named gap-libs, and isn't a library package in the computer science meaning of the word, so isn't the reason libgap can't go in debian. Since there is a gap project (with a version number, say 3.14), debian doesn't want to release a libgap-3.14 (same name, same version number) package not from upstream, as that would be deceiving the users. Rename that libsagegap and it's not a problem anymore. Do not lie, do not deceive -- are those unreasonable demands? Snark on #sagemath -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
I ignored this thread because of the title, but I guess I shouldn't have! general the combinatorial explosion of configurations to debug is way too large and it is next to impossible to find any distribution where the version numbers even remotely match. We updated to GAP 4.4.12 in Yes. If we want all doctests to pass, this is the issue. (Sometimes also for building or for supporting new code, but let's just focus on that.) So the real issue is that it is very challenging to put together *exact* versions where every last doctest passes on all platforms we regularly use. Distros presumably have another focus. In all honesty, I think you should throw golden bridges to people like Julien and Francois who are doing all this heavy-lifting work on the software engineering side of things. I think that having sage integrating with distro packages would not only be a benefit from the point of view of expanding the userbase, I think it would also greatly increase the software engineering quality of sage and related packages. This is also a good idea. François has been incredibly helpful with a lot of stuff I was completely lost by in getting this or that to work. We should be honoring that work as a community, because it is not very visible and doesn't lead directly to lots of papers, but makes a lot of those visible results possible by providing necessary infrastructure to doing science! The elephant no one is mentioning, of course, is that the number of potential users of (non-cloud-based) Sage is limited FAR FAR FAR more by the fact we do not have a native Windows port. (Despite awesome work by JP and others with Cygwin!) Sorry to say it, esp. since Linux and Mac are more relevant in science academia. And for Mac we definitely do need to provide a full distro, unless someone is seriously suggesting that we should ask all Sage users on Mac to use homebrew. (And while I rant on that, I have to say that anyone who uses Linux in a scientific environment almost certainly knows how to download source and type make. So I'm really not sure why this is such a problem, compared to the users I am usually dealing with. But I don't use Linux in a scientific environment, so that could be ignorance.) Here is an idea. I know nothing about packaging so it might be dumb. But see what you think. Problem 1: We don't want to hold up Sage development because of a slow upstream, or an upstream that doesn't package much for Debian (say). Problem 2: A lot of people really want to yum sagemath or something like that, and it's very hard to do this. Possible Solution: Have a (very) occasional Sage release that relies only on pure upstreams that are packaged in such a distro. Much slower release cycle than regular Sage. Maybe we just say Sage-2015 and it is just whatever has to be done to the Sage released by Jan. 1 2015 to make things work. Then a year later one does it again. Downside: Someone still has to figure out what that magic blend of secret herbs and spices is that will make this possible. Downside: People doing yum sagemath will get an older Sage than normal. Upside: It will be possible to do, and not require maintainers to constantly be trying to make things line up, just on a slow basis. Upside: It will bypass people complaining about download size (which is substantial in developing contexts, not quite so much in Western academia) and similar issues. Probably this is untenable for some obvious reason, but anyway it's putting something concrete out there. Have fun! - kcrisman -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
In all honesty, I think you should throw golden bridges to people like Julien and Francois who are doing all this heavy-lifting work on the What is a golden bridge? software engineering side of things. I think that having sage integrating with distro packages would not only be a benefit from the point of view of expanding the userbase, I think it would also greatly increase the software engineering quality of sage and related packages. I completely agree. The issue is one of resources. This is also a good idea. François has been incredibly helpful with a lot of stuff I was completely lost by in getting this or that to work. We should be honoring that work as a community, because it is not very visible and doesn't lead directly to lots of papers, but makes a lot of those visible results possible by providing necessary infrastructure to doing science! I certainly very much appreciate what François and everybody else doing distro integration is doing.The context of this discussion was that people were telling Volker/Jereon/etc.: - change how you are doing Sage releases - add major additional constraints to how Sage development is done - etc. I do not at all support adding such additional constraints to sage development. There's nothing incompatible about Sage development being done as it is now, and people also putting in a lot of work to integrate Sage into distributions. I personal don't think your suggestion above of how to do this would work (you didn't either0.I think a realistic solution is having a different branch of Sage, which is friendly to a distribution, and having a person work significantly (15 hours/week?) just on maintaining that fork. I'm all for that! -- William -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
On 2015-02-19 08:31, Marc Mezzarobba wrote: On a perhaps related note, Sage used to be about building the car, didn't it? I would say it still is about building the car. I think this refers to using dependencies where possible. Instead of writing our own functions to compute in number fields, we wrap PARI's number field functionality. What you do is to take only certain parts of the Sage car, change the bodywork and then complain that the wheels no longer fit. I find it ironic how hard sage makes it for other projects to rely on it You seem to think that Sage is actively making it hard for other projects. I simply think that the way how Sage development is done is fundamentally incompatible with what the distros want. I think this sentence from Volker is completely on the spot: -1 to delaying a Sage version for $DISTRO to catch up. Jeroen. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
Le 19/02/2015 18:54, Michael Orlitzky a écrit : This presupposes that the status quo is not madness. My sage builds work for about two weeks before some invisible dependency update breaks them. There's a line in sage beyond which we just don't care about dependencies. We ship gcc, some utilities, and a bunch of math software. But we don't ship e.g. glibc. Guess what happens when I rebuild glibc on my machine? Sage breaks. What happens if I rebuild gd on my machine? Sage breaks. What happens if I rebuild dvipng on my machine? Sage breaks. As much as I despise sage-the-distribution for getting in my way and taking way too much disk space on my poor box (a chromebook has 16Gb... that's for chromeOS+ubuntu+sage), I have to defend it here : if you recompile something which isn't API+ABI compatible with what it replaces, it's quite normal that it breaks things, and sage certainly isn't the only one you break when you do something like this! Especially if it's the libc... Snark on #sagemath -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
Le 19/02/2015 10:19, Jeroen Demeyer a écrit : On 2015-02-19 08:31, Marc Mezzarobba wrote: On a perhaps related note, Sage used to be about building the car, didn't it? I would say it still is about building the car. I think this refers to using dependencies where possible. Instead of writing our own functions to compute in number fields, we wrap PARI's number field functionality. What you do is to take only certain parts of the Sage car, change the bodywork and then complain that the wheels no longer fit. I find it ironic how hard sage makes it for other projects to rely on it You seem to think that Sage is actively making it hard for other projects. I simply think that the way how Sage development is done is fundamentally incompatible with what the distros want. Well, examples exist where poor choices have been made which make(made) it harder for other projects. From the top of my head : (1) ECL was configured to disable SIGCHLD... by patching it! I proposed a two-line patch which did it programmatically from sage's code. (2) PARI/GP is configured using a gprc... shipped by the spkg -- ticket #17796 is about pushing that in sage's code. So yes, the impression is there that given the choice between doing things in sage-the-software and working for everyone and doing things in sage-the-distribution and breaking for everyone else, some sage developers have a tendency to choose the later. I think this sentence from Volker is completely on the spot: -1 to delaying a Sage version for $DISTRO to catch up. I don't think software was ever delayed for debian. The point is about doing things cleanly, which open the door to everyone, instead of favoring sage-the-distribution. Snark on #sagemath -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
On 02/19/2015 03:49 PM, Julien Puydt wrote: Le 19/02/2015 18:54, Michael Orlitzky a écrit : This presupposes that the status quo is not madness. My sage builds work for about two weeks before some invisible dependency update breaks them. There's a line in sage beyond which we just don't care about dependencies. We ship gcc, some utilities, and a bunch of math software. But we don't ship e.g. glibc. Guess what happens when I rebuild glibc on my machine? Sage breaks. What happens if I rebuild gd on my machine? Sage breaks. What happens if I rebuild dvipng on my machine? Sage breaks. As much as I despise sage-the-distribution for getting in my way and taking way too much disk space on my poor box (a chromebook has 16Gb... that's for chromeOS+ubuntu+sage), I have to defend it here : if you recompile something which isn't API+ABI compatible with what it replaces, it's quite normal that it breaks things, and sage certainly isn't the only one you break when you do something like this! Especially if it's the libc... Not true! My package manager will automatically reinstall (i.e. fix) any other package on the system that has an ABI mismatch as the result of an upgrade. Sage is the only software not managed by my package manager, so sage is the only software with this problem. Libc was an extreme example -- gd/dvipng are more mundane. Sage ships a gd spkg, and sage uses dvipng but doesn't ship an spkg for it. The problem? dvipng links against gd. But since dvipng comes from my system, it links against the system gd. When running within sage, we mangle LD_LIBRARY_PATH to allow us to use all of our bundled libraries. As a result, dvipng tries to load sage's gd (WRONG) instead of my system's (RIGHT), and it segfaults. The same problem shows up everywhere along the boundary of things we do/don't bundle. There are a *lot* of little packages along that boundary and sage breaks whenever one of them gets updated or rebuilt with different ./configure flags. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
On Thursday, February 19, 2015 at 1:22:12 PM UTC-8, Michael Orlitzky wrote: Libc was an extreme example -- gd/dvipng are more mundane. Sage ships a gd spkg, and sage uses dvipng but doesn't ship an spkg for it. The problem? dvipng links against gd. But since dvipng comes from my system, it links against the system gd. When running within sage, we mangle LD_LIBRARY_PATH to allow us to use all of our bundled libraries. As a result, dvipng tries to load sage's gd (WRONG) instead of my system's (RIGHT), and it segfaults. That's just a bug. Executables that were built to link against $SAGE_local/lib should run in the SAGE environment. Executables that were not should run in a normal system environment, i.e., be started by sage-native-execute. Before that really helps, we should first merge http://trac.sagemath.org/ticket/14414 though (hint...) -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
Hi, Le 20/02/2015 01:07, Volker Braun a écrit : On Thursday, February 19, 2015 at 6:36:38 PM UTC+1, Snark wrote: Sage's libgap and cddlib are problems : they correspond to upstreams That is not correct, there is no upstream library interface to gap. So there is no conflict. However, Debian invented a gap-library package. The package is actually named gap-libs, and isn't a library package in the computer science meaning of the word, so isn't the reason libgap can't go in debian. Since there is a gap project (with a version number, say 3.14), debian doesn't want to release a libgap-3.14 (same name, same version number) package not from upstream, as that would be deceiving the users. Rename that libsagegap and it's not a problem anymore. Do not lie, do not deceive -- are those unreasonable demands? Snark on #sagemath -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
On 02/19/2015 09:21 AM, Jeroen Demeyer wrote: I don't think software was ever delayed for debian. If people are against #16997 because it's not compatible with Debian, then Debian is *already* slowing down Sage. It's not incompatibility with Debian that's the problem. Having dependencies like whatever was in the git repo at 11:00 on 2015-02-19 UTC-5 leads to madness. Debian won't do it, because it leads to madness. So doing things that lead to madness are incompatible with Debian. The cause and effect are the other way around =) Bundling the git repo is a short-term solution that bones everyone else (and possibly us, too, if upstream starts reverting commits). A better solution would be to work with them, settle on a set of commits that are definitely going to stay, and make a release. Yes, it's more work *right now*, but most good ideas are. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
On 2015-02-19 16:55, Michael Orlitzky wrote: It's not incompatibility with Debian that's the problem. Having dependencies like whatever was in the git repo at 11:00 on 2015-02-19 UTC-5 leads to madness. Why madness? It has been done before (#9343) and it worked just fine. Waiting forever until PARI makes a new stable release, that's madness. Bundling the git repo is a short-term solution that bones everyone else (and possibly us, too, if upstream starts reverting commits) If upstream reverts the occasional commit, we can deal with that. Stable releases also remove/change functionality, so what's the difference? A better solution would be to work with them, settle on a set of commits that are definitely going to stay, and make a release. Yes, it's more work *right now*, but most good ideas are. We can't tell PARI to make a new stable release for us, it just doesn't work that way. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
On Thu, Feb 19, 2015 at 11:24 AM, Jeroen Demeyer jdeme...@cage.ugent.be wrote: On 2015-02-19 16:55, Michael Orlitzky wrote: It's not incompatibility with Debian that's the problem. Having dependencies like whatever was in the git repo at 11:00 on 2015-02-19 UTC-5 leads to madness. Why madness? It has been done before (#9343) and it worked just fine. Waiting forever until PARI makes a new stable release, that's madness. Bundling the git repo is a short-term solution that bones everyone else (and possibly us, too, if upstream starts reverting commits) If upstream reverts the occasional commit, we can deal with that. Stable releases also remove/change functionality, so what's the difference? A better solution would be to work with them, settle on a set of commits that are definitely going to stay, and make a release. Yes, it's more work *right now*, but most good ideas are. We can't tell PARI to make a new stable release for us, it just doesn't work that way. +1 to everything said by anybody who has been the Sage release manager, hence has a better understanding of the constraints. I want to remind people that the goal of Sage is to be a competitor to Mathematica, Matlab, Magma and Maple. This is a very high bar, and it requires doing things that are much harder than what is possible within the framework of constraints of waiting for stable versions of all dependencies to catch up, etc. -- William -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
Hi, Regarding third-party packaging, etc., what's the status of the Sage Ubuntu PPA from AIMS? Because of SageMathCloud I regularly (try to) install a lot of big complicated scientific software in other areas (not pure math), that are in many ways similar to Sage. In many cases there is an Ubuntu PPA -- that seems to be quite standard. So another question is: are we doing enough to support the Sage Ubuntu PPA? On Thu, Feb 19, 2015 at 10:55 AM, Michael Orlitzky mich...@orlitzky.com wrote: On 02/19/2015 09:21 AM, Jeroen Demeyer wrote: I don't think software was ever delayed for debian. If people are against #16997 because it's not compatible with Debian, then Debian is *already* slowing down Sage. It's not incompatibility with Debian that's the problem. Having dependencies like whatever was in the git repo at 11:00 on 2015-02-19 UTC-5 leads to madness. Debian won't do it, because it leads to madness. So doing things that lead to madness are incompatible with Debian. The cause and effect are the other way around =) Bundling the git repo is a short-term solution that bones everyone else (and possibly us, too, if upstream starts reverting commits). A better solution would be to work with them, settle on a set of commits that are definitely going to stay, and make a release. Yes, it's more work *right now*, but most good ideas are. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. -- William (http://wstein.org) -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
On 2015-02-19 12:56, Julien Puydt wrote: Well, examples exist where poor choices have been made which make(made) it harder for other projects. From the top of my head : (1) ECL was configured to disable SIGCHLD... by patching it! I proposed a two-line patch which did it programmatically from sage's code. (2) PARI/GP is configured using a gprc... shipped by the spkg -- ticket #17796 is about pushing that in sage's code. Sure, these are two examples where improvement is possible. Sage developers are not perfect and there are indeed many things in Sage which are less than optimal. I never said that we shouldn't improve where we can. Indeed, (1) has been fixed and I am willing to review (2). However, don't let these two rather trivial issues distract you from the bigger issue of package dependencies. I don't think software was ever delayed for debian. If people are against #16997 because it's not compatible with Debian, then Debian is *already* slowing down Sage. Jeroen. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
Le 19/02/2015 15:21, Jeroen Demeyer a écrit : On 2015-02-19 12:56, Julien Puydt wrote: Well, examples exist where poor choices have been made which make(made) it harder for other projects. From the top of my head : (1) ECL was configured to disable SIGCHLD... by patching it! I proposed a two-line patch which did it programmatically from sage's code. (2) PARI/GP is configured using a gprc... shipped by the spkg -- ticket #17796 is about pushing that in sage's code. Sure, these are two examples where improvement is possible. Sage developers are not perfect and there are indeed many things in Sage which are less than optimal. I never said that we shouldn't improve where we can. Indeed, (1) has been fixed and I am willing to review (2). However, don't let these two rather trivial issues distract you from the bigger issue of package dependencies. All distributions have thousands of packages, and deps are not a big issue. Sage-the-distribution has about a hundred, and it's a big issue. A software package which claims it depends on a series of others with precise version requirements is ok : if the requirements aren't met, it can't be shipped, but there's a list of things to ship before. Everything is clear, honest. A software package which claims it depends on a series of others with precise version requirements, but when you look a little more closely, some of them are not really what upstream distributes, there are patches here and there... that is bad, and not something a serious distribution can accept. I don't think software was ever delayed for debian. If people are against #16997 because it's not compatible with Debian, then Debian is *already* slowing down Sage. If sage claims it needs a version debian doesn't have, that's not a problem. But if upstream 2.8 comes out and it turns out sage's pari isn't compatible with it, then it's bad! Depending on development versions not packagable in serious distributions isn't a problem as long as it's a transient property! Most software project are like this... but they strive to make releases now and then where they do depend only on stable releases of their deps. In conclusion: nobody will vote against #16997, as it's normal practice. But when pari 2.8 comes out, that will be a severe bug if the new release can't seamlessly replace the snapshot. Snark on #sagemath -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
On 2015-02-19, Michael Orlitzky mich...@orlitzky.com wrote: On 02/19/2015 09:21 AM, Jeroen Demeyer wrote: I don't think software was ever delayed for debian. If people are against #16997 because it's not compatible with Debian, then Debian is *already* slowing down Sage. It's not incompatibility with Debian that's the problem. Having dependencies like whatever was in the git repo at 11:00 on 2015-02-19 UTC-5 leads to madness. Debian won't do it, because it leads to madness. So doing things that lead to madness are incompatible with Debian. The cause and effect are the other way around =) Yes, but Debian (stable) is often rather hopelessly behind in supporting many things, in particular new hardware and new tools like newer gcc. Bundling the git repo is a short-term solution that bones everyone else (and possibly us, too, if upstream starts reverting commits). A better solution would be to work with them, settle on a set of commits that are definitely going to stay, and make a release. Yes, it's more work *right now*, but most good ideas are. how about making a clone of their git repo and referring to a commit in that clone? This would at least be stable. Basing something on timing rather than on a verifiable repo commit is indeed not good. By the way, that was one of main reasons for me to propose, some time ago, to distribute 3-rd party stuff not as tarballs, but as git submodules. Dima -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
Hi, Le 19/02/2015 17:29, William Stein a écrit : On Thu, Feb 19, 2015 at 11:24 AM, Jeroen Demeyer jdeme...@cage.ugent.be wrote: On 2015-02-19 16:55, Michael Orlitzky wrote: It's not incompatibility with Debian that's the problem. Having dependencies like whatever was in the git repo at 11:00 on 2015-02-19 UTC-5 leads to madness. Why madness? It has been done before (#9343) and it worked just fine. Waiting forever until PARI makes a new stable release, that's madness. Bundling the git repo is a short-term solution that bones everyone else (and possibly us, too, if upstream starts reverting commits) If upstream reverts the occasional commit, we can deal with that. Stable releases also remove/change functionality, so what's the difference? A better solution would be to work with them, settle on a set of commits that are definitely going to stay, and make a release. Yes, it's more work *right now*, but most good ideas are. We can't tell PARI to make a new stable release for us, it just doesn't work that way. +1 to everything said by anybody who has been the Sage release manager, hence has a better understanding of the constraints. The constraints are the same for each software project. Please, don't hesitate to depend on dev versions of pari, but then make sure you're compatible with the next release (ie: if upstream changes break sage, don't commit away the changes, but make sage move to be compatible). And if there is no upstream release in sight and you still want to go forth : make a special release, stating clearly that it's not upstream. If you depend on a foo 3.14 which isn't upstream, that's a problem for serious distributions, since they won't lie. Make your package a sagefoo 3.14, and now there's something to package. Sage's libgap and cddlib are problems : they correspond to upstreams, but they are forks : packaging them would be lying to the users. Rename them to libsagegap and sagecddlib, and everything changes : sage isn't lying about its deps, debian isn't lying about what it packages. I want to remind people that the goal of Sage is to be a competitor to Mathematica, Matlab, Magma and Maple. This is a very high bar, and it requires doing things that are much harder than what is possible within the framework of constraints of waiting for stable versions of all dependencies to catch up, etc. If you look at : https://people.debian.org/~thansen/debian-sage-dev-status.html then you'll see that sage isn't on the bleeding edge as you think it is. Yes, debian stable is slow, very slow -- many would say: much too slow. But testing is quite fast already, and unstable and experimental move very fast. Oh, by the way, as I write it, the page above still says we have flint 2.4.4 -- in fact, flint 2.4.5 is in unstable : another blue line. Saying that SageMath has incredible constraints that no other software project has, that it's so unbelievably fast that its deps can't keep up, that it leaves a fire trail before it everywhere it goes... it's just boasting! Sage-the-software is a normal project, which would probably be able to move faster if it weren't glued to sage-the-distribution. Snark on #sagemath -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
On 19 February 2015 at 18:05, Julien Puydt julien.pu...@laposte.net wrote: All distributions have thousands of packages, and deps are not a big issue. Sage-the-distribution has about a hundred, and it's a big issue. This is something I have failed to understand so far. What is it that makes Sage require such special handling of dependencies (i.e., package everything in one monolithic blob and with ad-hoc patching)? There's a lot of complex software around with long dependency chains (Firefox, Chrome, KDE, GNOME, OpenOffice, ...) and it seems like most Linux distributions are able to deal with this, without too many issues, via system-wide libraries. Even in the presence of libraries that do not do stable releases (e.g., ffmpeg a few years ago is a notable example I think) or do not guarantee a stable API. Of course, problems and incompatibilities arise occasionally, but many distributions have developed mechanisms to cope with this (e.g., SLOTs in Gentoo, proper versioning, reverse dependency checking, blockers, etc.). I understand that the big blob probably makes it easier on platforms such as OSX, but honestly, all this stuff about packaging, versioning, etc. has been a solved problem on Linux distributions for quite a while now. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
On 02/19/2015 11:24 AM, Jeroen Demeyer wrote: On 2015-02-19 16:55, Michael Orlitzky wrote: It's not incompatibility with Debian that's the problem. Having dependencies like whatever was in the git repo at 11:00 on 2015-02-19 UTC-5 leads to madness. Why madness? If you try to have sage coexist with *any* other piece of software on the system, it's going to conflict. Every other package in the ecosystem depends on something like =pari-1.0 and pari-2.0. But sage requires EXACTLY commit (say) 02a793ab4325. First of all, nobody knows how to resolve that (is 02a793ab4325 bigger than 1.0?). Second, it restricts the solution space so much that an installation plan will be impossible once a few packages are involved. Dependency resolution is usually a set of overlapping intervals. If the intersection is nonempty, some version works and you install that. If not, you're stuck. Depending on exactly one specific commit is intersecting with a point. Unless you're *very* lucky, you're going to wind up with an impossible constraint. It has been done before (#9343) and it worked just fine. This presupposes that the status quo is not madness. My sage builds work for about two weeks before some invisible dependency update breaks them. There's a line in sage beyond which we just don't care about dependencies. We ship gcc, some utilities, and a bunch of math software. But we don't ship e.g. glibc. Guess what happens when I rebuild glibc on my machine? Sage breaks. What happens if I rebuild gd on my machine? Sage breaks. What happens if I rebuild dvipng on my machine? Sage breaks. I no longer use sage for my day-to-day work, but when I was and I had to e.g. give a presentation, it was infuriating to find sage broken AGAIN at 8am. Sage-on-gentoo fixes this, but not if I want to submit patches, because the official sage has a gigabyte of junk bundled with it and whoever reviews my patch will be using that. Nobody wants to bundle *everything* because that'd be crazy, right? But unless we do, bundling *anything* is going to lead to breakage. If we were forced to fix the regular breakage by bundling everything, we'd all agree that it was madness to maintain an entire distro. It's too much work and time that would be better spent writing math software. We can't tell PARI to make a new stable release for us, it just doesn't work that way. We can't make them, but we can ask nicely. Especially if we're willing to help. If they're like every other project on Earth, their limiting factor is manpower. There are alternatives, anyway. If the new pari just fixes some minor bug, who cares. We can say this is fixed upstream and if users want to upgrade their pari to some bleeding-edge commit, so be it. If the change is big, we should probably wait for a full release anyway to make sure we're working against the real, eventual API. We don't need to be responsible for every line of code that we depend on at any level. If it comes down to it, we could always fork pari and make a release. But we have to call it sage-pari or something else; otherwise pretending to be pari is going to cause problems with other packages that expect the real pari. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
On Thursday, February 19, 2015 at 6:36:38 PM UTC+1, Snark wrote: Sage's libgap and cddlib are problems : they correspond to upstreams That is not correct, there is no upstream library interface to gap. So there is no conflict. However, Debian invented a gap-library package. -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
On Thu, Feb 19, 2015 at 12:51 PM, Francesco Biscani bluesca...@gmail.com wrote: On 19 February 2015 at 18:05, Julien Puydt julien.pu...@laposte.net wrote: All distributions have thousands of packages, and deps are not a big issue. Sage-the-distribution has about a hundred, and it's a big issue. This is something I have failed to understand so far. What is it that makes Sage require such special handling of dependencies (i.e., package everything in one monolithic blob and with ad-hoc patching)? See http://wiki.sagemath.org/faq/bigsagerant for another past Sage release manager's rant on this topic from long ago (maybe 2008?). == Wouldn't it be way better if Sage did not ship as a gigantic bundle? == This has been discussed over and over again and it plainly doesn't work. The Sage in Debian does not pass doctests, not even close. In general the combinatorial explosion of configurations to debug is way too large and it is next to impossible to find any distribution where the version numbers even remotely match. We updated to GAP 4.4.12 in Sage 3.3 and the doctests involving GAP will in certain files be broken with any previous GAP release. If you used the Debian packages for Singular Sage won't work since we patch NTL and when those NTL libs come in conflict either Sage doesn't compile or Singular blows up. I can go on and on and on about similar issues and that is only the stuff I know about right on top of my head. I have never taken the time to go out and do dumb things to break Sage :) In the near future we plan to upgrade to a svn release of the development version of pari and then closely track it as bugs we report are often only fixed in pari-2.4.3svn. There is *no* way any distribution can track this without potentially breaking other code dependent on pari and you will be royally screwed if you want to use pari 2.3.4 in Sage (the stable release at this point) since Sage won't even build. We will fix all in tree code that gets broken with the new pari-svn and push it back upstream, but until that shows up in a distribution we will long have shipped Sage 4.0. The way we do it is the only way and I have doubts that any distribution packaged Sage will even be able to keep up with the official release given that I (=Michael Abshoff) spend working full time as the Sage release manager :) There's a lot of complex software around with long dependency chains (Firefox, Chrome, KDE, GNOME, OpenOffice, ...) and it seems like most Linux distributions are able to deal with this, without too many issues, via system-wide libraries. Those are a different domain of software engineering. Mathematics software is fundamentally different than word processing, graphical desktop, and web browser software. It doesn't matter much if a line in a UI is off by one pixel. In mathematics, being off by 1 can result in major bugs all over Sage. The Sage distribution model, which has frequently been attacked every single year for nearly a decade, is one of the most important reasons for Sage's success. That said, if somebody had the energy to make and maintain a branch/fork of Sage that could easily integrate with Linux distros, more power to them. I'd be happy to host it, point to it on the sage website, etc. If I had infinite resources (money) I would definitely hire somebody to create and maintain such a thing. It wouldn't even be a question.The problem is that right now we have *extremely* limited resources and have to make choices. -- William -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
Maybe I'm missing something here, but aren't these test also badly stated? This would be a good example why some tolerance should be included if one test something with floating points: Every small change in some flop somewhere in the code will lead to a fail. I personally wouldn't call something strange numerical error, where some floating point operation differs from the expected output by a difference below machine epsilon. If this is the only problem with the different pari version, it would be better to restate the unit test. Regards, Stefan On Wednesday, February 18, 2015 at 1:53:58 PM UTC+1, Snark wrote: Hi, I'm having strange numerical behaviour with my experimental sage using debian packages, with two failing doctests in the src/sage/libs/pari/ directory (both in gen.pyx) : Failed example: (s*z)^5 Expected: 2.00 - 1.08420217248550 E-19*I Got: 2.00 + 0.E-19*I Failed example: e.ellztopoint(1+i) Expected: [0.E-19 - 1.02152286795670*I, -0.149072813701096 - 0.149072813701096*I] Got: [0.E-18 - 1.02152286795670*I, -0.149072813701096 - 0.149072813701096*I] For the first one, the Got: is the one expected on a 32-bit box! And from all the tests in the directory where there is a differing 32-bit/64-bit expectation, it's the only failing. For the second one... I really don't know... Does it look familiar? Snark on #sagemath -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
Le 18/02/2015 19:15, maldun a écrit : Maybe I'm missing something here, but aren't these test also badly stated? This would be a good example why some tolerance should be included if one test something with floating points: Every small change in some flop somewhere in the code will lead to a fail. I personally wouldn't call something strange numerical error, where some floating point operation differs from the expected output by a difference below machine epsilon. If this is the only problem with the different pari version, it would be better to restate the unit test. That's what I was proposing when I mentioned a tol :-P Snark on #sagemath -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: [debian] Strange numerical errors in sage's libpari code
Jeroen Demeyer wrote: Sage shouldn't support Debian. Debian should support Sage. On a perhaps related note, Sage used to be about building the car, didn't it¹? I find it ironic how hard sage makes it for other projects to rely on it in the way it itself relies on tons of third-party packages. Want to install Parior Gap from the Sage distribution and use it through sage? Easy! Want to package sage itself, or use the Python bindings for Pari it provides in your (otherwise unrelated and perhaps non-primarily-mathematical) code?--Ouch! ¹ Yeah, I know, that was never part of its mission statement, but it is mentioned in the second sentence of the tutorial, even before that mission statement. And makes much more sense to me. -- Marc -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
