[Cython] overwriting pull requests and the related discussion
Hi, I'd like to suggest that instead of overwriting pull requests and all of their comments on github by pushing replaced commits over them, it would be better to keep any existing discussions accessible by rejecting the current pull request and creating a new one. Does that make sense for everyone? Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] overwriting pull requests and the related discussion
On 15 February 2012 09:37, Stefan Behnel wrote: > Hi, > > I'd like to suggest that instead of overwriting pull requests and all of > their comments on github by pushing replaced commits over them, it would be > better to keep any existing discussions accessible by rejecting the current > pull request and creating a new one. > > Does that make sense for everyone? > > Stefan > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel Hm, rebasing + force pushing is very common for pull requests, does that delete the inline (or all) comments? ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] overwriting pull requests and the related discussion
2012/2/15 mark florisson : > On 15 February 2012 09:37, Stefan Behnel wrote: >> Hi, >> >> I'd like to suggest that instead of overwriting pull requests and all of >> their comments on github by pushing replaced commits over them, it would be >> better to keep any existing discussions accessible by rejecting the current >> pull request and creating a new one. >> >> Does that make sense for everyone? >> >> Stefan >> ___ >> cython-devel mailing list >> cython-devel@python.org >> http://mail.python.org/mailman/listinfo/cython-devel > > Hm, rebasing + force pushing is very common for pull requests, does > that delete the inline (or all) comments? Yeah, vanished comments are really annoying on the other hand it's really hard to avoid rebases and forced pusing. Forced pushing (via git rebase -i HEAD~N) is rather useful to cleanup commits: fix typos, obvious bugs and so on. -- vitja. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
[Cython] Bringing Cython and PyPy closer together
Hi, following up on the thread on the PyPy mailing list where this topic was started, I've started a CEP in our Wiki in order to focus the different ideas and opinions. http://wiki.cython.org/enhancements/pypy The current state of the discussion seems to be that PyPy provides ways to talk to C code, but nothing as complete as CPython's C-API in the sense that it allows efficient two-way communication between C code and Python objects. Thus, we need to either improve this or look for alternatives. Please add to the CEP as you see fit. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] 0.16 release
On 14 February 2012 21:33, Robert Bradshaw wrote: > On Tue, Feb 14, 2012 at 1:09 PM, mark florisson > wrote: >> On 14 February 2012 17:19, Robert Bradshaw >> wrote: >>> On Tue, Feb 14, 2012 at 7:49 AM, mark florisson >>> wrote: On 14 February 2012 07:07, Robert Bradshaw wrote: > On Sun, Feb 12, 2012 at 12:53 PM, Vitja Makarov > wrote: >> 2012/2/12 Vitja Makarov : >>> 2012/2/11 Robert Bradshaw : 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)? ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] 0.16 release
On 15 February 2012 15:45, mark florisson wrote: > On 14 February 2012 21:33, Robert Bradshaw > wrote: >> On Tue, Feb 14, 2012 at 1:09 PM, mark florisson >> wrote: >>> On 14 February 2012 17:19, Robert Bradshaw >>> wrote: On Tue, Feb 14, 2012 at 7:49 AM, mark florisson wrote: > On 14 February 2012 07:07, Robert Bradshaw > wrote: >> On Sun, Feb 12, 2012 at 12:53 PM, Vitja Makarov >> wrote: >>> 2012/2/12 Vitja Makarov : 2012/2/11 Robert Bradshaw : > 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 out
