2012/2/23 mark florisson <[email protected]>: > On 23 February 2012 08:36, Vitja Makarov <[email protected]> wrote: >> 2012/2/23 mark florisson <[email protected]>: >>> On 23 February 2012 08:30, Vitja Makarov <[email protected]> wrote: >>>> 2012/2/20 Vitja Makarov <[email protected]>: >>>>> 2012/2/20 mark florisson <[email protected]>: >>>>>> On 19 February 2012 10:16, Vitja Makarov <[email protected]> wrote: >>>>>>> 2012/2/15 mark florisson <[email protected]>: >>>>>>>> On 15 February 2012 15:45, mark florisson <[email protected]> >>>>>>>> wrote: >>>>>>>>> On 14 February 2012 21:33, Robert Bradshaw >>>>>>>>> <[email protected]> wrote: >>>>>>>>>> On Tue, Feb 14, 2012 at 1:09 PM, mark florisson >>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>> On 14 February 2012 17:19, Robert Bradshaw >>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>> On Tue, Feb 14, 2012 at 7:49 AM, mark florisson >>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>> On 14 February 2012 07:07, Robert Bradshaw >>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>> On Sun, Feb 12, 2012 at 12:53 PM, Vitja Makarov >>>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>>> 2012/2/12 Vitja Makarov <[email protected]>: >>>>>>>>>>>>>>>> 2012/2/11 Robert Bradshaw <[email protected]>: >>>>>>>>>>>>>>>>> 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 >>>>>>>>>> [email protected] >>>>>>>>>> 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. _______________________________________________ cython-devel mailing list [email protected] http://mail.python.org/mailman/listinfo/cython-devel
