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,
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
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
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
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
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
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
