Hey, It's been almost three months since we talked about a 0.16 release, I think it's quite ready. It would already be a big release, it would be good to see how people like it, and to catch any issues etc before we pile on more features. Mark
On Mon, Jan 23, 2012 at 2:27 AM, mark florisson <markflorisson88@gmail.com> wrote:
Hey,
It's been almost three months since we talked about a 0.16 release, I think it's quite ready. It would already be a big release, it would be good to see how people like it, and to catch any issues etc before we pile on more features.
I would love to do a release soon. Last time this came up, I think the big issue was (compilation) performance regression. Has this been adequately addressed? The other issue is that there are a couple of doctest failures with Sage. One source of problems is decorators due to the (ugly) disallowing of function re-declarations, I'll try look into this one. There are also a huge number of segfaults (see the bottom of https://sage.math.washington.edu:8091/hudson/view/ext-libs/job/sage-tests/la... ) which we need to get to the bottom of. - Robert
On 25 January 2012 01:27, Robert Bradshaw <robertwb@math.washington.edu> wrote:
On Mon, Jan 23, 2012 at 2:27 AM, mark florisson <markflorisson88@gmail.com> wrote:
Hey,
It's been almost three months since we talked about a 0.16 release, I think it's quite ready. It would already be a big release, it would be good to see how people like it, and to catch any issues etc before we pile on more features.
I would love to do a release soon. Last time this came up, I think the big issue was (compilation) performance regression. Has this been adequately addressed?
Sort of. Basically if you don't use memoryviews it will be as fast as it used to be, otherwise there is about a 3 second constant time overhead (on my machine).
The other issue is that there are a couple of doctest failures with Sage. One source of problems is decorators due to the (ugly) disallowing of function re-declarations, I'll try look into this one. There are also a huge number of segfaults (see the bottom of https://sage.math.washington.edu:8091/hudson/view/ext-libs/job/sage-tests/la... ) which we need to get to the bottom of.
Oh I see. I suppose to try it out under a debugger one would have to compile the whole of sage from source?
- Robert _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
mark florisson, 25.01.2012 11:43:
On 25 January 2012 01:27, Robert Bradshaw wrote:
On Mon, Jan 23, 2012 at 2:27 AM, mark florisson wrote:
It's been almost three months since we talked about a 0.16 release, I think it's quite ready. It would already be a big release, it would be good to see how people like it, and to catch any issues etc before we pile on more features.
I would love to do a release soon. Last time this came up, I think the big issue was (compilation) performance regression. Has this been adequately addressed?
Sort of. Basically if you don't use memoryviews it will be as fast as it used to be, otherwise there is about a 3 second constant time overhead (on my machine).
The other issue is that there are a couple of doctest failures with Sage. One source of problems is decorators due to the (ugly) disallowing of function re-declarations, I'll try look into this one. There are also a huge number of segfaults (see the bottom of https://sage.math.washington.edu:8091/hudson/view/ext-libs/job/sage-tests/la... ) which we need to get to the bottom of.
Oh I see. I suppose to try it out under a debugger one would have to compile the whole of sage from source?
It might be easier to log into sage.math, go to the sage build directory that Jenkins uses and do some experiments there. It's in /levi/scratch/robertwb/hudson/sage-4.8/ Stefan
On 25 January 2012 12:00, Stefan Behnel <stefan_ml@behnel.de> wrote:
mark florisson, 25.01.2012 11:43:
On 25 January 2012 01:27, Robert Bradshaw wrote:
On Mon, Jan 23, 2012 at 2:27 AM, mark florisson wrote:
It's been almost three months since we talked about a 0.16 release, I think it's quite ready. It would already be a big release, it would be good to see how people like it, and to catch any issues etc before we pile on more features.
I would love to do a release soon. Last time this came up, I think the big issue was (compilation) performance regression. Has this been adequately addressed?
Sort of. Basically if you don't use memoryviews it will be as fast as it used to be, otherwise there is about a 3 second constant time overhead (on my machine).
The other issue is that there are a couple of doctest failures with Sage. One source of problems is decorators due to the (ugly) disallowing of function re-declarations, I'll try look into this one. There are also a huge number of segfaults (see the bottom of https://sage.math.washington.edu:8091/hudson/view/ext-libs/job/sage-tests/la... ) which we need to get to the bottom of.
Oh I see. I suppose to try it out under a debugger one would have to compile the whole of sage from source?
It might be easier to log into sage.math, go to the sage build directory that Jenkins uses and do some experiments there. It's in
/levi/scratch/robertwb/hudson/sage-4.8/
Stefan _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Ah, neat, thanks.
On Wed, Jan 25, 2012 at 4:17 AM, mark florisson <markflorisson88@gmail.com> wrote:
On 25 January 2012 12:00, Stefan Behnel <stefan_ml@behnel.de> wrote:
mark florisson, 25.01.2012 11:43:
On 25 January 2012 01:27, Robert Bradshaw wrote:
On Mon, Jan 23, 2012 at 2:27 AM, mark florisson wrote:
It's been almost three months since we talked about a 0.16 release, I think it's quite ready. It would already be a big release, it would be good to see how people like it, and to catch any issues etc before we pile on more features.
I would love to do a release soon. Last time this came up, I think the big issue was (compilation) performance regression. Has this been adequately addressed?
Sort of. Basically if you don't use memoryviews it will be as fast as it used to be, otherwise there is about a 3 second constant time overhead (on my machine).
The other issue is that there are a couple of doctest failures with Sage. One source of problems is decorators due to the (ugly) disallowing of function re-declarations, I'll try look into this one. There are also a huge number of segfaults (see the bottom of https://sage.math.washington.edu:8091/hudson/view/ext-libs/job/sage-tests/la... ) which we need to get to the bottom of.
Oh I see. I suppose to try it out under a debugger one would have to compile the whole of sage from source?
It might be easier to log into sage.math, go to the sage build directory that Jenkins uses and do some experiments there. It's in
/levi/scratch/robertwb/hudson/sage-4.8/
And compiling Sage from scratch isn't actually that hard: type "make" and wait a couple of hours. I've updated the description at https://sage.math.washington.edu:8091/hudson/view/ext-libs/job/sage-build/ to explain how to build a cython-devel sage locally as others have asked for this as well, in summary you apply the patch at http://sage.math.washington.edu/home/robertwb/hudson-sage/sage-4.8/devel/sag... to the repo in $SAGE_ROOT/devel/sage-main/ , install https://sage.math.washington.edu:8091/hudson/view/ext-libs/job/sage-build/la... by downloading it and running "sage -i cython-devel.spkg" and then do "sage -ba" to re-build all Cython files. sage -gdb and sage -t -gdb /path/to/file are useful to know as well. - Robert
On 1/25/12 11:39 AM, Robert Bradshaw wrote:
install https://sage.math.washington.edu:8091/hudson/view/ext-libs/job/sage-build/la... by downloading it and running "sage -i cython-devel.spkg"
In fact, you could just do sage -i https://sage.math.washington.edu:8091/hudson/view/ext-libs/job/sage-build/la... and Sage will (at least, should) download it for you, so that's even one less step! Jason
2012/1/26 Jason Grout <jason-sage@creativetrax.com>:
On 1/25/12 11:39 AM, Robert Bradshaw wrote:
install
https://sage.math.washington.edu:8091/hudson/view/ext-libs/job/sage-build/la... by downloading it and running "sage -i cython-devel.spkg"
In fact, you could just do
sage -i https://sage.math.washington.edu:8091/hudson/view/ext-libs/job/sage-build/la...
and Sage will (at least, should) download it for you, so that's even one less step!
Jason
Thanks for detailed instruction! I've successfully built it. "sage -t -gdb ./...." doesn't work, is that a bug? vitja@mchome:~/Downloads/sage-4.8$ ./sage -t -gdb devel/sage/sage/combinat/sf/macdonald.py sage -t -gdb "devel/sage/sage/combinat/sf/macdonald.py" ******************************************************************************** Type r at the (gdb) prompt to run the doctests. Type bt if there is a crash to see a traceback. ******************************************************************************** gdb --args python /home/vitja/.sage//tmp/macdonald_6182.py starting cmd gdb --args python /home/vitja/.sage//tmp/macdonald_6182.py ImportError: No module named site [0.2 s] ---------------------------------------------------------------------- The following tests failed: sage -t -gdb "devel/sage/sage/combinat/sf/macdonald.py" Total time for all tests: 0.2 seconds I've found another way to run tests (using sage -sh and then direct python ~/.sage/tmp/...py) So I found one of the problems. Here is minimal cython example: def foo(values): return (0,)*len(values) foo([1,2,3]) len(values) somehow is passed as an integer to PyObject_Multiply() -- vitja.
On Sat, Jan 28, 2012 at 8:05 AM, Vitja Makarov <vitja.makarov@gmail.com> wrote:
2012/1/26 Jason Grout <jason-sage@creativetrax.com>:
On 1/25/12 11:39 AM, Robert Bradshaw wrote:
install
https://sage.math.washington.edu:8091/hudson/view/ext-libs/job/sage-build/la... by downloading it and running "sage -i cython-devel.spkg"
In fact, you could just do
sage -i https://sage.math.washington.edu:8091/hudson/view/ext-libs/job/sage-build/la...
and Sage will (at least, should) download it for you, so that's even one less step!
Jason
Thanks for detailed instruction! I've successfully built it.
"sage -t -gdb ./...." doesn't work, is that a bug?
vitja@mchome:~/Downloads/sage-4.8$ ./sage -t -gdb devel/sage/sage/combinat/sf/macdonald.py sage -t -gdb "devel/sage/sage/combinat/sf/macdonald.py" ******************************************************************************** Type r at the (gdb) prompt to run the doctests. Type bt if there is a crash to see a traceback. ******************************************************************************** gdb --args python /home/vitja/.sage//tmp/macdonald_6182.py starting cmd gdb --args python /home/vitja/.sage//tmp/macdonald_6182.py ImportError: No module named site [0.2 s]
---------------------------------------------------------------------- The following tests failed:
sage -t -gdb "devel/sage/sage/combinat/sf/macdonald.py" Total time for all tests: 0.2 seconds
Yes, that's a bug.
I've found another way to run tests (using sage -sh and then direct python ~/.sage/tmp/...py)
So I found one of the problems. Here is minimal cython example:
def foo(values): return (0,)*len(values) foo([1,2,3])
len(values) somehow is passed as an integer to PyObject_Multiply()
Yeah, that's a bug too :).
2012/1/31 Robert Bradshaw <robertwb@math.washington.edu>:
On Sat, Jan 28, 2012 at 8:05 AM, Vitja Makarov <vitja.makarov@gmail.com> wrote:
2012/1/26 Jason Grout <jason-sage@creativetrax.com>:
On 1/25/12 11:39 AM, Robert Bradshaw wrote:
install
https://sage.math.washington.edu:8091/hudson/view/ext-libs/job/sage-build/la... by downloading it and running "sage -i cython-devel.spkg"
In fact, you could just do
sage -i https://sage.math.washington.edu:8091/hudson/view/ext-libs/job/sage-build/la...
and Sage will (at least, should) download it for you, so that's even one less step!
Jason
Thanks for detailed instruction! I've successfully built it.
"sage -t -gdb ./...." doesn't work, is that a bug?
vitja@mchome:~/Downloads/sage-4.8$ ./sage -t -gdb devel/sage/sage/combinat/sf/macdonald.py sage -t -gdb "devel/sage/sage/combinat/sf/macdonald.py" ******************************************************************************** Type r at the (gdb) prompt to run the doctests. Type bt if there is a crash to see a traceback. ******************************************************************************** gdb --args python /home/vitja/.sage//tmp/macdonald_6182.py starting cmd gdb --args python /home/vitja/.sage//tmp/macdonald_6182.py ImportError: No module named site [0.2 s]
---------------------------------------------------------------------- The following tests failed:
sage -t -gdb "devel/sage/sage/combinat/sf/macdonald.py"release Total time for all tests: 0.2 seconds
Yes, that's a bug.
I've found another way to run tests (using sage -sh and then direct python ~/.sage/tmp/...py)
So I found one of the problems. Here is minimal cython example:
def foo(values): return (0,)*len(values) foo([1,2,3])
len(values) somehow is passed as an integer to PyObject_Multiply()
Yeah, that's a bug too :).
I've fixed tuple mult_factor bug here: https://github.com/cython/cython/commit/2d4b85dbcef885fbdaf6a3b2daef7a017184... No more segfaults in sage-tests but still 7 errors. -- vitja.
Vitja Makarov, 04.02.2012 19:49:
On Sat, Jan 28, 2012 at 8:05 AM, Vitja Makarov wrote:
So I found one of the problems. Here is minimal cython example:
def foo(values): return (0,)*len(values) foo([1,2,3])
len(values) somehow is passed as an integer to PyObject_Multiply()
I've fixed tuple mult_factor bug here:
https://github.com/cython/cython/commit/2d4b85dbcef885fbdaf6a3b2daef7a017184...
I didn't have any time to look into this, but your fix seems right. Thanks! Stefan
On Sat, Feb 4, 2012 at 10:49 AM, Vitja Makarov <vitja.makarov@gmail.com> wrote:
2012/1/31 Robert Bradshaw <robertwb@math.washington.edu>:
On Sat, Jan 28, 2012 at 8:05 AM, Vitja Makarov <vitja.makarov@gmail.com> wrote:
2012/1/26 Jason Grout <jason-sage@creativetrax.com>:
On 1/25/12 11:39 AM, Robert Bradshaw wrote:
install
https://sage.math.washington.edu:8091/hudson/view/ext-libs/job/sage-build/la... by downloading it and running "sage -i cython-devel.spkg"
In fact, you could just do
sage -i https://sage.math.washington.edu:8091/hudson/view/ext-libs/job/sage-build/la...
and Sage will (at least, should) download it for you, so that's even one less step!
Jason
Thanks for detailed instruction! I've successfully built it.
"sage -t -gdb ./...." doesn't work, is that a bug?
vitja@mchome:~/Downloads/sage-4.8$ ./sage -t -gdb devel/sage/sage/combinat/sf/macdonald.py sage -t -gdb "devel/sage/sage/combinat/sf/macdonald.py" ******************************************************************************** Type r at the (gdb) prompt to run the doctests. Type bt if there is a crash to see a traceback. ******************************************************************************** gdb --args python /home/vitja/.sage//tmp/macdonald_6182.py starting cmd gdb --args python /home/vitja/.sage//tmp/macdonald_6182.py ImportError: No module named site [0.2 s]
---------------------------------------------------------------------- The following tests failed:
sage -t -gdb "devel/sage/sage/combinat/sf/macdonald.py"release Total time for all tests: 0.2 seconds
Yes, that's a bug.
I've found another way to run tests (using sage -sh and then direct python ~/.sage/tmp/...py)
So I found one of the problems. Here is minimal cython example:
def foo(values): return (0,)*len(values) foo([1,2,3])
len(values) somehow is passed as an integer to PyObject_Multiply()
Yeah, that's a bug too :).
I've fixed tuple mult_factor bug here:
https://github.com/cython/cython/commit/2d4b85dbcef885fbdaf6a3b2daef7a017184...
No more segfaults in sage-tests but still 7 errors.
Thanks! I've looked into the other errors and I think it boils down to our use of --disable-function-redefinition being incompatible with how decorators work. Of course that was just a hack, so I've fixed sage to build/startup without using that flag, but there's some strangeness with import order now that I haven't had time to resolve yet.
All of Sage passes except for one test: sage -t devel/sage/sage/misc/sageinspect.py ********************************************************************** File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", line 970: sage: sage_getargspec(bernstein_polynomial_factory_ratlist.coeffs_bitsize) Expected: ArgSpec(args=['self'], varargs=None, keywords=None, defaults=None) Got: ArgSpec(args=['self'], varargs=None, keywords=None, defaults=()) ********************************************************************** File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", line 973: sage: sage_getargspec(BooleanMonomialMonoid.gen) Expected: ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=(0,)) Got: ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=()) ********************************************************************** 1 items had failures: 2 of 31 in __main__.example_21 ***Test Failed*** 2 failures. Any ideas why this would have changed? On Sun, Feb 5, 2012 at 2:31 AM, Robert Bradshaw <robertwb@math.washington.edu> wrote:
On Sat, Feb 4, 2012 at 10:49 AM, Vitja Makarov <vitja.makarov@gmail.com> wrote:
2012/1/31 Robert Bradshaw <robertwb@math.washington.edu>:
On Sat, Jan 28, 2012 at 8:05 AM, Vitja Makarov <vitja.makarov@gmail.com> wrote:
2012/1/26 Jason Grout <jason-sage@creativetrax.com>:
On 1/25/12 11:39 AM, Robert Bradshaw wrote:
install
https://sage.math.washington.edu:8091/hudson/view/ext-libs/job/sage-build/la... by downloading it and running "sage -i cython-devel.spkg"
In fact, you could just do
sage -i https://sage.math.washington.edu:8091/hudson/view/ext-libs/job/sage-build/la...
and Sage will (at least, should) download it for you, so that's even one less step!
Jason
Thanks for detailed instruction! I've successfully built it.
"sage -t -gdb ./...." doesn't work, is that a bug?
vitja@mchome:~/Downloads/sage-4.8$ ./sage -t -gdb devel/sage/sage/combinat/sf/macdonald.py sage -t -gdb "devel/sage/sage/combinat/sf/macdonald.py" ******************************************************************************** Type r at the (gdb) prompt to run the doctests. Type bt if there is a crash to see a traceback. ******************************************************************************** gdb --args python /home/vitja/.sage//tmp/macdonald_6182.py starting cmd gdb --args python /home/vitja/.sage//tmp/macdonald_6182.py ImportError: No module named site [0.2 s]
---------------------------------------------------------------------- The following tests failed:
sage -t -gdb "devel/sage/sage/combinat/sf/macdonald.py"release Total time for all tests: 0.2 seconds
Yes, that's a bug.
I've found another way to run tests (using sage -sh and then direct python ~/.sage/tmp/...py)
So I found one of the problems. Here is minimal cython example:
def foo(values): return (0,)*len(values) foo([1,2,3])
len(values) somehow is passed as an integer to PyObject_Multiply()
Yeah, that's a bug too :).
I've fixed tuple mult_factor bug here:
https://github.com/cython/cython/commit/2d4b85dbcef885fbdaf6a3b2daef7a017184...
No more segfaults in sage-tests but still 7 errors.
Thanks! I've looked into the other errors and I think it boils down to our use of --disable-function-redefinition being incompatible with how decorators work. Of course that was just a hack, so I've fixed sage to build/startup without using that flag, but there's some strangeness with import order now that I haven't had time to resolve yet.
2012/2/11 Robert Bradshaw <robertwb@math.washington.edu>:
All of Sage passes except for one test:
sage -t devel/sage/sage/misc/sageinspect.py ********************************************************************** File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", line 970: sage: sage_getargspec(bernstein_polynomial_factory_ratlist.coeffs_bitsize) Expected: ArgSpec(args=['self'], varargs=None, keywords=None, defaults=None) Got: ArgSpec(args=['self'], varargs=None, keywords=None, defaults=()) ********************************************************************** File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", line 973: sage: sage_getargspec(BooleanMonomialMonoid.gen) Expected: ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=(0,)) Got: ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=()) ********************************************************************** 1 items had failures: 2 of 31 in __main__.example_21 ***Test Failed*** 2 failures.
Any ideas why this would have changed?
CyFunction now provides its own code object. So inspect.getargs() is called instead of inspect.ArgSpec(*_sage_getargspec_cython(sage_getsource(obj))). It seems like func.func_defaults should be implemented. -- vitja.
2012/2/12 Vitja Makarov <vitja.makarov@gmail.com>:
2012/2/11 Robert Bradshaw <robertwb@math.washington.edu>:
All of Sage passes except for one test:
sage -t devel/sage/sage/misc/sageinspect.py ********************************************************************** File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", line 970: sage: sage_getargspec(bernstein_polynomial_factory_ratlist.coeffs_bitsize) Expected: ArgSpec(args=['self'], varargs=None, keywords=None, defaults=None) Got: ArgSpec(args=['self'], varargs=None, keywords=None, defaults=()) ********************************************************************** File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", line 973: sage: sage_getargspec(BooleanMonomialMonoid.gen) Expected: ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=(0,)) Got: ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=()) ********************************************************************** 1 items had failures: 2 of 31 in __main__.example_21 ***Test Failed*** 2 failures.
Any ideas why this would have changed?
CyFunction now provides its own code object. So inspect.getargs() is called instead of inspect.ArgSpec(*_sage_getargspec_cython(sage_getsource(obj))). It seems like func.func_defaults should be implemented.
I've created a pull request: https://github.com/cython/cython/pull/88 -- vitja.
On Sun, Feb 12, 2012 at 12:53 PM, Vitja Makarov <vitja.makarov@gmail.com> wrote:
2012/2/12 Vitja Makarov <vitja.makarov@gmail.com>:
2012/2/11 Robert Bradshaw <robertwb@math.washington.edu>:
All of Sage passes except for one test:
sage -t devel/sage/sage/misc/sageinspect.py ********************************************************************** File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", line 970: sage: sage_getargspec(bernstein_polynomial_factory_ratlist.coeffs_bitsize) Expected: ArgSpec(args=['self'], varargs=None, keywords=None, defaults=None) Got: ArgSpec(args=['self'], varargs=None, keywords=None, defaults=()) ********************************************************************** File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", line 973: sage: sage_getargspec(BooleanMonomialMonoid.gen) Expected: ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=(0,)) Got: ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=()) ********************************************************************** 1 items had failures: 2 of 31 in __main__.example_21 ***Test Failed*** 2 failures.
Any ideas why this would have changed?
CyFunction now provides its own code object. So inspect.getargs() is called instead of inspect.ArgSpec(*_sage_getargspec_cython(sage_getsource(obj))). It seems like func.func_defaults should be implemented.
I've created a pull request:
Thanks! The only other thing I can think of was a question of using caching to mitigate the longer compile times, but I can't remember if this was resolved. As I'm going to be MIA any day now, someone else should take up the banner to push this long awaited release. - Robert
On 14 February 2012 07:07, Robert Bradshaw <robertwb@math.washington.edu> wrote:
On Sun, Feb 12, 2012 at 12:53 PM, Vitja Makarov <vitja.makarov@gmail.com> wrote:
2012/2/12 Vitja Makarov <vitja.makarov@gmail.com>:
2012/2/11 Robert Bradshaw <robertwb@math.washington.edu>:
All of Sage passes except for one test:
sage -t devel/sage/sage/misc/sageinspect.py ********************************************************************** File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", line 970: sage: sage_getargspec(bernstein_polynomial_factory_ratlist.coeffs_bitsize) Expected: ArgSpec(args=['self'], varargs=None, keywords=None, defaults=None) Got: ArgSpec(args=['self'], varargs=None, keywords=None, defaults=()) ********************************************************************** File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", line 973: sage: sage_getargspec(BooleanMonomialMonoid.gen) Expected: ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=(0,)) Got: ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=()) ********************************************************************** 1 items had failures: 2 of 31 in __main__.example_21 ***Test Failed*** 2 failures.
Any ideas why this would have changed?
CyFunction now provides its own code object. So inspect.getargs() is called instead of inspect.ArgSpec(*_sage_getargspec_cython(sage_getsource(obj))). It seems like func.func_defaults should be implemented.
I've created a pull request:
Thanks! The only other thing I can think of was a question of using caching to mitigate the longer compile times, but I can't remember if this was resolved.
The compiler has like 2 or 3 seconds of constant overhead if you use memoryviews.
As I'm going to be MIA any day now, someone else should take up the banner to push this long awaited release.
"Missing in action"? Are you planning to desert? :) I can't find any relevant abbreviation, but I think I know what it means, congratulations in advance. Stefan, you have been involved the longest, would you feel up to the task? You probably have the best understanding and experience with any issues (no pressure :). Otherwise I could have a try...
- Robert _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
On Tue, Feb 14, 2012 at 7:49 AM, mark florisson <markflorisson88@gmail.com> wrote:
On 14 February 2012 07:07, Robert Bradshaw <robertwb@math.washington.edu> wrote:
On Sun, Feb 12, 2012 at 12:53 PM, Vitja Makarov <vitja.makarov@gmail.com> wrote:
2012/2/12 Vitja Makarov <vitja.makarov@gmail.com>:
2012/2/11 Robert Bradshaw <robertwb@math.washington.edu>:
All of Sage passes except for one test:
sage -t devel/sage/sage/misc/sageinspect.py ********************************************************************** File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", line 970: sage: sage_getargspec(bernstein_polynomial_factory_ratlist.coeffs_bitsize) Expected: ArgSpec(args=['self'], varargs=None, keywords=None, defaults=None) Got: ArgSpec(args=['self'], varargs=None, keywords=None, defaults=()) ********************************************************************** File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", line 973: sage: sage_getargspec(BooleanMonomialMonoid.gen) Expected: ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=(0,)) Got: ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=()) ********************************************************************** 1 items had failures: 2 of 31 in __main__.example_21 ***Test Failed*** 2 failures.
Any ideas why this would have changed?
CyFunction now provides its own code object. So inspect.getargs() is called instead of inspect.ArgSpec(*_sage_getargspec_cython(sage_getsource(obj))). It seems like func.func_defaults should be implemented.
I've created a pull request:
Thanks! The only other thing I can think of was a question of using caching to mitigate the longer compile times, but I can't remember if this was resolved.
The compiler has like 2 or 3 seconds of constant overhead if you use memoryviews.
That'd be nice to cut down, but certainly not a blocker.
As I'm going to be MIA any day now, someone else should take up the banner to push this long awaited release.
"Missing in action"? Are you planning to desert? :) I can't find any relevant abbreviation, but I think I know what it means, congratulations in advance.
Twin boys coming any day now!
Stefan, you have been involved the longest, would you feel up to the task? You probably have the best understanding and experience with any issues (no pressure :). Otherwise I could have a try...
It's pretty easy. Once the defaults change is in it's probably worth cutting a beta or release candidate to email to dev/users, and if there's no blocking feedback you go ahead and push it out (basically writing up the release notes on the wiki, cleaning up trac, tagging the repository, making sure everything we care about on hudson is still passing, uploading to pypi and the website (the sdist tarball), emailing our lists and python-announce, re-building and updating the pointer to the documentation, ...) If it goes on for a while it's worth making/using a release branch on github. - Robert
On 14 February 2012 17:19, Robert Bradshaw <robertwb@math.washington.edu> wrote:
On Tue, Feb 14, 2012 at 7:49 AM, mark florisson <markflorisson88@gmail.com> wrote:
On 14 February 2012 07:07, Robert Bradshaw <robertwb@math.washington.edu> wrote:
On Sun, Feb 12, 2012 at 12:53 PM, Vitja Makarov <vitja.makarov@gmail.com> wrote:
2012/2/12 Vitja Makarov <vitja.makarov@gmail.com>:
2012/2/11 Robert Bradshaw <robertwb@math.washington.edu>:
All of Sage passes except for one test:
sage -t devel/sage/sage/misc/sageinspect.py ********************************************************************** File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", line 970: sage: sage_getargspec(bernstein_polynomial_factory_ratlist.coeffs_bitsize) Expected: ArgSpec(args=['self'], varargs=None, keywords=None, defaults=None) Got: ArgSpec(args=['self'], varargs=None, keywords=None, defaults=()) ********************************************************************** File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", line 973: sage: sage_getargspec(BooleanMonomialMonoid.gen) Expected: ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=(0,)) Got: ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=()) ********************************************************************** 1 items had failures: 2 of 31 in __main__.example_21 ***Test Failed*** 2 failures.
Any ideas why this would have changed?
CyFunction now provides its own code object. So inspect.getargs() is called instead of inspect.ArgSpec(*_sage_getargspec_cython(sage_getsource(obj))). It seems like func.func_defaults should be implemented.
I've created a pull request:
Thanks! The only other thing I can think of was a question of using caching to mitigate the longer compile times, but I can't remember if this was resolved.
The compiler has like 2 or 3 seconds of constant overhead if you use memoryviews.
That'd be nice to cut down, but certainly not a blocker.
As I'm going to be MIA any day now, someone else should take up the banner to push this long awaited release.
"Missing in action"? Are you planning to desert? :) I can't find any relevant abbreviation, but I think I know what it means, congratulations in advance.
Twin boys coming any day now!
And the Cython team just keeps on growing!
Stefan, you have been involved the longest, would you feel up to the task? You probably have the best understanding and experience with any issues (no pressure :). Otherwise I could have a try...
It's pretty easy. Once the defaults change is in it's probably worth cutting a beta or release candidate to email to dev/users, and if there's no blocking feedback you go ahead and push it out (basically writing up the release notes on the wiki, cleaning up trac, tagging the repository, making sure everything we care about on hudson is still passing, uploading to pypi and the website (the sdist tarball), emailing our lists and python-announce, re-building and updating the pointer to the documentation, ...) If it goes on for a while it's worth making/using a release branch on github.
Thanks for the summary, I'm sure I would have missed one or two :) Ok, I'll volunteer then. Maybe I can create a beta somewhere next week and then we can see the community tear it apart.
- Robert _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
On Tue, Feb 14, 2012 at 1:09 PM, mark florisson <markflorisson88@gmail.com> wrote:
On 14 February 2012 17:19, Robert Bradshaw <robertwb@math.washington.edu> wrote:
On Tue, Feb 14, 2012 at 7:49 AM, mark florisson <markflorisson88@gmail.com> wrote:
On 14 February 2012 07:07, Robert Bradshaw <robertwb@math.washington.edu> wrote:
On Sun, Feb 12, 2012 at 12:53 PM, Vitja Makarov <vitja.makarov@gmail.com> wrote:
2012/2/12 Vitja Makarov <vitja.makarov@gmail.com>:
2012/2/11 Robert Bradshaw <robertwb@math.washington.edu>: > All of Sage passes except for one test: > > sage -t devel/sage/sage/misc/sageinspect.py > ********************************************************************** > File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", > line 970: > sage: sage_getargspec(bernstein_polynomial_factory_ratlist.coeffs_bitsize) > Expected: > ArgSpec(args=['self'], varargs=None, keywords=None, defaults=None) > Got: > ArgSpec(args=['self'], varargs=None, keywords=None, defaults=()) > ********************************************************************** > File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", > line 973: > sage: sage_getargspec(BooleanMonomialMonoid.gen) > Expected: > ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=(0,)) > Got: > ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=()) > ********************************************************************** > 1 items had failures: > 2 of 31 in __main__.example_21 > ***Test Failed*** 2 failures. > > Any ideas why this would have changed? >
CyFunction now provides its own code object. So inspect.getargs() is called instead of inspect.ArgSpec(*_sage_getargspec_cython(sage_getsource(obj))). It seems like func.func_defaults should be implemented.
I've created a pull request:
Thanks! The only other thing I can think of was a question of using caching to mitigate the longer compile times, but I can't remember if this was resolved.
The compiler has like 2 or 3 seconds of constant overhead if you use memoryviews.
That'd be nice to cut down, but certainly not a blocker.
As I'm going to be MIA any day now, someone else should take up the banner to push this long awaited release.
"Missing in action"? Are you planning to desert? :) I can't find any relevant abbreviation, but I think I know what it means, congratulations in advance.
Twin boys coming any day now!
And the Cython team just keeps on growing!
:)
Stefan, you have been involved the longest, would you feel up to the task? You probably have the best understanding and experience with any issues (no pressure :). Otherwise I could have a try...
It's pretty easy. Once the defaults change is in it's probably worth cutting a beta or release candidate to email to dev/users, and if there's no blocking feedback you go ahead and push it out (basically writing up the release notes on the wiki, cleaning up trac, tagging the repository, making sure everything we care about on hudson is still passing, uploading to pypi and the website (the sdist tarball), emailing our lists and python-announce, re-building and updating the pointer to the documentation, ...) If it goes on for a while it's worth making/using a release branch on github.
Thanks for the summary, I'm sure I would have missed one or two :) Ok, I'll volunteer then. Maybe I can create a beta somewhere next week and then we can see the community tear it apart.
Thanks! - Robert
On 14 February 2012 21:33, Robert Bradshaw <robertwb@math.washington.edu> wrote:
On Tue, Feb 14, 2012 at 1:09 PM, mark florisson <markflorisson88@gmail.com> wrote:
On 14 February 2012 17:19, Robert Bradshaw <robertwb@math.washington.edu> wrote:
On Tue, Feb 14, 2012 at 7:49 AM, mark florisson <markflorisson88@gmail.com> wrote:
On 14 February 2012 07:07, Robert Bradshaw <robertwb@math.washington.edu> wrote:
On Sun, Feb 12, 2012 at 12:53 PM, Vitja Makarov <vitja.makarov@gmail.com> wrote:
2012/2/12 Vitja Makarov <vitja.makarov@gmail.com>: > 2012/2/11 Robert Bradshaw <robertwb@math.washington.edu>: >> All of Sage passes except for one test: >> >> sage -t devel/sage/sage/misc/sageinspect.py >> ********************************************************************** >> File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", >> line 970: >> sage: sage_getargspec(bernstein_polynomial_factory_ratlist.coeffs_bitsize) >> Expected: >> ArgSpec(args=['self'], varargs=None, keywords=None, defaults=None) >> Got: >> ArgSpec(args=['self'], varargs=None, keywords=None, defaults=()) >> ********************************************************************** >> File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", >> line 973: >> sage: sage_getargspec(BooleanMonomialMonoid.gen) >> Expected: >> ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=(0,)) >> Got: >> ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=()) >> ********************************************************************** >> 1 items had failures: >> 2 of 31 in __main__.example_21 >> ***Test Failed*** 2 failures. >> >> Any ideas why this would have changed? >> > > CyFunction now provides its own code object. So inspect.getargs() is > called instead of > inspect.ArgSpec(*_sage_getargspec_cython(sage_getsource(obj))). It > seems like func.func_defaults should be implemented. > >
I've created a pull request:
Thanks! The only other thing I can think of was a question of using caching to mitigate the longer compile times, but I can't remember if this was resolved.
The compiler has like 2 or 3 seconds of constant overhead if you use memoryviews.
That'd be nice to cut down, but certainly not a blocker.
As I'm going to be MIA any day now, someone else should take up the banner to push this long awaited release.
"Missing in action"? Are you planning to desert? :) I can't find any relevant abbreviation, but I think I know what it means, congratulations in advance.
Twin boys coming any day now!
And the Cython team just keeps on growing!
:)
Stefan, you have been involved the longest, would you feel up to the task? You probably have the best understanding and experience with any issues (no pressure :). Otherwise I could have a try...
It's pretty easy. Once the defaults change is in it's probably worth cutting a beta or release candidate to email to dev/users, and if there's no blocking feedback you go ahead and push it out (basically writing up the release notes on the wiki, cleaning up trac, tagging the repository, making sure everything we care about on hudson is still passing, uploading to pypi and the website (the sdist tarball), emailing our lists and python-announce, re-building and updating the pointer to the documentation, ...) If it goes on for a while it's worth making/using a release branch on github.
Thanks for the summary, I'm sure I would have missed one or two :) Ok, I'll volunteer then. Maybe I can create a beta somewhere next week and then we can see the community tear it apart.
Thanks!
- Robert _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Sorry, my previous email with attachment bounced. Here goes. I'm getting a substantial amount of failing tests on MSVC, https://gist.github.com/1836766. I think most complex number tests are failing because they cast a struct of a certain type to itself like ((struct_A) my_struct_A), which MSVC doesn't allow. Some tests seem to fail because they can't be imported: "compiling (c) and running numpy_parallel: ImportError: No module named numpy_parallel". And then there is a huge number of permission errors: WindowsError: [Error 5] Access is denied: 'c:\\Users\\mark\\cython\\BUILD\\compile\\cpp\\libc_math.pyd' . Maybe something is broken in the test runner (or in my setup somehow)?
On 15 February 2012 15:45, mark florisson <markflorisson88@gmail.com> wrote:
On 14 February 2012 21:33, Robert Bradshaw <robertwb@math.washington.edu> wrote:
On Tue, Feb 14, 2012 at 1:09 PM, mark florisson <markflorisson88@gmail.com> wrote:
On 14 February 2012 17:19, Robert Bradshaw <robertwb@math.washington.edu> wrote:
On Tue, Feb 14, 2012 at 7:49 AM, mark florisson <markflorisson88@gmail.com> wrote:
On 14 February 2012 07:07, Robert Bradshaw <robertwb@math.washington.edu> wrote:
On Sun, Feb 12, 2012 at 12:53 PM, Vitja Makarov <vitja.makarov@gmail.com> wrote: > 2012/2/12 Vitja Makarov <vitja.makarov@gmail.com>: >> 2012/2/11 Robert Bradshaw <robertwb@math.washington.edu>: >>> All of Sage passes except for one test: >>> >>> sage -t devel/sage/sage/misc/sageinspect.py >>> ********************************************************************** >>> File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", >>> line 970: >>> sage: sage_getargspec(bernstein_polynomial_factory_ratlist.coeffs_bitsize) >>> Expected: >>> ArgSpec(args=['self'], varargs=None, keywords=None, defaults=None) >>> Got: >>> ArgSpec(args=['self'], varargs=None, keywords=None, defaults=()) >>> ********************************************************************** >>> File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", >>> line 973: >>> sage: sage_getargspec(BooleanMonomialMonoid.gen) >>> Expected: >>> ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=(0,)) >>> Got: >>> ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=()) >>> ********************************************************************** >>> 1 items had failures: >>> 2 of 31 in __main__.example_21 >>> ***Test Failed*** 2 failures. >>> >>> Any ideas why this would have changed? >>> >> >> CyFunction now provides its own code object. So inspect.getargs() is >> called instead of >> inspect.ArgSpec(*_sage_getargspec_cython(sage_getsource(obj))). It >> seems like func.func_defaults should be implemented. >> >> > > I've created a pull request: > > https://github.com/cython/cython/pull/88
Thanks! The only other thing I can think of was a question of using caching to mitigate the longer compile times, but I can't remember if this was resolved.
The compiler has like 2 or 3 seconds of constant overhead if you use memoryviews.
That'd be nice to cut down, but certainly not a blocker.
As I'm going to be MIA any day now, someone else should take up the banner to push this long awaited release.
"Missing in action"? Are you planning to desert? :) I can't find any relevant abbreviation, but I think I know what it means, congratulations in advance.
Twin boys coming any day now!
And the Cython team just keeps on growing!
:)
Stefan, you have been involved the longest, would you feel up to the task? You probably have the best understanding and experience with any issues (no pressure :). Otherwise I could have a try...
It's pretty easy. Once the defaults change is in it's probably worth cutting a beta or release candidate to email to dev/users, and if there's no blocking feedback you go ahead and push it out (basically writing up the release notes on the wiki, cleaning up trac, tagging the repository, making sure everything we care about on hudson is still passing, uploading to pypi and the website (the sdist tarball), emailing our lists and python-announce, re-building and updating the pointer to the documentation, ...) If it goes on for a while it's worth making/using a release branch on github.
Thanks for the summary, I'm sure I would have missed one or two :) Ok, I'll volunteer then. Maybe I can create a beta somewhere next week and then we can see the community tear it apart.
Thanks!
- Robert _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Sorry, my previous email with attachment bounced. Here goes.
I'm getting a substantial amount of failing tests on MSVC, https://gist.github.com/1836766. I think most complex number tests are failing because they cast a struct of a certain type to itself like ((struct_A) my_struct_A), which MSVC doesn't allow.
Some tests seem to fail because they can't be imported: "compiling (c) and running numpy_parallel: ImportError: No module named numpy_parallel".
And then there is a huge number of permission errors: WindowsError: [Error 5] Access is denied: 'c:\\Users\\mark\\cython\\BUILD\\compile\\cpp\\libc_math.pyd' . Maybe something is broken in the test runner (or in my setup somehow)?
The pasted output is a little munged because it was redirected to a log (and stdout is probably block buffering, something we could also fix to line buffering).
2012/2/15 mark florisson <markflorisson88@gmail.com>:
On 15 February 2012 15:45, mark florisson <markflorisson88@gmail.com> wrote:
On 14 February 2012 21:33, Robert Bradshaw <robertwb@math.washington.edu> wrote:
On Tue, Feb 14, 2012 at 1:09 PM, mark florisson <markflorisson88@gmail.com> wrote:
On 14 February 2012 17:19, Robert Bradshaw <robertwb@math.washington.edu> wrote:
On Tue, Feb 14, 2012 at 7:49 AM, mark florisson <markflorisson88@gmail.com> wrote:
On 14 February 2012 07:07, Robert Bradshaw <robertwb@math.washington.edu> wrote: > On Sun, Feb 12, 2012 at 12:53 PM, Vitja Makarov <vitja.makarov@gmail.com> wrote: >> 2012/2/12 Vitja Makarov <vitja.makarov@gmail.com>: >>> 2012/2/11 Robert Bradshaw <robertwb@math.washington.edu>: >>>> All of Sage passes except for one test: >>>> >>>> sage -t devel/sage/sage/misc/sageinspect.py >>>> ********************************************************************** >>>> File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", >>>> line 970: >>>> sage: sage_getargspec(bernstein_polynomial_factory_ratlist.coeffs_bitsize) >>>> Expected: >>>> ArgSpec(args=['self'], varargs=None, keywords=None, defaults=None) >>>> Got: >>>> ArgSpec(args=['self'], varargs=None, keywords=None, defaults=()) >>>> ********************************************************************** >>>> File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", >>>> line 973: >>>> sage: sage_getargspec(BooleanMonomialMonoid.gen) >>>> Expected: >>>> ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=(0,)) >>>> Got: >>>> ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=()) >>>> ********************************************************************** >>>> 1 items had failures: >>>> 2 of 31 in __main__.example_21 >>>> ***Test Failed*** 2 failures. >>>> >>>> Any ideas why this would have changed? >>>> >>> >>> CyFunction now provides its own code object. So inspect.getargs() is >>> called instead of >>> inspect.ArgSpec(*_sage_getargspec_cython(sage_getsource(obj))). It >>> seems like func.func_defaults should be implemented. >>> >>> >> >> I've created a pull request: >> >> https://github.com/cython/cython/pull/88 > > Thanks! The only other thing I can think of was a question of using > caching to mitigate the longer compile times, but I can't remember if > this was resolved.
The compiler has like 2 or 3 seconds of constant overhead if you use memoryviews.
That'd be nice to cut down, but certainly not a blocker.
> As I'm going to be MIA any day now, someone else should take up the > banner to push this long awaited release.
"Missing in action"? Are you planning to desert? :) I can't find any relevant abbreviation, but I think I know what it means, congratulations in advance.
Twin boys coming any day now!
And the Cython team just keeps on growing!
:)
Stefan, you have been involved the longest, would you feel up to the task? You probably have the best understanding and experience with any issues (no pressure :). Otherwise I could have a try...
It's pretty easy. Once the defaults change is in it's probably worth cutting a beta or release candidate to email to dev/users, and if there's no blocking feedback you go ahead and push it out (basically writing up the release notes on the wiki, cleaning up trac, tagging the repository, making sure everything we care about on hudson is still passing, uploading to pypi and the website (the sdist tarball), emailing our lists and python-announce, re-building and updating the pointer to the documentation, ...) If it goes on for a while it's worth making/using a release branch on github.
Thanks for the summary, I'm sure I would have missed one or two :) Ok, I'll volunteer then. Maybe I can create a beta somewhere next week and then we can see the community tear it apart.
Thanks!
- Robert _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Sorry, my previous email with attachment bounced. Here goes.
I'm getting a substantial amount of failing tests on MSVC, https://gist.github.com/1836766. I think most complex number tests are failing because they cast a struct of a certain type to itself like ((struct_A) my_struct_A), which MSVC doesn't allow.
Some tests seem to fail because they can't be imported: "compiling (c) and running numpy_parallel: ImportError: No module named numpy_parallel".
And then there is a huge number of permission errors: WindowsError: [Error 5] Access is denied: 'c:\\Users\\mark\\cython\\BUILD\\compile\\cpp\\libc_math.pyd' . Maybe something is broken in the test runner (or in my setup somehow)?
The pasted output is a little munged because it was redirected to a log (and stdout is probably block buffering, something we could also fix to line buffering).
I've merged cydefaults branch and now sage-tests is blue. -- vitja.
On 19 February 2012 10:16, Vitja Makarov <vitja.makarov@gmail.com> wrote:
2012/2/15 mark florisson <markflorisson88@gmail.com>:
On 15 February 2012 15:45, mark florisson <markflorisson88@gmail.com> wrote:
On 14 February 2012 21:33, Robert Bradshaw <robertwb@math.washington.edu> wrote:
On Tue, Feb 14, 2012 at 1:09 PM, mark florisson <markflorisson88@gmail.com> wrote:
On 14 February 2012 17:19, Robert Bradshaw <robertwb@math.washington.edu> wrote:
On Tue, Feb 14, 2012 at 7:49 AM, mark florisson <markflorisson88@gmail.com> wrote: > On 14 February 2012 07:07, Robert Bradshaw <robertwb@math.washington.edu> wrote: >> On Sun, Feb 12, 2012 at 12:53 PM, Vitja Makarov <vitja.makarov@gmail.com> wrote: >>> 2012/2/12 Vitja Makarov <vitja.makarov@gmail.com>: >>>> 2012/2/11 Robert Bradshaw <robertwb@math.washington.edu>: >>>>> All of Sage passes except for one test: >>>>> >>>>> sage -t devel/sage/sage/misc/sageinspect.py >>>>> ********************************************************************** >>>>> File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", >>>>> line 970: >>>>> sage: sage_getargspec(bernstein_polynomial_factory_ratlist.coeffs_bitsize) >>>>> Expected: >>>>> ArgSpec(args=['self'], varargs=None, keywords=None, defaults=None) >>>>> Got: >>>>> ArgSpec(args=['self'], varargs=None, keywords=None, defaults=()) >>>>> ********************************************************************** >>>>> File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", >>>>> line 973: >>>>> sage: sage_getargspec(BooleanMonomialMonoid.gen) >>>>> Expected: >>>>> ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=(0,)) >>>>> Got: >>>>> ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=()) >>>>> ********************************************************************** >>>>> 1 items had failures: >>>>> 2 of 31 in __main__.example_21 >>>>> ***Test Failed*** 2 failures. >>>>> >>>>> Any ideas why this would have changed? >>>>> >>>> >>>> CyFunction now provides its own code object. So inspect.getargs() is >>>> called instead of >>>> inspect.ArgSpec(*_sage_getargspec_cython(sage_getsource(obj))). It >>>> seems like func.func_defaults should be implemented. >>>> >>>> >>> >>> I've created a pull request: >>> >>> https://github.com/cython/cython/pull/88 >> >> Thanks! The only other thing I can think of was a question of using >> caching to mitigate the longer compile times, but I can't remember if >> this was resolved. > > The compiler has like 2 or 3 seconds of constant overhead if you use > memoryviews.
That'd be nice to cut down, but certainly not a blocker.
>> As I'm going to be MIA any day now, someone else should take up the >> banner to push this long awaited release. > > "Missing in action"? Are you planning to desert? :) I can't find any > relevant abbreviation, but I think I know what it means, > congratulations in advance.
Twin boys coming any day now!
And the Cython team just keeps on growing!
:)
> Stefan, you have been involved the longest, would you feel up to the > task? You probably have the best understanding and experience with any > issues (no pressure :). Otherwise I could have a try...
It's pretty easy. Once the defaults change is in it's probably worth cutting a beta or release candidate to email to dev/users, and if there's no blocking feedback you go ahead and push it out (basically writing up the release notes on the wiki, cleaning up trac, tagging the repository, making sure everything we care about on hudson is still passing, uploading to pypi and the website (the sdist tarball), emailing our lists and python-announce, re-building and updating the pointer to the documentation, ...) If it goes on for a while it's worth making/using a release branch on github.
Thanks for the summary, I'm sure I would have missed one or two :) Ok, I'll volunteer then. Maybe I can create a beta somewhere next week and then we can see the community tear it apart.
Thanks!
- Robert _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Sorry, my previous email with attachment bounced. Here goes.
I'm getting a substantial amount of failing tests on MSVC, https://gist.github.com/1836766. I think most complex number tests are failing because they cast a struct of a certain type to itself like ((struct_A) my_struct_A), which MSVC doesn't allow.
Some tests seem to fail because they can't be imported: "compiling (c) and running numpy_parallel: ImportError: No module named numpy_parallel".
And then there is a huge number of permission errors: WindowsError: [Error 5] Access is denied: 'c:\\Users\\mark\\cython\\BUILD\\compile\\cpp\\libc_math.pyd' . Maybe something is broken in the test runner (or in my setup somehow)?
The pasted output is a little munged because it was redirected to a log (and stdout is probably block buffering, something we could also fix to line buffering).
I've merged cydefaults branch and now sage-tests is blue.
Great, thanks. I'll add some tests with default arguments for fused types.
-- vitja. _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
On 19 February 2012 10:16, Vitja Makarov <vitja.makarov@gmail.com> wrote:
2012/2/15 mark florisson <markflorisson88@gmail.com>:
On 15 February 2012 15:45, mark florisson <markflorisson88@gmail.com> wrote:
On 14 February 2012 21:33, Robert Bradshaw <robertwb@math.washington.edu> wrote:
On Tue, Feb 14, 2012 at 1:09 PM, mark florisson <markflorisson88@gmail.com> wrote:
On 14 February 2012 17:19, Robert Bradshaw <robertwb@math.washington.edu> wrote:
On Tue, Feb 14, 2012 at 7:49 AM, mark florisson <markflorisson88@gmail.com> wrote: > On 14 February 2012 07:07, Robert Bradshaw <robertwb@math.washington.edu> wrote: >> On Sun, Feb 12, 2012 at 12:53 PM, Vitja Makarov <vitja.makarov@gmail.com> wrote: >>> 2012/2/12 Vitja Makarov <vitja.makarov@gmail.com>: >>>> 2012/2/11 Robert Bradshaw <robertwb@math.washington.edu>: >>>>> All of Sage passes except for one test: >>>>> >>>>> sage -t devel/sage/sage/misc/sageinspect.py >>>>> ********************************************************************** >>>>> File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", >>>>> line 970: >>>>> sage: sage_getargspec(bernstein_polynomial_factory_ratlist.coeffs_bitsize) >>>>> Expected: >>>>> ArgSpec(args=['self'], varargs=None, keywords=None, defaults=None) >>>>> Got: >>>>> ArgSpec(args=['self'], varargs=None, keywords=None, defaults=()) >>>>> ********************************************************************** >>>>> File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", >>>>> line 973: >>>>> sage: sage_getargspec(BooleanMonomialMonoid.gen) >>>>> Expected: >>>>> ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=(0,)) >>>>> Got: >>>>> ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=()) >>>>> ********************************************************************** >>>>> 1 items had failures: >>>>> 2 of 31 in __main__.example_21 >>>>> ***Test Failed*** 2 failures. >>>>> >>>>> Any ideas why this would have changed? >>>>> >>>> >>>> CyFunction now provides its own code object. So inspect.getargs() is >>>> called instead of >>>> inspect.ArgSpec(*_sage_getargspec_cython(sage_getsource(obj))). It >>>> seems like func.func_defaults should be implemented. >>>> >>>> >>> >>> I've created a pull request: >>> >>> https://github.com/cython/cython/pull/88 >> >> Thanks! The only other thing I can think of was a question of using >> caching to mitigate the longer compile times, but I can't remember if >> this was resolved. > > The compiler has like 2 or 3 seconds of constant overhead if you use > memoryviews.
That'd be nice to cut down, but certainly not a blocker.
>> As I'm going to be MIA any day now, someone else should take up the >> banner to push this long awaited release. > > "Missing in action"? Are you planning to desert? :) I can't find any > relevant abbreviation, but I think I know what it means, > congratulations in advance.
Twin boys coming any day now!
And the Cython team just keeps on growing!
:)
> Stefan, you have been involved the longest, would you feel up to the > task? You probably have the best understanding and experience with any > issues (no pressure :). Otherwise I could have a try...
It's pretty easy. Once the defaults change is in it's probably worth cutting a beta or release candidate to email to dev/users, and if there's no blocking feedback you go ahead and push it out (basically writing up the release notes on the wiki, cleaning up trac, tagging the repository, making sure everything we care about on hudson is still passing, uploading to pypi and the website (the sdist tarball), emailing our lists and python-announce, re-building and updating the pointer to the documentation, ...) If it goes on for a while it's worth making/using a release branch on github.
Thanks for the summary, I'm sure I would have missed one or two :) Ok, I'll volunteer then. Maybe I can create a beta somewhere next week and then we can see the community tear it apart.
Thanks!
- Robert _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Sorry, my previous email with attachment bounced. Here goes.
I'm getting a substantial amount of failing tests on MSVC, https://gist.github.com/1836766. I think most complex number tests are failing because they cast a struct of a certain type to itself like ((struct_A) my_struct_A), which MSVC doesn't allow.
Some tests seem to fail because they can't be imported: "compiling (c) and running numpy_parallel: ImportError: No module named numpy_parallel".
And then there is a huge number of permission errors: WindowsError: [Error 5] Access is denied: 'c:\\Users\\mark\\cython\\BUILD\\compile\\cpp\\libc_math.pyd' . Maybe something is broken in the test runner (or in my setup somehow)?
The pasted output is a little munged because it was redirected to a log (and stdout is probably block buffering, something we could also fix to line buffering).
I've merged cydefaults branch and now sage-tests is blue.
So, if the defaults are literals you build a tuple and set them on the function, but if they are not literals you save everything in a struct and use a callback that builds a tuple from the elements of that struct, correct? Why can't you always just build a tuple, i.e., why do you need the callback to build the tuple?
-- vitja. _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
2012/2/20 mark florisson <markflorisson88@gmail.com>:
On 19 February 2012 10:16, Vitja Makarov <vitja.makarov@gmail.com> wrote:
2012/2/15 mark florisson <markflorisson88@gmail.com>:
On 15 February 2012 15:45, mark florisson <markflorisson88@gmail.com> wrote:
On 14 February 2012 21:33, Robert Bradshaw <robertwb@math.washington.edu> wrote:
On Tue, Feb 14, 2012 at 1:09 PM, mark florisson <markflorisson88@gmail.com> wrote:
On 14 February 2012 17:19, Robert Bradshaw <robertwb@math.washington.edu> wrote: > On Tue, Feb 14, 2012 at 7:49 AM, mark florisson > <markflorisson88@gmail.com> wrote: >> On 14 February 2012 07:07, Robert Bradshaw <robertwb@math.washington.edu> wrote: >>> On Sun, Feb 12, 2012 at 12:53 PM, Vitja Makarov <vitja.makarov@gmail.com> wrote: >>>> 2012/2/12 Vitja Makarov <vitja.makarov@gmail.com>: >>>>> 2012/2/11 Robert Bradshaw <robertwb@math.washington.edu>: >>>>>> All of Sage passes except for one test: >>>>>> >>>>>> sage -t devel/sage/sage/misc/sageinspect.py >>>>>> ********************************************************************** >>>>>> File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", >>>>>> line 970: >>>>>> sage: sage_getargspec(bernstein_polynomial_factory_ratlist.coeffs_bitsize) >>>>>> Expected: >>>>>> ArgSpec(args=['self'], varargs=None, keywords=None, defaults=None) >>>>>> Got: >>>>>> ArgSpec(args=['self'], varargs=None, keywords=None, defaults=()) >>>>>> ********************************************************************** >>>>>> File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", >>>>>> line 973: >>>>>> sage: sage_getargspec(BooleanMonomialMonoid.gen) >>>>>> Expected: >>>>>> ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=(0,)) >>>>>> Got: >>>>>> ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=()) >>>>>> ********************************************************************** >>>>>> 1 items had failures: >>>>>> 2 of 31 in __main__.example_21 >>>>>> ***Test Failed*** 2 failures. >>>>>> >>>>>> Any ideas why this would have changed? >>>>>> >>>>> >>>>> CyFunction now provides its own code object. So inspect.getargs() is >>>>> called instead of >>>>> inspect.ArgSpec(*_sage_getargspec_cython(sage_getsource(obj))). It >>>>> seems like func.func_defaults should be implemented. >>>>> >>>>> >>>> >>>> I've created a pull request: >>>> >>>> https://github.com/cython/cython/pull/88 >>> >>> Thanks! The only other thing I can think of was a question of using >>> caching to mitigate the longer compile times, but I can't remember if >>> this was resolved. >> >> The compiler has like 2 or 3 seconds of constant overhead if you use >> memoryviews. > > That'd be nice to cut down, but certainly not a blocker. > >>> As I'm going to be MIA any day now, someone else should take up the >>> banner to push this long awaited release. >> >> "Missing in action"? Are you planning to desert? :) I can't find any >> relevant abbreviation, but I think I know what it means, >> congratulations in advance. > > Twin boys coming any day now!
And the Cython team just keeps on growing!
:)
>> Stefan, you have been involved the longest, would you feel up to the >> task? You probably have the best understanding and experience with any >> issues (no pressure :). Otherwise I could have a try... > > It's pretty easy. Once the defaults change is in it's probably worth > cutting a beta or release candidate to email to dev/users, and if > there's no blocking feedback you go ahead and push it out (basically > writing up the release notes on the wiki, cleaning up trac, tagging > the repository, making sure everything we care about on hudson is > still passing, uploading to pypi and the website (the sdist tarball), > emailing our lists and python-announce, re-building and updating the > pointer to the documentation, ...) If it goes on for a while it's > worth making/using a release branch on github.
Thanks for the summary, I'm sure I would have missed one or two :) Ok, I'll volunteer then. Maybe I can create a beta somewhere next week and then we can see the community tear it apart.
Thanks!
- Robert _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Sorry, my previous email with attachment bounced. Here goes.
I'm getting a substantial amount of failing tests on MSVC, https://gist.github.com/1836766. I think most complex number tests are failing because they cast a struct of a certain type to itself like ((struct_A) my_struct_A), which MSVC doesn't allow.
Some tests seem to fail because they can't be imported: "compiling (c) and running numpy_parallel: ImportError: No module named numpy_parallel".
And then there is a huge number of permission errors: WindowsError: [Error 5] Access is denied: 'c:\\Users\\mark\\cython\\BUILD\\compile\\cpp\\libc_math.pyd' . Maybe something is broken in the test runner (or in my setup somehow)?
The pasted output is a little munged because it was redirected to a log (and stdout is probably block buffering, something we could also fix to line buffering).
I've merged cydefaults branch and now sage-tests is blue.
So, if the defaults are literals you build a tuple and set them on the function, but if they are not literals you save everything in a struct and use a callback that builds a tuple from the elements of that struct, correct? Why can't you always just build a tuple, i.e., why do you need the callback to build the tuple?
So if defaults are literals const tuple is created once at constant initialization. Since CyFunction.defaults are already there (remember http://trac.cython.org/cython_trac/ticket/674) I've decided to avoid defaults tuple initialization at function create time. Instead I've introduced constructor (defaults_getter) it's run only once and caches result in CyFunction.defaults_tuple. ps: We should wait with release until pyregr tests issue is solved. -- vitja.
2012/2/20 Vitja Makarov <vitja.makarov@gmail.com>:
2012/2/20 mark florisson <markflorisson88@gmail.com>:
On 19 February 2012 10:16, Vitja Makarov <vitja.makarov@gmail.com> wrote:
2012/2/15 mark florisson <markflorisson88@gmail.com>:
On 15 February 2012 15:45, mark florisson <markflorisson88@gmail.com> wrote:
On 14 February 2012 21:33, Robert Bradshaw <robertwb@math.washington.edu> wrote:
On Tue, Feb 14, 2012 at 1:09 PM, mark florisson <markflorisson88@gmail.com> wrote: > On 14 February 2012 17:19, Robert Bradshaw <robertwb@math.washington.edu> wrote: >> On Tue, Feb 14, 2012 at 7:49 AM, mark florisson >> <markflorisson88@gmail.com> wrote: >>> On 14 February 2012 07:07, Robert Bradshaw <robertwb@math.washington.edu> wrote: >>>> On Sun, Feb 12, 2012 at 12:53 PM, Vitja Makarov <vitja.makarov@gmail.com> wrote: >>>>> 2012/2/12 Vitja Makarov <vitja.makarov@gmail.com>: >>>>>> 2012/2/11 Robert Bradshaw <robertwb@math.washington.edu>: >>>>>>> All of Sage passes except for one test: >>>>>>> >>>>>>> sage -t devel/sage/sage/misc/sageinspect.py >>>>>>> ********************************************************************** >>>>>>> File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", >>>>>>> line 970: >>>>>>> sage: sage_getargspec(bernstein_polynomial_factory_ratlist.coeffs_bitsize) >>>>>>> Expected: >>>>>>> ArgSpec(args=['self'], varargs=None, keywords=None, defaults=None) >>>>>>> Got: >>>>>>> ArgSpec(args=['self'], varargs=None, keywords=None, defaults=()) >>>>>>> ********************************************************************** >>>>>>> File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", >>>>>>> line 973: >>>>>>> sage: sage_getargspec(BooleanMonomialMonoid.gen) >>>>>>> Expected: >>>>>>> ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=(0,)) >>>>>>> Got: >>>>>>> ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=()) >>>>>>> ********************************************************************** >>>>>>> 1 items had failures: >>>>>>> 2 of 31 in __main__.example_21 >>>>>>> ***Test Failed*** 2 failures. >>>>>>> >>>>>>> Any ideas why this would have changed? >>>>>>> >>>>>> >>>>>> CyFunction now provides its own code object. So inspect.getargs() is >>>>>> called instead of >>>>>> inspect.ArgSpec(*_sage_getargspec_cython(sage_getsource(obj))). It >>>>>> seems like func.func_defaults should be implemented. >>>>>> >>>>>> >>>>> >>>>> I've created a pull request: >>>>> >>>>> https://github.com/cython/cython/pull/88 >>>> >>>> Thanks! The only other thing I can think of was a question of using >>>> caching to mitigate the longer compile times, but I can't remember if >>>> this was resolved. >>> >>> The compiler has like 2 or 3 seconds of constant overhead if you use >>> memoryviews. >> >> That'd be nice to cut down, but certainly not a blocker. >> >>>> As I'm going to be MIA any day now, someone else should take up the >>>> banner to push this long awaited release. >>> >>> "Missing in action"? Are you planning to desert? :) I can't find any >>> relevant abbreviation, but I think I know what it means, >>> congratulations in advance. >> >> Twin boys coming any day now! > > And the Cython team just keeps on growing!
:)
>>> Stefan, you have been involved the longest, would you feel up to the >>> task? You probably have the best understanding and experience with any >>> issues (no pressure :). Otherwise I could have a try... >> >> It's pretty easy. Once the defaults change is in it's probably worth >> cutting a beta or release candidate to email to dev/users, and if >> there's no blocking feedback you go ahead and push it out (basically >> writing up the release notes on the wiki, cleaning up trac, tagging >> the repository, making sure everything we care about on hudson is >> still passing, uploading to pypi and the website (the sdist tarball), >> emailing our lists and python-announce, re-building and updating the >> pointer to the documentation, ...) If it goes on for a while it's >> worth making/using a release branch on github. > > Thanks for the summary, I'm sure I would have missed one or two :) Ok, > I'll volunteer then. Maybe I can create a beta somewhere next week and > then we can see the community tear it apart.
Thanks!
- Robert _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Sorry, my previous email with attachment bounced. Here goes.
I'm getting a substantial amount of failing tests on MSVC, https://gist.github.com/1836766. I think most complex number tests are failing because they cast a struct of a certain type to itself like ((struct_A) my_struct_A), which MSVC doesn't allow.
Some tests seem to fail because they can't be imported: "compiling (c) and running numpy_parallel: ImportError: No module named numpy_parallel".
And then there is a huge number of permission errors: WindowsError: [Error 5] Access is denied: 'c:\\Users\\mark\\cython\\BUILD\\compile\\cpp\\libc_math.pyd' . Maybe something is broken in the test runner (or in my setup somehow)?
The pasted output is a little munged because it was redirected to a log (and stdout is probably block buffering, something we could also fix to line buffering).
I've merged cydefaults branch and now sage-tests is blue.
So, if the defaults are literals you build a tuple and set them on the function, but if they are not literals you save everything in a struct and use a callback that builds a tuple from the elements of that struct, correct? Why can't you always just build a tuple, i.e., why do you need the callback to build the tuple?
So if defaults are literals const tuple is created once at constant initialization. Since CyFunction.defaults are already there (remember http://trac.cython.org/cython_trac/ticket/674) I've decided to avoid defaults tuple initialization at function create time. Instead I've introduced constructor (defaults_getter) it's run only once and caches result in CyFunction.defaults_tuple.
ps: We should wait with release until pyregr tests issue is solved.
We can also fix this ticket before release http://trac.cython.org/cython_trac/ticket/761 -- vitja.
On 23 February 2012 08:30, Vitja Makarov <vitja.makarov@gmail.com> wrote:
2012/2/20 Vitja Makarov <vitja.makarov@gmail.com>:
2012/2/20 mark florisson <markflorisson88@gmail.com>:
On 19 February 2012 10:16, Vitja Makarov <vitja.makarov@gmail.com> wrote:
2012/2/15 mark florisson <markflorisson88@gmail.com>:
On 15 February 2012 15:45, mark florisson <markflorisson88@gmail.com> wrote:
On 14 February 2012 21:33, Robert Bradshaw <robertwb@math.washington.edu> wrote: > On Tue, Feb 14, 2012 at 1:09 PM, mark florisson > <markflorisson88@gmail.com> wrote: >> On 14 February 2012 17:19, Robert Bradshaw <robertwb@math.washington.edu> wrote: >>> On Tue, Feb 14, 2012 at 7:49 AM, mark florisson >>> <markflorisson88@gmail.com> wrote: >>>> On 14 February 2012 07:07, Robert Bradshaw <robertwb@math.washington.edu> wrote: >>>>> On Sun, Feb 12, 2012 at 12:53 PM, Vitja Makarov <vitja.makarov@gmail.com> wrote: >>>>>> 2012/2/12 Vitja Makarov <vitja.makarov@gmail.com>: >>>>>>> 2012/2/11 Robert Bradshaw <robertwb@math.washington.edu>: >>>>>>>> All of Sage passes except for one test: >>>>>>>> >>>>>>>> sage -t devel/sage/sage/misc/sageinspect.py >>>>>>>> ********************************************************************** >>>>>>>> File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", >>>>>>>> line 970: >>>>>>>> sage: sage_getargspec(bernstein_polynomial_factory_ratlist.coeffs_bitsize) >>>>>>>> Expected: >>>>>>>> ArgSpec(args=['self'], varargs=None, keywords=None, defaults=None) >>>>>>>> Got: >>>>>>>> ArgSpec(args=['self'], varargs=None, keywords=None, defaults=()) >>>>>>>> ********************************************************************** >>>>>>>> File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", >>>>>>>> line 973: >>>>>>>> sage: sage_getargspec(BooleanMonomialMonoid.gen) >>>>>>>> Expected: >>>>>>>> ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=(0,)) >>>>>>>> Got: >>>>>>>> ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=()) >>>>>>>> ********************************************************************** >>>>>>>> 1 items had failures: >>>>>>>> 2 of 31 in __main__.example_21 >>>>>>>> ***Test Failed*** 2 failures. >>>>>>>> >>>>>>>> Any ideas why this would have changed? >>>>>>>> >>>>>>> >>>>>>> CyFunction now provides its own code object. So inspect.getargs() is >>>>>>> called instead of >>>>>>> inspect.ArgSpec(*_sage_getargspec_cython(sage_getsource(obj))). It >>>>>>> seems like func.func_defaults should be implemented. >>>>>>> >>>>>>> >>>>>> >>>>>> I've created a pull request: >>>>>> >>>>>> https://github.com/cython/cython/pull/88 >>>>> >>>>> Thanks! The only other thing I can think of was a question of using >>>>> caching to mitigate the longer compile times, but I can't remember if >>>>> this was resolved. >>>> >>>> The compiler has like 2 or 3 seconds of constant overhead if you use >>>> memoryviews. >>> >>> That'd be nice to cut down, but certainly not a blocker. >>> >>>>> As I'm going to be MIA any day now, someone else should take up the >>>>> banner to push this long awaited release. >>>> >>>> "Missing in action"? Are you planning to desert? :) I can't find any >>>> relevant abbreviation, but I think I know what it means, >>>> congratulations in advance. >>> >>> Twin boys coming any day now! >> >> And the Cython team just keeps on growing! > > :) > >>>> Stefan, you have been involved the longest, would you feel up to the >>>> task? You probably have the best understanding and experience with any >>>> issues (no pressure :). Otherwise I could have a try... >>> >>> It's pretty easy. Once the defaults change is in it's probably worth >>> cutting a beta or release candidate to email to dev/users, and if >>> there's no blocking feedback you go ahead and push it out (basically >>> writing up the release notes on the wiki, cleaning up trac, tagging >>> the repository, making sure everything we care about on hudson is >>> still passing, uploading to pypi and the website (the sdist tarball), >>> emailing our lists and python-announce, re-building and updating the >>> pointer to the documentation, ...) If it goes on for a while it's >>> worth making/using a release branch on github. >> >> Thanks for the summary, I'm sure I would have missed one or two :) Ok, >> I'll volunteer then. Maybe I can create a beta somewhere next week and >> then we can see the community tear it apart. > > Thanks! > > - Robert > _______________________________________________ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel
Sorry, my previous email with attachment bounced. Here goes.
I'm getting a substantial amount of failing tests on MSVC, https://gist.github.com/1836766. I think most complex number tests are failing because they cast a struct of a certain type to itself like ((struct_A) my_struct_A), which MSVC doesn't allow.
Some tests seem to fail because they can't be imported: "compiling (c) and running numpy_parallel: ImportError: No module named numpy_parallel".
And then there is a huge number of permission errors: WindowsError: [Error 5] Access is denied: 'c:\\Users\\mark\\cython\\BUILD\\compile\\cpp\\libc_math.pyd' . Maybe something is broken in the test runner (or in my setup somehow)?
The pasted output is a little munged because it was redirected to a log (and stdout is probably block buffering, something we could also fix to line buffering).
I've merged cydefaults branch and now sage-tests is blue.
So, if the defaults are literals you build a tuple and set them on the function, but if they are not literals you save everything in a struct and use a callback that builds a tuple from the elements of that struct, correct? Why can't you always just build a tuple, i.e., why do you need the callback to build the tuple?
So if defaults are literals const tuple is created once at constant initialization. Since CyFunction.defaults are already there (remember http://trac.cython.org/cython_trac/ticket/674) I've decided to avoid defaults tuple initialization at function create time. Instead I've introduced constructor (defaults_getter) it's run only once and caches result in CyFunction.defaults_tuple.
ps: We should wait with release until pyregr tests issue is solved.
We can also fix this ticket before release http://trac.cython.org/cython_trac/ticket/761
Good idea. I think the ticket should read 'sys.path' instead of PYTHONPATH, though.
-- vitja. _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
2012/2/23 mark florisson <markflorisson88@gmail.com>:
On 23 February 2012 08:30, Vitja Makarov <vitja.makarov@gmail.com> wrote:
2012/2/20 Vitja Makarov <vitja.makarov@gmail.com>:
2012/2/20 mark florisson <markflorisson88@gmail.com>:
On 19 February 2012 10:16, Vitja Makarov <vitja.makarov@gmail.com> wrote:
2012/2/15 mark florisson <markflorisson88@gmail.com>:
On 15 February 2012 15:45, mark florisson <markflorisson88@gmail.com> wrote: > On 14 February 2012 21:33, Robert Bradshaw <robertwb@math.washington.edu> wrote: >> On Tue, Feb 14, 2012 at 1:09 PM, mark florisson >> <markflorisson88@gmail.com> wrote: >>> On 14 February 2012 17:19, Robert Bradshaw <robertwb@math.washington.edu> wrote: >>>> On Tue, Feb 14, 2012 at 7:49 AM, mark florisson >>>> <markflorisson88@gmail.com> wrote: >>>>> On 14 February 2012 07:07, Robert Bradshaw <robertwb@math.washington.edu> wrote: >>>>>> On Sun, Feb 12, 2012 at 12:53 PM, Vitja Makarov <vitja.makarov@gmail.com> wrote: >>>>>>> 2012/2/12 Vitja Makarov <vitja.makarov@gmail.com>: >>>>>>>> 2012/2/11 Robert Bradshaw <robertwb@math.washington.edu>: >>>>>>>>> All of Sage passes except for one test: >>>>>>>>> >>>>>>>>> sage -t devel/sage/sage/misc/sageinspect.py >>>>>>>>> ********************************************************************** >>>>>>>>> File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", >>>>>>>>> line 970: >>>>>>>>> sage: sage_getargspec(bernstein_polynomial_factory_ratlist.coeffs_bitsize) >>>>>>>>> Expected: >>>>>>>>> ArgSpec(args=['self'], varargs=None, keywords=None, defaults=None) >>>>>>>>> Got: >>>>>>>>> ArgSpec(args=['self'], varargs=None, keywords=None, defaults=()) >>>>>>>>> ********************************************************************** >>>>>>>>> File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", >>>>>>>>> line 973: >>>>>>>>> sage: sage_getargspec(BooleanMonomialMonoid.gen) >>>>>>>>> Expected: >>>>>>>>> ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=(0,)) >>>>>>>>> Got: >>>>>>>>> ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=()) >>>>>>>>> ********************************************************************** >>>>>>>>> 1 items had failures: >>>>>>>>> 2 of 31 in __main__.example_21 >>>>>>>>> ***Test Failed*** 2 failures. >>>>>>>>> >>>>>>>>> Any ideas why this would have changed? >>>>>>>>> >>>>>>>> >>>>>>>> CyFunction now provides its own code object. So inspect.getargs() is >>>>>>>> called instead of >>>>>>>> inspect.ArgSpec(*_sage_getargspec_cython(sage_getsource(obj))). It >>>>>>>> seems like func.func_defaults should be implemented. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> I've created a pull request: >>>>>>> >>>>>>> https://github.com/cython/cython/pull/88 >>>>>> >>>>>> Thanks! The only other thing I can think of was a question of using >>>>>> caching to mitigate the longer compile times, but I can't remember if >>>>>> this was resolved. >>>>> >>>>> The compiler has like 2 or 3 seconds of constant overhead if you use >>>>> memoryviews. >>>> >>>> That'd be nice to cut down, but certainly not a blocker. >>>> >>>>>> As I'm going to be MIA any day now, someone else should take up the >>>>>> banner to push this long awaited release. >>>>> >>>>> "Missing in action"? Are you planning to desert? :) I can't find any >>>>> relevant abbreviation, but I think I know what it means, >>>>> congratulations in advance. >>>> >>>> Twin boys coming any day now! >>> >>> And the Cython team just keeps on growing! >> >> :) >> >>>>> Stefan, you have been involved the longest, would you feel up to the >>>>> task? You probably have the best understanding and experience with any >>>>> issues (no pressure :). Otherwise I could have a try... >>>> >>>> It's pretty easy. Once the defaults change is in it's probably worth >>>> cutting a beta or release candidate to email to dev/users, and if >>>> there's no blocking feedback you go ahead and push it out (basically >>>> writing up the release notes on the wiki, cleaning up trac, tagging >>>> the repository, making sure everything we care about on hudson is >>>> still passing, uploading to pypi and the website (the sdist tarball), >>>> emailing our lists and python-announce, re-building and updating the >>>> pointer to the documentation, ...) If it goes on for a while it's >>>> worth making/using a release branch on github. >>> >>> Thanks for the summary, I'm sure I would have missed one or two :) Ok, >>> I'll volunteer then. Maybe I can create a beta somewhere next week and >>> then we can see the community tear it apart. >> >> Thanks! >> >> - Robert >> _______________________________________________ >> cython-devel mailing list >> cython-devel@python.org >> http://mail.python.org/mailman/listinfo/cython-devel > > Sorry, my previous email with attachment bounced. Here goes. > > I'm getting a substantial amount of failing tests on MSVC, > https://gist.github.com/1836766. I think most complex number tests are > failing because they cast > a struct of a certain type to itself like ((struct_A) my_struct_A), > which MSVC doesn't allow. > > Some tests seem to fail because they can't be imported: "compiling (c) > and running numpy_parallel: ImportError: No module named > numpy_parallel". > > And then there is a huge number of permission errors: WindowsError: > [Error 5] Access is denied: > 'c:\\Users\\mark\\cython\\BUILD\\compile\\cpp\\libc_math.pyd' . Maybe > something is broken in the test runner (or in my setup somehow)?
The pasted output is a little munged because it was redirected to a log (and stdout is probably block buffering, something we could also fix to line buffering).
I've merged cydefaults branch and now sage-tests is blue.
So, if the defaults are literals you build a tuple and set them on the function, but if they are not literals you save everything in a struct and use a callback that builds a tuple from the elements of that struct, correct? Why can't you always just build a tuple, i.e., why do you need the callback to build the tuple?
So if defaults are literals const tuple is created once at constant initialization. Since CyFunction.defaults are already there (remember http://trac.cython.org/cython_trac/ticket/674) I've decided to avoid defaults tuple initialization at function create time. Instead I've introduced constructor (defaults_getter) it's run only once and caches result in CyFunction.defaults_tuple.
ps: We should wait with release until pyregr tests issue is solved.
We can also fix this ticket before release http://trac.cython.org/cython_trac/ticket/761
Good idea. I think the ticket should read 'sys.path' instead of PYTHONPATH, though.
Yeah, I think the fix is trivial we should prepend (or append?) sys.path to cython includes -- vitja.
2012/2/23 Vitja Makarov <vitja.makarov@gmail.com>:
2012/2/23 mark florisson <markflorisson88@gmail.com>:
On 23 February 2012 08:30, Vitja Makarov <vitja.makarov@gmail.com> wrote:
2012/2/20 Vitja Makarov <vitja.makarov@gmail.com>:
2012/2/20 mark florisson <markflorisson88@gmail.com>:
On 19 February 2012 10:16, Vitja Makarov <vitja.makarov@gmail.com> wrote:
2012/2/15 mark florisson <markflorisson88@gmail.com>: > On 15 February 2012 15:45, mark florisson <markflorisson88@gmail.com> wrote: >> On 14 February 2012 21:33, Robert Bradshaw <robertwb@math.washington.edu> wrote: >>> On Tue, Feb 14, 2012 at 1:09 PM, mark florisson >>> <markflorisson88@gmail.com> wrote: >>>> On 14 February 2012 17:19, Robert Bradshaw <robertwb@math.washington.edu> wrote: >>>>> On Tue, Feb 14, 2012 at 7:49 AM, mark florisson >>>>> <markflorisson88@gmail.com> wrote: >>>>>> On 14 February 2012 07:07, Robert Bradshaw <robertwb@math.washington.edu> wrote: >>>>>>> On Sun, Feb 12, 2012 at 12:53 PM, Vitja Makarov <vitja.makarov@gmail.com> wrote: >>>>>>>> 2012/2/12 Vitja Makarov <vitja.makarov@gmail.com>: >>>>>>>>> 2012/2/11 Robert Bradshaw <robertwb@math.washington.edu>: >>>>>>>>>> All of Sage passes except for one test: >>>>>>>>>> >>>>>>>>>> sage -t devel/sage/sage/misc/sageinspect.py >>>>>>>>>> ********************************************************************** >>>>>>>>>> File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", >>>>>>>>>> line 970: >>>>>>>>>> sage: sage_getargspec(bernstein_polynomial_factory_ratlist.coeffs_bitsize) >>>>>>>>>> Expected: >>>>>>>>>> ArgSpec(args=['self'], varargs=None, keywords=None, defaults=None) >>>>>>>>>> Got: >>>>>>>>>> ArgSpec(args=['self'], varargs=None, keywords=None, defaults=()) >>>>>>>>>> ********************************************************************** >>>>>>>>>> File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", >>>>>>>>>> line 973: >>>>>>>>>> sage: sage_getargspec(BooleanMonomialMonoid.gen) >>>>>>>>>> Expected: >>>>>>>>>> ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=(0,)) >>>>>>>>>> Got: >>>>>>>>>> ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=()) >>>>>>>>>> ********************************************************************** >>>>>>>>>> 1 items had failures: >>>>>>>>>> 2 of 31 in __main__.example_21 >>>>>>>>>> ***Test Failed*** 2 failures. >>>>>>>>>> >>>>>>>>>> Any ideas why this would have changed? >>>>>>>>>> >>>>>>>>> >>>>>>>>> CyFunction now provides its own code object. So inspect.getargs() is >>>>>>>>> called instead of >>>>>>>>> inspect.ArgSpec(*_sage_getargspec_cython(sage_getsource(obj))). It >>>>>>>>> seems like func.func_defaults should be implemented. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> I've created a pull request: >>>>>>>> >>>>>>>> https://github.com/cython/cython/pull/88 >>>>>>> >>>>>>> Thanks! The only other thing I can think of was a question of using >>>>>>> caching to mitigate the longer compile times, but I can't remember if >>>>>>> this was resolved. >>>>>> >>>>>> The compiler has like 2 or 3 seconds of constant overhead if you use >>>>>> memoryviews. >>>>> >>>>> That'd be nice to cut down, but certainly not a blocker. >>>>> >>>>>>> As I'm going to be MIA any day now, someone else should take up the >>>>>>> banner to push this long awaited release. >>>>>> >>>>>> "Missing in action"? Are you planning to desert? :) I can't find any >>>>>> relevant abbreviation, but I think I know what it means, >>>>>> congratulations in advance. >>>>> >>>>> Twin boys coming any day now! >>>> >>>> And the Cython team just keeps on growing! >>> >>> :) >>> >>>>>> Stefan, you have been involved the longest, would you feel up to the >>>>>> task? You probably have the best understanding and experience with any >>>>>> issues (no pressure :). Otherwise I could have a try... >>>>> >>>>> It's pretty easy. Once the defaults change is in it's probably worth >>>>> cutting a beta or release candidate to email to dev/users, and if >>>>> there's no blocking feedback you go ahead and push it out (basically >>>>> writing up the release notes on the wiki, cleaning up trac, tagging >>>>> the repository, making sure everything we care about on hudson is >>>>> still passing, uploading to pypi and the website (the sdist tarball), >>>>> emailing our lists and python-announce, re-building and updating the >>>>> pointer to the documentation, ...) If it goes on for a while it's >>>>> worth making/using a release branch on github. >>>> >>>> Thanks for the summary, I'm sure I would have missed one or two :) Ok, >>>> I'll volunteer then. Maybe I can create a beta somewhere next week and >>>> then we can see the community tear it apart. >>> >>> Thanks! >>> >>> - Robert >>> _______________________________________________ >>> cython-devel mailing list >>> cython-devel@python.org >>> http://mail.python.org/mailman/listinfo/cython-devel >> >> Sorry, my previous email with attachment bounced. Here goes. >> >> I'm getting a substantial amount of failing tests on MSVC, >> https://gist.github.com/1836766. I think most complex number tests are >> failing because they cast >> a struct of a certain type to itself like ((struct_A) my_struct_A), >> which MSVC doesn't allow. >> >> Some tests seem to fail because they can't be imported: "compiling (c) >> and running numpy_parallel: ImportError: No module named >> numpy_parallel". >> >> And then there is a huge number of permission errors: WindowsError: >> [Error 5] Access is denied: >> 'c:\\Users\\mark\\cython\\BUILD\\compile\\cpp\\libc_math.pyd' . Maybe >> something is broken in the test runner (or in my setup somehow)? > > The pasted output is a little munged because it was redirected to a > log (and stdout is probably block buffering, something we could also > fix to line buffering).
I've merged cydefaults branch and now sage-tests is blue.
So, if the defaults are literals you build a tuple and set them on the function, but if they are not literals you save everything in a struct and use a callback that builds a tuple from the elements of that struct, correct? Why can't you always just build a tuple, i.e., why do you need the callback to build the tuple?
So if defaults are literals const tuple is created once at constant initialization. Since CyFunction.defaults are already there (remember http://trac.cython.org/cython_trac/ticket/674) I've decided to avoid defaults tuple initialization at function create time. Instead I've introduced constructor (defaults_getter) it's run only once and caches result in CyFunction.defaults_tuple.
ps: We should wait with release until pyregr tests issue is solved.
We can also fix this ticket before release http://trac.cython.org/cython_trac/ticket/761
Good idea. I think the ticket should read 'sys.path' instead of PYTHONPATH, though.
Yeah, I think the fix is trivial we should prepend (or append?) sys.path to cython includes
Btw we have 3 more regressions for py3k, I think some of them are related to hash randomization. https://sage.math.washington.edu:8091/hudson/view/dev-vitek/job/cython-vitek... -- vitja.
On 23 February 2012 08:36, Vitja Makarov <vitja.makarov@gmail.com> wrote:
2012/2/23 mark florisson <markflorisson88@gmail.com>:
On 23 February 2012 08:30, Vitja Makarov <vitja.makarov@gmail.com> wrote:
2012/2/20 Vitja Makarov <vitja.makarov@gmail.com>:
2012/2/20 mark florisson <markflorisson88@gmail.com>:
On 19 February 2012 10:16, Vitja Makarov <vitja.makarov@gmail.com> wrote:
2012/2/15 mark florisson <markflorisson88@gmail.com>: > On 15 February 2012 15:45, mark florisson <markflorisson88@gmail.com> wrote: >> On 14 February 2012 21:33, Robert Bradshaw <robertwb@math.washington.edu> wrote: >>> On Tue, Feb 14, 2012 at 1:09 PM, mark florisson >>> <markflorisson88@gmail.com> wrote: >>>> On 14 February 2012 17:19, Robert Bradshaw <robertwb@math.washington.edu> wrote: >>>>> On Tue, Feb 14, 2012 at 7:49 AM, mark florisson >>>>> <markflorisson88@gmail.com> wrote: >>>>>> On 14 February 2012 07:07, Robert Bradshaw <robertwb@math.washington.edu> wrote: >>>>>>> On Sun, Feb 12, 2012 at 12:53 PM, Vitja Makarov <vitja.makarov@gmail.com> wrote: >>>>>>>> 2012/2/12 Vitja Makarov <vitja.makarov@gmail.com>: >>>>>>>>> 2012/2/11 Robert Bradshaw <robertwb@math.washington.edu>: >>>>>>>>>> All of Sage passes except for one test: >>>>>>>>>> >>>>>>>>>> sage -t devel/sage/sage/misc/sageinspect.py >>>>>>>>>> ********************************************************************** >>>>>>>>>> File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", >>>>>>>>>> line 970: >>>>>>>>>> sage: sage_getargspec(bernstein_polynomial_factory_ratlist.coeffs_bitsize) >>>>>>>>>> Expected: >>>>>>>>>> ArgSpec(args=['self'], varargs=None, keywords=None, defaults=None) >>>>>>>>>> Got: >>>>>>>>>> ArgSpec(args=['self'], varargs=None, keywords=None, defaults=()) >>>>>>>>>> ********************************************************************** >>>>>>>>>> File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", >>>>>>>>>> line 973: >>>>>>>>>> sage: sage_getargspec(BooleanMonomialMonoid.gen) >>>>>>>>>> Expected: >>>>>>>>>> ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=(0,)) >>>>>>>>>> Got: >>>>>>>>>> ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=()) >>>>>>>>>> ********************************************************************** >>>>>>>>>> 1 items had failures: >>>>>>>>>> 2 of 31 in __main__.example_21 >>>>>>>>>> ***Test Failed*** 2 failures. >>>>>>>>>> >>>>>>>>>> Any ideas why this would have changed? >>>>>>>>>> >>>>>>>>> >>>>>>>>> CyFunction now provides its own code object. So inspect.getargs() is >>>>>>>>> called instead of >>>>>>>>> inspect.ArgSpec(*_sage_getargspec_cython(sage_getsource(obj))). It >>>>>>>>> seems like func.func_defaults should be implemented. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> I've created a pull request: >>>>>>>> >>>>>>>> https://github.com/cython/cython/pull/88 >>>>>>> >>>>>>> Thanks! The only other thing I can think of was a question of using >>>>>>> caching to mitigate the longer compile times, but I can't remember if >>>>>>> this was resolved. >>>>>> >>>>>> The compiler has like 2 or 3 seconds of constant overhead if you use >>>>>> memoryviews. >>>>> >>>>> That'd be nice to cut down, but certainly not a blocker. >>>>> >>>>>>> As I'm going to be MIA any day now, someone else should take up the >>>>>>> banner to push this long awaited release. >>>>>> >>>>>> "Missing in action"? Are you planning to desert? :) I can't find any >>>>>> relevant abbreviation, but I think I know what it means, >>>>>> congratulations in advance. >>>>> >>>>> Twin boys coming any day now! >>>> >>>> And the Cython team just keeps on growing! >>> >>> :) >>> >>>>>> Stefan, you have been involved the longest, would you feel up to the >>>>>> task? You probably have the best understanding and experience with any >>>>>> issues (no pressure :). Otherwise I could have a try... >>>>> >>>>> It's pretty easy. Once the defaults change is in it's probably worth >>>>> cutting a beta or release candidate to email to dev/users, and if >>>>> there's no blocking feedback you go ahead and push it out (basically >>>>> writing up the release notes on the wiki, cleaning up trac, tagging >>>>> the repository, making sure everything we care about on hudson is >>>>> still passing, uploading to pypi and the website (the sdist tarball), >>>>> emailing our lists and python-announce, re-building and updating the >>>>> pointer to the documentation, ...) If it goes on for a while it's >>>>> worth making/using a release branch on github. >>>> >>>> Thanks for the summary, I'm sure I would have missed one or two :) Ok, >>>> I'll volunteer then. Maybe I can create a beta somewhere next week and >>>> then we can see the community tear it apart. >>> >>> Thanks! >>> >>> - Robert >>> _______________________________________________ >>> cython-devel mailing list >>> cython-devel@python.org >>> http://mail.python.org/mailman/listinfo/cython-devel >> >> Sorry, my previous email with attachment bounced. Here goes. >> >> I'm getting a substantial amount of failing tests on MSVC, >> https://gist.github.com/1836766. I think most complex number tests are >> failing because they cast >> a struct of a certain type to itself like ((struct_A) my_struct_A), >> which MSVC doesn't allow. >> >> Some tests seem to fail because they can't be imported: "compiling (c) >> and running numpy_parallel: ImportError: No module named >> numpy_parallel". >> >> And then there is a huge number of permission errors: WindowsError: >> [Error 5] Access is denied: >> 'c:\\Users\\mark\\cython\\BUILD\\compile\\cpp\\libc_math.pyd' . Maybe >> something is broken in the test runner (or in my setup somehow)? > > The pasted output is a little munged because it was redirected to a > log (and stdout is probably block buffering, something we could also > fix to line buffering).
I've merged cydefaults branch and now sage-tests is blue.
So, if the defaults are literals you build a tuple and set them on the function, but if they are not literals you save everything in a struct and use a callback that builds a tuple from the elements of that struct, correct? Why can't you always just build a tuple, i.e., why do you need the callback to build the tuple?
So if defaults are literals const tuple is created once at constant initialization. Since CyFunction.defaults are already there (remember http://trac.cython.org/cython_trac/ticket/674) I've decided to avoid defaults tuple initialization at function create time. Instead I've introduced constructor (defaults_getter) it's run only once and caches result in CyFunction.defaults_tuple.
ps: We should wait with release until pyregr tests issue is solved.
We can also fix this ticket before release http://trac.cython.org/cython_trac/ticket/761
Good idea. I think the ticket should read 'sys.path' instead of PYTHONPATH, though.
Yeah, I think the fix is trivial we should prepend (or append?) sys.path to cython includes
I think append, you'd want local things to override installed things along sys.path.
-- vitja. _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
2012/2/23 mark florisson <markflorisson88@gmail.com>:
On 23 February 2012 08:36, Vitja Makarov <vitja.makarov@gmail.com> wrote:
2012/2/23 mark florisson <markflorisson88@gmail.com>:
On 23 February 2012 08:30, Vitja Makarov <vitja.makarov@gmail.com> wrote:
2012/2/20 Vitja Makarov <vitja.makarov@gmail.com>:
2012/2/20 mark florisson <markflorisson88@gmail.com>:
On 19 February 2012 10:16, Vitja Makarov <vitja.makarov@gmail.com> wrote: > 2012/2/15 mark florisson <markflorisson88@gmail.com>: >> On 15 February 2012 15:45, mark florisson <markflorisson88@gmail.com> wrote: >>> On 14 February 2012 21:33, Robert Bradshaw <robertwb@math.washington.edu> wrote: >>>> On Tue, Feb 14, 2012 at 1:09 PM, mark florisson >>>> <markflorisson88@gmail.com> wrote: >>>>> On 14 February 2012 17:19, Robert Bradshaw <robertwb@math.washington.edu> wrote: >>>>>> On Tue, Feb 14, 2012 at 7:49 AM, mark florisson >>>>>> <markflorisson88@gmail.com> wrote: >>>>>>> On 14 February 2012 07:07, Robert Bradshaw <robertwb@math.washington.edu> wrote: >>>>>>>> On Sun, Feb 12, 2012 at 12:53 PM, Vitja Makarov <vitja.makarov@gmail.com> wrote: >>>>>>>>> 2012/2/12 Vitja Makarov <vitja.makarov@gmail.com>: >>>>>>>>>> 2012/2/11 Robert Bradshaw <robertwb@math.washington.edu>: >>>>>>>>>>> All of Sage passes except for one test: >>>>>>>>>>> >>>>>>>>>>> sage -t devel/sage/sage/misc/sageinspect.py >>>>>>>>>>> ********************************************************************** >>>>>>>>>>> File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", >>>>>>>>>>> line 970: >>>>>>>>>>> sage: sage_getargspec(bernstein_polynomial_factory_ratlist.coeffs_bitsize) >>>>>>>>>>> Expected: >>>>>>>>>>> ArgSpec(args=['self'], varargs=None, keywords=None, defaults=None) >>>>>>>>>>> Got: >>>>>>>>>>> ArgSpec(args=['self'], varargs=None, keywords=None, defaults=()) >>>>>>>>>>> ********************************************************************** >>>>>>>>>>> File "/levi/scratch/robertwb/hudson/sage-4.8/devel/sage-main/sage/misc/sageinspect.py", >>>>>>>>>>> line 973: >>>>>>>>>>> sage: sage_getargspec(BooleanMonomialMonoid.gen) >>>>>>>>>>> Expected: >>>>>>>>>>> ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=(0,)) >>>>>>>>>>> Got: >>>>>>>>>>> ArgSpec(args=['self', 'i'], varargs=None, keywords=None, defaults=()) >>>>>>>>>>> ********************************************************************** >>>>>>>>>>> 1 items had failures: >>>>>>>>>>> 2 of 31 in __main__.example_21 >>>>>>>>>>> ***Test Failed*** 2 failures. >>>>>>>>>>> >>>>>>>>>>> Any ideas why this would have changed? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> CyFunction now provides its own code object. So inspect.getargs() is >>>>>>>>>> called instead of >>>>>>>>>> inspect.ArgSpec(*_sage_getargspec_cython(sage_getsource(obj))). It >>>>>>>>>> seems like func.func_defaults should be implemented. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> I've created a pull request: >>>>>>>>> >>>>>>>>> https://github.com/cython/cython/pull/88 >>>>>>>> >>>>>>>> Thanks! The only other thing I can think of was a question of using >>>>>>>> caching to mitigate the longer compile times, but I can't remember if >>>>>>>> this was resolved. >>>>>>> >>>>>>> The compiler has like 2 or 3 seconds of constant overhead if you use >>>>>>> memoryviews. >>>>>> >>>>>> That'd be nice to cut down, but certainly not a blocker. >>>>>> >>>>>>>> As I'm going to be MIA any day now, someone else should take up the >>>>>>>> banner to push this long awaited release. >>>>>>> >>>>>>> "Missing in action"? Are you planning to desert? :) I can't find any >>>>>>> relevant abbreviation, but I think I know what it means, >>>>>>> congratulations in advance. >>>>>> >>>>>> Twin boys coming any day now! >>>>> >>>>> And the Cython team just keeps on growing! >>>> >>>> :) >>>> >>>>>>> Stefan, you have been involved the longest, would you feel up to the >>>>>>> task? You probably have the best understanding and experience with any >>>>>>> issues (no pressure :). Otherwise I could have a try... >>>>>> >>>>>> It's pretty easy. Once the defaults change is in it's probably worth >>>>>> cutting a beta or release candidate to email to dev/users, and if >>>>>> there's no blocking feedback you go ahead and push it out (basically >>>>>> writing up the release notes on the wiki, cleaning up trac, tagging >>>>>> the repository, making sure everything we care about on hudson is >>>>>> still passing, uploading to pypi and the website (the sdist tarball), >>>>>> emailing our lists and python-announce, re-building and updating the >>>>>> pointer to the documentation, ...) If it goes on for a while it's >>>>>> worth making/using a release branch on github. >>>>> >>>>> Thanks for the summary, I'm sure I would have missed one or two :) Ok, >>>>> I'll volunteer then. Maybe I can create a beta somewhere next week and >>>>> then we can see the community tear it apart. >>>> >>>> Thanks! >>>> >>>> - Robert >>>> _______________________________________________ >>>> cython-devel mailing list >>>> cython-devel@python.org >>>> http://mail.python.org/mailman/listinfo/cython-devel >>> >>> Sorry, my previous email with attachment bounced. Here goes. >>> >>> I'm getting a substantial amount of failing tests on MSVC, >>> https://gist.github.com/1836766. I think most complex number tests are >>> failing because they cast >>> a struct of a certain type to itself like ((struct_A) my_struct_A), >>> which MSVC doesn't allow. >>> >>> Some tests seem to fail because they can't be imported: "compiling (c) >>> and running numpy_parallel: ImportError: No module named >>> numpy_parallel". >>> >>> And then there is a huge number of permission errors: WindowsError: >>> [Error 5] Access is denied: >>> 'c:\\Users\\mark\\cython\\BUILD\\compile\\cpp\\libc_math.pyd' . Maybe >>> something is broken in the test runner (or in my setup somehow)? >> >> The pasted output is a little munged because it was redirected to a >> log (and stdout is probably block buffering, something we could also >> fix to line buffering). > > I've merged cydefaults branch and now sage-tests is blue.
So, if the defaults are literals you build a tuple and set them on the function, but if they are not literals you save everything in a struct and use a callback that builds a tuple from the elements of that struct, correct? Why can't you always just build a tuple, i.e., why do you need the callback to build the tuple?
So if defaults are literals const tuple is created once at constant initialization. Since CyFunction.defaults are already there (remember http://trac.cython.org/cython_trac/ticket/674) I've decided to avoid defaults tuple initialization at function create time. Instead I've introduced constructor (defaults_getter) it's run only once and caches result in CyFunction.defaults_tuple.
ps: We should wait with release until pyregr tests issue is solved.
We can also fix this ticket before release http://trac.cython.org/cython_trac/ticket/761
Good idea. I think the ticket should read 'sys.path' instead of PYTHONPATH, though.
Yeah, I think the fix is trivial we should prepend (or append?) sys.path to cython includes
I think append, you'd want local things to override installed things along sys.path.
Yeah, right. -- vitja.
mark florisson, 23.02.2012 09:38:
On 23 February 2012 08:36, Vitja Makarov wrote:
2012/2/23 mark florisson:
On 23 February 2012 08:30, Vitja Makarov wrote:
We can also fix this ticket before release http://trac.cython.org/cython_trac/ticket/761
Good idea. I think the ticket should read 'sys.path' instead of PYTHONPATH, though.
Yeah, I think the fix is trivial we should prepend (or append?) sys.path to cython includes
I think append, you'd want local things to override installed things along sys.path.
I think it's 1) user provided directories 2) Cython provided directories 3) sys.path or would you swap 2) and 3) ? Stefan
On 23 February 2012 15:43, Stefan Behnel <stefan_ml@behnel.de> wrote:
mark florisson, 23.02.2012 09:38:
On 23 February 2012 08:36, Vitja Makarov wrote:
2012/2/23 mark florisson:
On 23 February 2012 08:30, Vitja Makarov wrote:
We can also fix this ticket before release http://trac.cython.org/cython_trac/ticket/761
Good idea. I think the ticket should read 'sys.path' instead of PYTHONPATH, though.
Yeah, I think the fix is trivial we should prepend (or append?) sys.path to cython includes
I think append, you'd want local things to override installed things along sys.path.
I think it's
1) user provided directories
2) Cython provided directories
3) sys.path
I think this is the most sensible order, yes. And the current directory would also come before anything else, as always.
or would you swap 2) and 3) ?
Stefan _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Hi, could you please also look at incorporating the following patch before releasing 0.16? (if it has not already been merged) https://github.com/cython/cython/pull/67 It has been more or less validated, but a test case is needed. This patch makes using C++ templates much more convenient with Cython. Currently I have to use hacks like the following which looks ugly and make the code less readable: ctypedef TCacheVarData[float] TCacheVarData_float "TCacheVarData<float>" Also thank you for all the work done on Cython, I have been using it (and Pyrex before) intensively for more than 6 years now, and it makes integrating Python and C/C++ really convenient. Thanks in advance Sébastien
2012/2/24 Sébastien Sablé Sablé <sable@users.sourceforge.net>:
Hi,
could you please also look at incorporating the following patch before releasing 0.16? (if it has not already been merged)
https://github.com/cython/cython/pull/67
It has been more or less validated, but a test case is needed.
This patch makes using C++ templates much more convenient with Cython.
Currently I have to use hacks like the following which looks ugly and make the code less readable: ctypedef TCacheVarData[float] TCacheVarData_float "TCacheVarData<float>"
Also thank you for all the work done on Cython, I have been using it (and Pyrex before) intensively for more than 6 years now, and it makes integrating Python and C/C++ really convenient.
Thanks in advance
Sébastien
_______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Ok I merged it and added a test. I also fixed a lot of tests to run under MSVC on windows. I'm thinking to merge https://github.com/cython/cython/pull/77, see if everything still passes on Jenkins, and then pushing out a beta release for 0.16. I created some release notes, please feel free to add to the page (especially to the feature and improvements lists), they might be incomplete: http://wiki.cython.org/ReleaseNotes-0.16 Are there any other last-minute bug fixes pending?
Great, thanks! 2012/2/25 mark florisson <markflorisson88@gmail.com>
2012/2/24 Sébastien Sablé Sablé <sable@users.sourceforge.net>:
Hi,
could you please also look at incorporating the following patch before releasing 0.16? (if it has not already been merged)
https://github.com/cython/cython/pull/67
It has been more or less validated, but a test case is needed.
This patch makes using C++ templates much more convenient with Cython.
Currently I have to use hacks like the following which looks ugly and make the code less readable: ctypedef TCacheVarData[float] TCacheVarData_float "TCacheVarData<float>"
Also thank you for all the work done on Cython, I have been using it (and Pyrex before) intensively for more than 6 years now, and it makes integrating Python and C/C++ really convenient.
Thanks in advance
Sébastien
_______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Ok I merged it and added a test. I also fixed a lot of tests to run under MSVC on windows. I'm thinking to merge https://github.com/cython/cython/pull/77, see if everything still passes on Jenkins, and then pushing out a beta release for 0.16. I created some release notes, please feel free to add to the page (especially to the feature and improvements lists), they might be incomplete: http://wiki.cython.org/ReleaseNotes-0.16
Are there any other last-minute bug fixes pending? _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
2012/2/27 Sébastien Sablé Sablé <sable@users.sourceforge.net>:
Great, thanks!
2012/2/25 mark florisson <markflorisson88@gmail.com>
2012/2/24 Sébastien Sablé Sablé <sable@users.sourceforge.net>:
Hi,
could you please also look at incorporating the following patch before releasing 0.16? (if it has not already been merged)
https://github.com/cython/cython/pull/67
It has been more or less validated, but a test case is needed.
This patch makes using C++ templates much more convenient with Cython.
Currently I have to use hacks like the following which looks ugly and make the code less readable: ctypedef TCacheVarData[float] TCacheVarData_float "TCacheVarData<float>"
Also thank you for all the work done on Cython, I have been using it (and Pyrex before) intensively for more than 6 years now, and it makes integrating Python and C/C++ really convenient.
Thanks in advance
Sébastien
_______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Ok I merged it and added a test. I also fixed a lot of tests to run under MSVC on windows. I'm thinking to merge https://github.com/cython/cython/pull/77, see if everything still passes on Jenkins, and then pushing out a beta release for 0.16. I created some release notes, please feel free to add to the page (especially to the feature and improvements lists), they might be incomplete: http://wiki.cython.org/ReleaseNotes-0.16
Are there any other last-minute bug fixes pending?
Recently I've found this bug on the tracker: http://trac.cython.org/cython_trac/ticket/766 I think I can fix it before release or wait unitl 0.16.1 since itsn't a regression. -- vitja.
On 27 March 2012 11:57, Vitja Makarov <vitja.makarov@gmail.com> wrote:
2012/2/27 Sébastien Sablé Sablé <sable@users.sourceforge.net>:
Great, thanks!
2012/2/25 mark florisson <markflorisson88@gmail.com>
2012/2/24 Sébastien Sablé Sablé <sable@users.sourceforge.net>:
Hi,
could you please also look at incorporating the following patch before releasing 0.16? (if it has not already been merged)
https://github.com/cython/cython/pull/67
It has been more or less validated, but a test case is needed.
This patch makes using C++ templates much more convenient with Cython.
Currently I have to use hacks like the following which looks ugly and make the code less readable: ctypedef TCacheVarData[float] TCacheVarData_float "TCacheVarData<float>"
Also thank you for all the work done on Cython, I have been using it (and Pyrex before) intensively for more than 6 years now, and it makes integrating Python and C/C++ really convenient.
Thanks in advance
Sébastien
_______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Ok I merged it and added a test. I also fixed a lot of tests to run under MSVC on windows. I'm thinking to merge https://github.com/cython/cython/pull/77, see if everything still passes on Jenkins, and then pushing out a beta release for 0.16. I created some release notes, please feel free to add to the page (especially to the feature and improvements lists), they might be incomplete: http://wiki.cython.org/ReleaseNotes-0.16
Are there any other last-minute bug fixes pending?
Recently I've found this bug on the tracker:
http://trac.cython.org/cython_trac/ticket/766
I think I can fix it before release or wait unitl 0.16.1 since itsn't a regression.
Sure, that's fine, I think there will be some time before the next beta. I tested the release in my own branch and jenkins was blue, but the release build seems to disagree. The py32 C++ build shows some refcount error: numpy_memoryview.cpp:16922: warning: ‘void __pyx_pw_5numpy_7ndarray_3__releasebuffer__(PyObject*, Py_buffer*)’ defined but not used python: Modules/gcmodule.c:327: visit_decref: Assertion `gc->gc.gc_refs != 0' failed. and some of the other python 3 tests are also failing.
-- vitja. _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
mark florisson, 27.03.2012 13:20:
I tested the release in my own branch and jenkins was blue, but the release build seems to disagree.
The release (and master) branch is tested against the "-ext" builds of CPython, which have some external packages installed, including NumPy. You have to change the config of your "tests" job to use those instead of the plain CPython builds. The build job can stay as it is. As for the inner workings, there's a normal "pyXY-hg" job to build CPython and a corresponding "pyXY-ext-hg" job that takes the build and installs a list of packages into it, then creates a new install archive. You can then reference either of the two archives in your build/test jobs by asking for a "pyXY" or "pyXY-ext" Python.
The py32 C++ build shows some refcount error:
numpy_memoryview.cpp:16922: warning: ‘void __pyx_pw_5numpy_7ndarray_3__releasebuffer__(PyObject*, Py_buffer*)’ defined but not used
These are legitimate warnings that are worth fixing (at some point), I think. They seem to originate from the buffer implementation in numpy.pxd. Those sort-of-external special methods shouldn't lead to the generation of a Python wrapper function.
python: Modules/gcmodule.c:327: visit_decref: Assertion `gc->gc.gc_refs != 0' failed.
It's surprising that that only occurs in one out of four Py3 test configurations. Maybe there's something indeterministic in those tests?
and some of the other python 3 tests are also failing.
Yep, some of them look really funny (complaining about getting exactly the expected output), others are the typical Py3 problems (e.g. printing bytes). Note that the reason the py3k tests are not impacted is that it does not have NumPy. So the tests would equally fail in all Py3 versions. Stefan
On 27 March 2012 12:58, Stefan Behnel <stefan_ml@behnel.de> wrote:
mark florisson, 27.03.2012 13:20:
I tested the release in my own branch and jenkins was blue, but the release build seems to disagree.
The release (and master) branch is tested against the "-ext" builds of CPython, which have some external packages installed, including NumPy. You have to change the config of your "tests" job to use those instead of the plain CPython builds. The build job can stay as it is.
As for the inner workings, there's a normal "pyXY-hg" job to build CPython and a corresponding "pyXY-ext-hg" job that takes the build and installs a list of packages into it, then creates a new install archive. You can then reference either of the two archives in your build/test jobs by asking for a "pyXY" or "pyXY-ext" Python.
The py32 C++ build shows some refcount error:
numpy_memoryview.cpp:16922: warning: ‘void __pyx_pw_5numpy_7ndarray_3__releasebuffer__(PyObject*, Py_buffer*)’ defined but not used
These are legitimate warnings that are worth fixing (at some point), I think. They seem to originate from the buffer implementation in numpy.pxd. Those sort-of-external special methods shouldn't lead to the generation of a Python wrapper function.
python: Modules/gcmodule.c:327: visit_decref: Assertion `gc->gc.gc_refs != 0' failed.
It's surprising that that only occurs in one out of four Py3 test configurations. Maybe there's something indeterministic in those tests?
and some of the other python 3 tests are also failing.
Yep, some of them look really funny (complaining about getting exactly the expected output), others are the typical Py3 problems (e.g. printing bytes).
Note that the reason the py3k tests are not impacted is that it does not have NumPy. So the tests would equally fail in all Py3 versions.
Stefan _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
The release build looks good now, I'm thinking of pushing a second and final beta out there tomorrow. If anyone wants to get something in, now is the time to raise voice.
On Fri, Mar 30, 2012 at 10:24 AM, mark florisson <markflorisson88@gmail.com> wrote:
The release build looks good now, I'm thinking of pushing a second and final beta out there tomorrow. If anyone wants to get something in, now is the time to raise voice.
Excellent. I personally don't know of anything that can't wait 'till 0.16.1. If you're confident enough, let's call it a release candidate :). - Robert
2012/3/30 Robert Bradshaw <robertwb@gmail.com>:
On Fri, Mar 30, 2012 at 10:24 AM, mark florisson <markflorisson88@gmail.com> wrote:
The release build looks good now, I'm thinking of pushing a second and final beta out there tomorrow. If anyone wants to get something in, now is the time to raise voice.
Excellent. I personally don't know of anything that can't wait 'till 0.16.1. If you're confident enough, let's call it a release candidate :).
I hope we're done with regressions now. I'm +1 for RC and feature freeze. -- vitja.
mark florisson, 30.03.2012 19:24:
The release build looks good now, I'm thinking of pushing a second and final beta out there tomorrow. If anyone wants to get something in, now is the time to raise voice.
Note that Dag's NumPy specialisation broke the Sage build by introducing a compiler crash. https://sage.math.washington.edu:8091/hudson/view/cython-devel/job/sage-buil... The problem is that the new code is already triggered during type inference (i.e. before type analysis) and then crashes the compiler because it accesses types that are not known yet. Stefan
On 31 March 2012 10:14, Stefan Behnel <stefan_ml@behnel.de> wrote:
mark florisson, 30.03.2012 19:24:
The release build looks good now, I'm thinking of pushing a second and final beta out there tomorrow. If anyone wants to get something in, now is the time to raise voice.
Note that Dag's NumPy specialisation broke the Sage build by introducing a compiler crash.
https://sage.math.washington.edu:8091/hudson/view/cython-devel/job/sage-buil...
The problem is that the new code is already triggered during type inference (i.e. before type analysis) and then crashes the compiler because it accesses types that are not known yet.
Stefan _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Thanks for pointing that out Stefan. It would probably work if it passed in 'obj_type' to the numpy_transform_attribute_node, and used that instead of node.type. Alternatively, it could just wait until the type is set through analyse_expressions.
mark florisson, 31.03.2012 11:31:
On 31 March 2012 10:14, Stefan Behnel wrote:
mark florisson, 30.03.2012 19:24:
The release build looks good now, I'm thinking of pushing a second and final beta out there tomorrow. If anyone wants to get something in, now is the time to raise voice.
Note that Dag's NumPy specialisation broke the Sage build by introducing a compiler crash.
https://sage.math.washington.edu:8091/hudson/view/cython-devel/job/sage-buil...
The problem is that the new code is already triggered during type inference (i.e. before type analysis) and then crashes the compiler because it accesses types that are not known yet.
Thanks for pointing that out Stefan. It would probably work if it passed in 'obj_type' to the numpy_transform_attribute_node, and used that instead of node.type. Alternatively, it could just wait until the type is set through analyse_expressions.
Thanks for fixing them. The release branch seems to be in good shape for a final beta release now. On a related note, the current master looks more like a 0.17 to me than a 0.16.1 when I compare it to the current release branch. We could just wait for a couple of weeks to collect bugs in 0.16 from user reports (and features as they come in), and then push out a 0.17. I hope the pending PyPy changes will also be ready enough for a release by then, that would round up the feature list quite nicely. Stefan
On 31 March 2012 17:15, Stefan Behnel <stefan_ml@behnel.de> wrote:
mark florisson, 31.03.2012 11:31:
On 31 March 2012 10:14, Stefan Behnel wrote:
mark florisson, 30.03.2012 19:24:
The release build looks good now, I'm thinking of pushing a second and final beta out there tomorrow. If anyone wants to get something in, now is the time to raise voice.
Note that Dag's NumPy specialisation broke the Sage build by introducing a compiler crash.
https://sage.math.washington.edu:8091/hudson/view/cython-devel/job/sage-buil...
The problem is that the new code is already triggered during type inference (i.e. before type analysis) and then crashes the compiler because it accesses types that are not known yet.
Thanks for pointing that out Stefan. It would probably work if it passed in 'obj_type' to the numpy_transform_attribute_node, and used that instead of node.type. Alternatively, it could just wait until the type is set through analyse_expressions.
Thanks for fixing them. The release branch seems to be in good shape for a final beta release now.
On a related note, the current master looks more like a 0.17 to me than a 0.16.1 when I compare it to the current release branch. We could just wait for a couple of weeks to collect bugs in 0.16 from user reports (and features as they come in), and then push out a 0.17. I hope the pending PyPy changes will also be ready enough for a release by then, that would round up the feature list quite nicely.
Indeed, I was getting ready for a release, but I almost forgot to merge over some fixes from the _fused_dispatch branch (to correctly specialize np.ndarray and C++ templates). So I'm doing that now, which also exposed a deepcopy python 2.4 bug. I'm planning an RC for tonight.
Stefan _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
participants (7)
-
Jason Grout -
mark florisson -
Robert Bradshaw -
Robert Bradshaw -
Stefan Behnel -
Sébastien Sablé Sablé -
Vitja Makarov