Re: [sage-devel] Re: interrupt.pyx on PyPi?
See https://github.com/malb/signal.pyx/issues/2 -- 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: interrupt.pyx on PyPi?
Hi, Ondrej Certik asks "Any chance to BSD license it [signal.pyx]?" I wrote the first version of the code and would be for that. It's core infrastructure and if we BSD it, then the chances it'll get used widely and be better quality go up.So I'm +1. I think we would mainly need Jereon Demeyer and Martin to also be +1 for BSD licensing and could do it, though searching the git blame would be a good idea. William On Sat, Feb 6, 2016 at 9:51 AM, 'Martin R. Albrecht' via sage-devel wrote: > Hi all, > > work on this has started: > > https://github.com/malb/signal.pyx > > http://trac.sagemath.org/ticket/20002 > > So far, it’s pretty standard setup.py stuff, i.e. no autoconf. > > Help welcome: > > https://github.com/malb/signal.pyx/issues > > Cheers, > Martin > > Martin R. Albrecht writes: >> Hi all, >> >> In a thread over at [sage-support] William wrote: >>> I've suggested numerous times that we should massively refactor the >>> sage library to be a bunch of smaller Python libraries, develop them >>> say on github (?), use Pypi and pip. If people would realize how >>> important it is that we revamp how Sage development is done in a much >>> less monolithic way, and better using existing tools, then I would be >>> happy and enjoy watching as people do the revamp (e.g., like happened >>> with switching from Mercurial to Git, which I didn't do much on, but >>> definitely supported). >> >> I don’t mean to restart a general strategy/development discussion here, >> but perhaps turning Sage into a bunch of smaller Python libraries is >> something which can be accomplished step-by-step. >> >> In particular, I am *very* interested in turning Sage’s interrupt >> handling into something that can be easily installed from PyPI. For >> those who don’t know what Sage’s interrupt handling does: it allows that >> you can press Ctrl-C to interrupt long running C code and that crashes >> in a library do not necessarily crash your Python shell. It is a >> difference between night and day to interface with external C/C++ code >> From Python without and with it. >> >> Having this code available outside of Sage enables, for example, to turn >> some of our C/C++ library interfaces into stand-alone libraries[^1], like >> I’ve done with our fplll interface at >> >> https://github.com/malb/fpylll >> >> Sage’s interrupt handling lives at >> >> https://github.com/sagemath/sage/tree/master/src/sage/ext/interrupt >> >> I think the technical challenges are manageable. I’m using a copy of it >> separately in >> >> https://github.com/malb/fpylll/tree/master/src/fpylll/interrupt >> >> without issues. Making this code independent would mean one big patch >> to the library, though, where we replace all >> >> include 'sage/ext/interrupt.pxi' >> >> with an appropriate new line depending on where we’d install the file. >> >> My question is: am I overlooking some technical challenge or another >> reason why making this code independent could be a problem? >> >> I’m happy to put some work into this, in case you’re wondering. >> >> Cheers, >> Martin >> >> [^1]: Okay, there’s also the small issue of how to do type conversion >> Sage ←→ library in a nice modular yet fast way, but one step at a time. > > > -- > > _pgp: https://keybase.io/martinralbrecht > _www: https://martinralbrecht.wordpress.com > _jab: martinralbre...@jabber.ccc.de > _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF > > -- > 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. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: interrupt.pyx on PyPi?
Hi all, work on this has started: https://github.com/malb/signal.pyx http://trac.sagemath.org/ticket/20002 So far, it’s pretty standard setup.py stuff, i.e. no autoconf. Help welcome: https://github.com/malb/signal.pyx/issues Cheers, Martin Martin R. Albrecht writes: > Hi all, > > In a thread over at [sage-support] William wrote: >> I've suggested numerous times that we should massively refactor the >> sage library to be a bunch of smaller Python libraries, develop them >> say on github (?), use Pypi and pip. If people would realize how >> important it is that we revamp how Sage development is done in a much >> less monolithic way, and better using existing tools, then I would be >> happy and enjoy watching as people do the revamp (e.g., like happened >> with switching from Mercurial to Git, which I didn't do much on, but >> definitely supported). > > I don’t mean to restart a general strategy/development discussion here, > but perhaps turning Sage into a bunch of smaller Python libraries is > something which can be accomplished step-by-step. > > In particular, I am *very* interested in turning Sage’s interrupt > handling into something that can be easily installed from PyPI. For > those who don’t know what Sage’s interrupt handling does: it allows that > you can press Ctrl-C to interrupt long running C code and that crashes > in a library do not necessarily crash your Python shell. It is a > difference between night and day to interface with external C/C++ code > From Python without and with it. > > Having this code available outside of Sage enables, for example, to turn > some of our C/C++ library interfaces into stand-alone libraries[^1], like > I’ve done with our fplll interface at > > https://github.com/malb/fpylll > > Sage’s interrupt handling lives at > > https://github.com/sagemath/sage/tree/master/src/sage/ext/interrupt > > I think the technical challenges are manageable. I’m using a copy of it > separately in > > https://github.com/malb/fpylll/tree/master/src/fpylll/interrupt > > without issues. Making this code independent would mean one big patch > to the library, though, where we replace all > > include 'sage/ext/interrupt.pxi' > > with an appropriate new line depending on where we’d install the file. > > My question is: am I overlooking some technical challenge or another > reason why making this code independent could be a problem? > > I’m happy to put some work into this, in case you’re wondering. > > Cheers, > Martin > > [^1]: Okay, there’s also the small issue of how to do type conversion > Sage ←→ library in a nice modular yet fast way, but one step at a time. -- _pgp: https://keybase.io/martinralbrecht _www: https://martinralbrecht.wordpress.com _jab: martinralbre...@jabber.ccc.de _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF -- 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. signature.asc Description: PGP signature
Re: [sage-devel] Re: interrupt.pyx on PyPi?
On 2016-02-02 11:12, Volker Braun wrote: Right now all tests for interrupts use "sage:" markers and customized magic comments. So its not easy to run the existing doctests under $favorite_testing_framework. At least for the interrupt tests, this shouldn't be a big issue. For other parts of Sage, that's a different story. -- 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: interrupt.pyx on PyPi?
Right now all tests for interrupts use "sage:" markers and customized magic comments. So its not easy to run the existing doctests under $favorite_testing_framework. On Tuesday, February 2, 2016 at 10:11:23 AM UTC+1, Martin Albrecht wrote: > > I’m not sure I follow. Many Python packages have tests, pick your > favourite Python testing framework. Why should this be a problem here? -- 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: interrupt.pyx on PyPi?
Hi Volker, I’m not sure I follow. Many Python packages have tests, pick your favourite Python testing framework. Why should this be a problem here? In addition, Sage can/should run its own doctests to check there’s no mismatch. Cheers, Martin Volker Braun writes: > On Monday, February 1, 2016 at 10:40:42 AM UTC+1, Martin Albrecht wrote: >> >> but perhaps turning Sage into a bunch of smaller Python libraries is >> something which can be accomplished step-by-step. >> > > The first order of business should then be to modularize the doctest > framework, otherwise you end up with a bunch of packages that have no > working testsuite. Which nobody in their right mind would want to base > their work on. > > Also, namespace packages (i.e. multiple packages sharing sage.*) are easier > in Python >= 3.3 thanks to PEP420. > > Splitting of non-mathematical tools would be definitely an advantage since > they would be useful in other projects. And some fairly isolated interfaces > with third-party programs could be factored out, too. But I don't think > there is much value in splitting up most of the core functionality; If the > doctests can't be run independently then modules are irreducible. And there > aren't many doctests that you can run without libgmp or libsingular, for > example. > > Also, the semver coolaid doesn't really work if there is nobody running e2e > tests. Which really is admitting defeat, if I can't develop packages > independently then they are not independent. At least in npm one can work > around broken semver by installing specific versions in parallel, but pip > does not support that. On the plus side, one can still install install pip > packages without pages of warnings about unsupported/abandoned versions -- _pgp: https://keybase.io/martinralbrecht _www: https://martinralbrecht.wordpress.com _jab: martinralbre...@jabber.ccc.de _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF -- 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. signature.asc Description: PGP signature
[sage-devel] Re: interrupt.pyx on PyPi?
On Monday, February 1, 2016 at 10:40:42 AM UTC+1, Martin Albrecht wrote: > > but perhaps turning Sage into a bunch of smaller Python libraries is > something which can be accomplished step-by-step. > The first order of business should then be to modularize the doctest framework, otherwise you end up with a bunch of packages that have no working testsuite. Which nobody in their right mind would want to base their work on. Also, namespace packages (i.e. multiple packages sharing sage.*) are easier in Python >= 3.3 thanks to PEP420. Splitting of non-mathematical tools would be definitely an advantage since they would be useful in other projects. And some fairly isolated interfaces with third-party programs could be factored out, too. But I don't think there is much value in splitting up most of the core functionality; If the doctests can't be run independently then modules are irreducible. And there aren't many doctests that you can run without libgmp or libsingular, for example. Also, the semver coolaid doesn't really work if there is nobody running e2e tests. Which really is admitting defeat, if I can't develop packages independently then they are not independent. At least in npm one can work around broken semver by installing specific versions in parallel, but pip does not support that. On the plus side, one can still install install pip packages without pages of warnings about unsupported/abandoned versions -- 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.
