[Cython] 0.16 release

Thu Feb 23 09:40:07 CET 2012

2012/2/23 mark florisson <markflorisson88 at gmail.com>:
> On 23 February 2012 08:36, Vitja Makarov <vitja.makarov at gmail.com> wrote:
>> 2012/2/23 mark florisson <markflorisson88 at gmail.com>:
>>> On 23 February 2012 08:30, Vitja Makarov <vitja.makarov at gmail.com> wrote:
>>>> 2012/2/20 Vitja Makarov <vitja.makarov at gmail.com>:
>>>>> 2012/2/20 mark florisson <markflorisson88 at gmail.com>:
>>>>>> On 19 February 2012 10:16, Vitja Makarov <vitja.makarov at gmail.com> wrote:
>>>>>>> 2012/2/15 mark florisson <markflorisson88 at gmail.com>:
>>>>>>>> On 15 February 2012 15:45, mark florisson <markflorisson88 at gmail.com> wrote:
>>>>>>>>> On 14 February 2012 21:33, Robert Bradshaw <robertwb at math.washington.edu> wrote:
>>>>>>>>>> On Tue, Feb 14, 2012 at 1:09 PM, mark florisson
>>>>>>>>>> <markflorisson88 at gmail.com> wrote:
>>>>>>>>>>> On 14 February 2012 17:19, Robert Bradshaw <robertwb at math.washington.edu> wrote:
>>>>>>>>>>>> On Tue, Feb 14, 2012 at 7:49 AM, mark florisson
>>>>>>>>>>>> <markflorisson88 at gmail.com> wrote:
>>>>>>>>>>>>> On 14 February 2012 07:07, Robert Bradshaw <robertwb at math.washington.edu> wrote:
>>>>>>>>>>>>>> On Sun, Feb 12, 2012 at 12:53 PM, Vitja Makarov <vitja.makarov at gmail.com> wrote:
>>>>>>>>>>>>>>> 2012/2/12 Vitja Makarov <vitja.makarov at gmail.com>:
>>>>>>>>>>>>>>>> 2012/2/11 Robert Bradshaw <robertwb at 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 at 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.