Re: [sage-devel] any buildbot using gcc-5.3 out there?
On 01/28/16 11:18, François Bissey wrote: I am asking because I got a report about a singular/ntl interaction with gcc-5.3.0 in sage-on-gentoo. Basically ntl 9.6.2 switches on c++11 support and then g++ refuse to compile bits of singular calling ntl without c++11 being enabled. Of course singular's configure scripts [yes there are several] are to old to even consider c++11. It could be due to me allowing user to turn on threads in ntl which we don't do so far in vanilla sage. https://bugs.gentoo.org/show_bug.cgi?id=572626 Turns out it is due to configuring ntl with "NTL_THREAD_BOOST=on" which uses c++11 threads. This isn't done in vanilla sage so no one should have come across it yet. It breaks the default building of flint as well, presumably it would break building of sage. Francois -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] any buildbot using gcc-5.3 out there?
I am asking because I got a report about a singular/ntl interaction with gcc-5.3.0 in sage-on-gentoo. Basically ntl 9.6.2 switches on c++11 support and then g++ refuse to compile bits of singular calling ntl without c++11 being enabled. Of course singular's configure scripts [yes there are several] are to old to even consider c++11. It could be due to me allowing user to turn on threads in ntl which we don't do so far in vanilla sage. https://bugs.gentoo.org/show_bug.cgi?id=572626 Francois -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Conversion Jupyter Notebook -> Doctests
It would be pretty easy to do since ipynb has an official api to read files. We could also combine it with the sagenb->ipynb converter... On Wednesday, January 27, 2016 at 3:39:23 PM UTC-5, kcrisman wrote: > > > > On Wednesday, January 27, 2016 at 1:22:15 AM UTC-5, Clemens Heuberger > wrote: >> >> Is there a way to convert a jupyter notebook .ipynb to a "doctestable >> file"? >> Such a thing existed for the sage notebook. >> >> > Is it possible that there is an ipynb -> rst out there, or in development? > That might help fill the need. > -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Conversion Jupyter Notebook -> Doctests
Min (in the Jupyter project) wrote a program to doctest .ipynb files a while ago: https://gist.github.com/minrk/2620735. I think it expects an old version of the .ipynb format, but it is a good starting point to update to the newest .ipynb format. Thanks, Jason On Wed, Jan 27, 2016 at 3:39 PM kcrisman wrote: > > > On Wednesday, January 27, 2016 at 1:22:15 AM UTC-5, Clemens Heuberger > wrote: >> >> Is there a way to convert a jupyter notebook .ipynb to a "doctestable >> file"? >> Such a thing existed for the sage notebook. >> >> > Is it possible that there is an ipynb -> rst out there, or in > development? That might help fill the need. > > -- > 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 https://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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Jupyter notebook by default?
> > I surprisingly don't remember even one user request for such > tinymce style wysiwyg editing for SMC. And our users are constantly asking > for the functionality they feel they really need... I'm very surprised by > this lack of demand. However maybe they don't know what they want. > > > Well, I think that as always there are two groups of people interested in feature X. 1) People who can't do without it but see right away it's not possible, and aren't invested enough to ask and so just don't use it (whatever "it" is, not just SMC). 2) People who figure the advantages of "it" are good enough that it's okay to deal without it. Group 3 is of course the ones who ask you, but perhaps whoever is using SMC doesn't need it/want it enough to ask. It would be interesting to see how technically advanced the typical SMC user perceives themselves. [My guess (and only a guess) is that anyone who wants a "real" wysiwyg for this is too intimidated by the interface to use it much anyway, assuming they even look into it. But that may change as more people are introduced to SMC, and/or my guess may be wrong.] -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Forking/patching of upstream projects
I'm fine with giving him all the time in the world to respond. Once he does I'm happy to update the SPKG.txt metadata. On Wednesday, January 27, 2016 at 3:27:58 PM UTC-5, Jeroen Demeyer wrote: > > On 2016-01-27 20:27, Volker Braun wrote: > > Imho if upstream hasn't made any changes in the last 5 years and/or > > can't be bothered with the added value of building a shared library then > > its better to fork. > > I agree! > > However, note the very important condition "can't be bothered with the > added value of building a shared library". > > Can we at least give upstream a chance to respond? Like what happened > with planarity? Politely explain the situation to upstream and see how > they respond. > > > 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Conversion Jupyter Notebook -> Doctests
On Wednesday, January 27, 2016 at 1:22:15 AM UTC-5, Clemens Heuberger wrote: > > Is there a way to convert a jupyter notebook .ipynb to a "doctestable > file"? > Such a thing existed for the sage notebook. > > Is it possible that there is an ipynb -> rst out there, or in development? That might help fill the need. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Forking/patching of upstream projects
On 2016-01-27 20:03, Dima Pasechnik wrote: The exciting alternative approach proposed by Jeroen is patching makefiles, and possibly other parts of upstream, by hand. Again false dichotomy... -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Forking/patching of upstream projects
On 2016-01-27 19:46, Dima Pasechnik wrote: Since when creating a public git repo of something is called forking? It is forking if the only way to obtain the tarball is using some obscure git repo that you created. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Forking/patching of upstream projects
On 2016-01-27 19:42, Dima Pasechnik wrote: Note that planarity already had a ./configure && make install support. This autoconf build system his was added by Nathann Cohen and accepted by upstream. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Forking/patching of upstream projects
On 2016-01-27 20:27, Volker Braun wrote: Imho if upstream hasn't made any changes in the last 5 years and/or can't be bothered with the added value of building a shared library then its better to fork. I agree! However, note the very important condition "can't be bothered with the added value of building a shared library". Can we at least give upstream a chance to respond? Like what happened with planarity? Politely explain the situation to upstream and see how they respond. 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Forking/patching of upstream projects
Imho if upstream hasn't made any changes in the last 5 years and/or can't be bothered with the added value of building a shared library then its better to fork. Make a git repo under the sagemath github organization, done. Really, everything is a fork in git. Just get used to it. On Wednesday, January 27, 2016 at 10:59:34 AM UTC-5, Jeroen Demeyer wrote: > > Hello sage-devel, > > There are various degrees of patching upstream projects for Sage: > > (0) vanilla upstream stable release > (1) upstream stable release with patches accepted by upstream > (2) upstream development code (e.g. git master) > (3) upstream code with patches not accepted by upstream > (4) fork upstream > > In my opinion, (4) should only be done if there is very good > justification for it (example: polybori was forked as brial because > upstream is dead). > > Dima Pasechnik recently proposed to do (4) for both nauty and cliquer, > but I think in both cases this lacks justification and (3) can be done > instead. > > I know it is a hard question what is acceptable under which conditions. > However, these questions regularly come up and it would be good to have > some guidelines. In particular, we should consider this in the light of > maintainability and distributability of SageMath. > > > 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Forking/patching of upstream projects
On Wednesday, 27 January 2016 18:50:02 UTC, Nathann Cohen wrote: > > > Since when creating a public git repo of something is called forking? > > In the present, upstream explained that the software was barely > updated anymore (last update was 5 years ago) and that there are no > plans to change it in the close future (except possible bugfixes). > *if* such a thing were to ever happen, we could easily update the repo > and stay compatible with upstream. > > Would it change the situation for you if upstream agreed to make the > tarball produced by Dima on his website? Is it just a question of > *where* the tarball is to be downloaded? > in my proposal, the tarball is produced by running spkg-src off a git repo, which in turn invokes autoconf/automake. This git repo may be put e.g. on github.com/sagemath/ to give it more clout. The exciting alternative approach proposed by Jeroen is patching makefiles, and possibly other parts of upstream, by hand. Now it's your choice, folks, I rest my case here. > Nathann > -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Forking/patching of upstream projects
> Since when creating a public git repo of something is called forking? In the present, upstream explained that the software was barely updated anymore (last update was 5 years ago) and that there are no plans to change it in the close future (except possible bugfixes). *if* such a thing were to ever happen, we could easily update the repo and stay compatible with upstream. Would it change the situation for you if upstream agreed to make the tarball produced by Dima on his website? Is it just a question of *where* the tarball is to be downloaded? Nathann -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Forking/patching of upstream projects
On Wednesday, 27 January 2016 17:53:47 UTC, Jeroen Demeyer wrote: > > On 2016-01-27 17:52, Dima Pasechnik wrote: > > For the record, I never proposed to create a fork of either of them in > > the 1st place. > True, you didn't propose anything. You just did it. > Since when creating a public git repo of something is called forking? This way, you know, oh horror, forks of most everything that is dear to us are created en mass at a rate of 1000 per minute or more, on gihub and elsewhere... -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Forking/patching of upstream projects
On Wednesday, 27 January 2016 18:18:47 UTC, Jeroen Demeyer wrote: > > On 2016-01-27 17:52, Dima Pasechnik wrote: > > I really do not understand why a complicated, buggy, hard to maintain, > > fix, or even read > > patches and scripts (e.g. > > > https://github.com/sagemath/sage/blob/master/build/pkgs/cliquer/spkg-install > > and > > its role in Sage 7.0 OSX binaries facepalm) > > should be preferred to an honest public git repo with our (trivial) > > changes laid out nicely > > I never said that I preferred a "complicated, buggy... spkg-install". Of > course I don't. You are presenting a false dichotomy. For an example of > how this is done without forking upstream, see planarity. > Jeroen, I don't see how this example applies to packages without a decent build system. Note that planarity already had a ./configure && make install support. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Forking/patching of upstream projects
On 2016-01-27 17:52, Dima Pasechnik wrote: I really do not understand why a complicated, buggy, hard to maintain, fix, or even read patches and scripts (e.g. https://github.com/sagemath/sage/blob/master/build/pkgs/cliquer/spkg-install and its role in Sage 7.0 OSX binaries facepalm) should be preferred to an honest public git repo with our (trivial) changes laid out nicely I never said that I preferred a "complicated, buggy... spkg-install". Of course I don't. You are presenting a false dichotomy. For an example of how this is done without forking upstream, see planarity. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Forking/patching of upstream projects
On 2016-01-27 17:52, Dima Pasechnik wrote: For the record, I never proposed to create a fork of either of them in the 1st place. True, you didn't propose anything. You just did it. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Forking/patching of upstream projects
On Wednesday, 27 January 2016 15:59:34 UTC, Jeroen Demeyer wrote: > > Hello sage-devel, > > There are various degrees of patching upstream projects for Sage: > > (0) vanilla upstream stable release > (1) upstream stable release with patches accepted by upstream > (2) upstream development code (e.g. git master) > (3) upstream code with patches not accepted by upstream > (4) fork upstream > > In my opinion, (4) should only be done if there is very good > justification for it (example: polybori was forked as brial because > upstream is dead). > > Dima Pasechnik recently proposed to do (4) for both nauty and cliquer, > but I think in both cases this lacks justification and (3) can be done > instead. > For the record, I never proposed to create a fork of either of them in the 1st place. Hopefully nauty 2.6 will be released under a GPL-compatible license, and IMHO it was important to show the will to create a fork. I might also remind you about csdp optional package, for which I was forced on http://trac.sagemath.org/ticket/14505 to do a lot totally useless re-packaging, only to be thrown away when the switch to git has taken place. And csdp is very similar to what I propose (http://trac.sagemath.org/ticket/19967) in one or another way with cliquer - adding a sane building system. And a solution is pretty similar too (cliquer is quite easy as it has no external dependencies, but on the other hand it has no directory structure at all, everything is dumped in one place). Both csdp and cliquer are quite old, essentially being unchanged for years and years. > I know it is a hard question what is acceptable under which conditions. > However, these questions regularly come up and it would be good to have > some guidelines. In particular, we should consider this in the light of > maintainability and distributability of SageMath. > > I really do not understand why a complicated, buggy, hard to maintain, fix, or even read patches and scripts (e.g. https://github.com/sagemath/sage/blob/master/build/pkgs/cliquer/spkg-install and its role in Sage 7.0 OSX binaries facepalm) should be preferred to an honest public git repo with our (trivial) changes laid out nicely, while autotools do the heavy lifting for us. Dima > > 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Forking/patching of upstream projects
Hello sage-devel, There are various degrees of patching upstream projects for Sage: (0) vanilla upstream stable release (1) upstream stable release with patches accepted by upstream (2) upstream development code (e.g. git master) (3) upstream code with patches not accepted by upstream (4) fork upstream In my opinion, (4) should only be done if there is very good justification for it (example: polybori was forked as brial because upstream is dead). Dima Pasechnik recently proposed to do (4) for both nauty and cliquer, but I think in both cases this lacks justification and (3) can be done instead. I know it is a hard question what is acceptable under which conditions. However, these questions regularly come up and it would be good to have some guidelines. In particular, we should consider this in the light of maintainability and distributability of SageMath. 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Conversion Jupyter Notebook -> Doctests
On 2016-01-27 07:22, Clemens Heuberger wrote: - diffs between various versions would be much easier than diffing the .ipynb file. I know that "diffability" of ipynb files is on upstream's TODO list. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
