Mailman 3 October 2013 - pypy-dev

Cygwin pypy patches (cpyext module)
by Richard H Lee Oct. 15, 2013

Oct. 15, 2013

Hi Uwe, I came across your tux.org page on how to build pypy on cygwin. I was wondering if you made any patches against the cpyext module to get it to build on cygwin? Richard

2 1

Re: [pypy-dev] [pypy-commit] pypy fast_cffi_list_init: implement the fast-path for intstrategy and long[] only
by Carl Friedrich Bolz Oct. 10, 2013

Oct. 10, 2013

Hi Anto, just said it on IRC, just so that it doesn't get lost: I think module/_cffi_backend should use the generic interfaces and not touch the internals of listobject.py. it can just call space.listview_int and space.listview_float, they are a no-copy operation on int/float strategy lists. Cheers, Carl Friedrich On 09/10/13 18:24, antocuni wrote: > Author: Antonio Cuni <anto.cuni(a)gmail.com> > Branch: fast_cffi_list_init > Changeset: r67250:a8d55ebf78ea > Date: 2013-10-09 18:20 +0200 > http://bitbucket.org/pypy/pypy/changeset/a8d55ebf78ea/ > > Log: implement the fast-path for intstrategy and long[] only > > diff --git a/pypy/module/_cffi_backend/ctypeprim.py b/pypy/module/_cffi_backend/ctypeprim.py > --- a/pypy/module/_cffi_backend/ctypeprim.py > +++ b/pypy/module/_cffi_backend/ctypeprim.py > @@ -85,6 +85,11 @@ > return self.space.wrap(s) > return W_CType.string(self, cdataobj, maxlen) > > + def is_long(self): > + return False > + > + def is_double(self): > + return False > > class W_CTypePrimitiveCharOrUniChar(W_CTypePrimitive): > _attrs_ = [] > @@ -171,6 +176,9 @@ > self.vmin = r_uint(-1) << (sh - 1) > self.vrangemax = (r_uint(1) << sh) - 1 > > + def is_long(self): > + return self.size == rffi.sizeof(lltype.Signed) > + > def cast_to_int(self, cdata): > return self.convert_to_object(cdata) > > @@ -274,6 +282,9 @@ > class W_CTypePrimitiveFloat(W_CTypePrimitive): > _attrs_ = [] > > + def is_double(self): > + return self.size == rffi.sizeof(lltype.Float) > + > def cast(self, w_ob): > space = self.space > if isinstance(w_ob, cdataobj.W_CData): > diff --git a/pypy/module/_cffi_backend/ctypeptr.py b/pypy/module/_cffi_backend/ctypeptr.py > --- a/pypy/module/_cffi_backend/ctypeptr.py > +++ b/pypy/module/_cffi_backend/ctypeptr.py > @@ -58,19 +58,44 @@ > value = rffi.cast(rffi.CCHARP, value) > return cdataobj.W_CData(space, value, self) > > + def _convert_array_from_list_strategy_maybe(self, cdata, w_ob): > + from rpython.rlib.rarray import copy_list_to_raw_array > + from pypy.objspace.std.listobject import W_ListObject, IntegerListStrategy > + if not isinstance(w_ob, W_ListObject): > + return False > + # > + int_stragegy = self.space.fromcache(IntegerListStrategy) > + > + if w_ob.strategy is int_stragegy and self.ctitem.is_long(): > + int_list = w_ob.strategy.unerase(w_ob.lstorage) > + cdata = rffi.cast(rffi.LONGP, cdata) > + copy_list_to_raw_array(int_list, cdata) > + return True > + > + return False > + > + def _convert_array_from_listview(self, cdata, w_ob): > + space = self.space > + lst_w = space.listview(w_ob) > + if self.length >= 0 and len(lst_w) > self.length: > + raise operationerrfmt(space.w_IndexError, > + "too many initializers for '%s' (got %d)", > + self.name, len(lst_w)) > + ctitem = self.ctitem > + for i in range(len(lst_w)): > + ctitem.convert_from_object(cdata, lst_w[i]) > + cdata = rffi.ptradd(cdata, ctitem.size) > + > def convert_array_from_object(self, cdata, w_ob): > space = self.space > + if self._convert_array_from_list_strategy_maybe(cdata, w_ob): > + # the fast path worked, we are done now > + return > + # > + # continue with the slow path > if (space.isinstance_w(w_ob, space.w_list) or > space.isinstance_w(w_ob, space.w_tuple)): > - lst_w = space.listview(w_ob) > - if self.length >= 0 and len(lst_w) > self.length: > - raise operationerrfmt(space.w_IndexError, > - "too many initializers for '%s' (got %d)", > - self.name, len(lst_w)) > - ctitem = self.ctitem > - for i in range(len(lst_w)): > - ctitem.convert_from_object(cdata, lst_w[i]) > - cdata = rffi.ptradd(cdata, ctitem.size) > + self._convert_array_from_listview(cdata, w_ob) > elif (self.can_cast_anything or > (self.ctitem.is_primitive_integer and > self.ctitem.size == rffi.sizeof(lltype.Char))): > diff --git a/pypy/objspace/std/listobject.py b/pypy/objspace/std/listobject.py > --- a/pypy/objspace/std/listobject.py > +++ b/pypy/objspace/std/listobject.py > @@ -139,6 +139,8 @@ > > class W_ListObject(W_Root): > > + strategy = None > + > def __init__(self, space, wrappeditems, sizehint=-1): > assert isinstance(wrappeditems, list) > self.space = space > _______________________________________________ > pypy-commit mailing list > pypy-commit(a)python.org > https://mail.python.org/mailman/listinfo/pypy-commit >

2 1

Re: [pypy-dev] [pypy-commit] pypy default: be a little more stringent about checking negative numbers early
by Carl Friedrich Bolz Oct. 9, 2013

Oct. 9, 2013

Hi Maciej, can you please write some tests for this change? Cheers, Carl Friedrich On 09/10/13 09:57, fijal wrote: > Author: Maciej Fijalkowski <fijall(a)gmail.com> > Branch: > Changeset: r67229:c214edb11c30 > Date: 2013-10-09 09:55 +0200 > http://bitbucket.org/pypy/pypy/changeset/c214edb11c30/ > > Log: be a little more stringent about checking negative numbers early > > diff --git a/rpython/annotator/unaryop.py b/rpython/annotator/unaryop.py > --- a/rpython/annotator/unaryop.py > +++ b/rpython/annotator/unaryop.py > @@ -333,12 +333,13 @@ > check_negative_slice(s_start, s_stop) > lst.listdef.resize() > > -def check_negative_slice(s_start, s_stop): > +def check_negative_slice(s_start, s_stop, error="slicing"): > if isinstance(s_start, SomeInteger) and not s_start.nonneg: > - raise AnnotatorError("slicing: not proven to have non-negative start") > + raise AnnotatorError("%s: not proven to have non-negative start" % > + error) > if isinstance(s_stop, SomeInteger) and not s_stop.nonneg and \ > getattr(s_stop, 'const', 0) != -1: > - raise AnnotatorError("slicing: not proven to have non-negative stop") > + raise AnnotatorError("%s: not proven to have non-negative stop" % error) > > > class __extend__(SomeDict): > @@ -448,12 +449,15 @@ > return s_Bool > > def method_find(str, frag, start=None, end=None): > + check_negative_slice(start, end, "find") > return SomeInteger() > > def method_rfind(str, frag, start=None, end=None): > + check_negative_slice(start, end, "rfind") > return SomeInteger() > > def method_count(str, frag, start=None, end=None): > + check_negative_slice(start, end, "count") > return SomeInteger(nonneg=True) > > def method_strip(str, chr): > _______________________________________________ > pypy-commit mailing list > pypy-commit(a)python.org > https://mail.python.org/mailman/listinfo/pypy-commit >

1 0

MIPS port
by Drasko DRASKOVIC Oct. 7, 2013

Oct. 7, 2013

Hi all, what is the state of the MIPS port? Does it exist and is it usable? On the website I can only see ARM ports. Best regards, Drasko

2 1

stdlib-2.7.5 branch
by Christian Hudon Oct. 6, 2013

Oct. 6, 2013

Hello, I created a pull request for a fix for a failing json test in the stdlib-2.7.5 branch. This is my first pull request outside of a PyCon sprint. When at a sprint, I either put the name of the PyPy developer that had coached me in the reviewer field of the pull request, or asked them for a suggestion for a reviewer. So for that first patch outside of a PyPy sprint, I'm not quite sure what the right procedure is... What should I do in the future to get code reviews for my pull requests. Should I "just wait and someone will get to it (eventually)", or would it be better to ping people a bit more explicitly? Here is the pull request: https://bitbucket.org/pypy/pypy/pull-request/192/fix-for-failing-json-test/… Also, any reason why buildbot isn't running automatically on the stdlib-2.7.5 branch? The last run was on August 31st. This is the branch which, once all tests pass, will be merged back into the trunk and then the next release of PyPy will be announced as supporting CPython 2.7.5, right? (Just making sure...) Assuming that's true, I'll work slowly on making all the tests pass, assuming nobody beats me to it. Thanks, Christian

4 3

Possible Numpy benchmark?
by Carl Friedrich Bolz Oct. 1, 2013

Oct. 1, 2013

Hi all, Maybe we can use this thing as a Numpy benchmark? http://radimrehurek.com/2013/09/deep-learning-with-word2vec-and-gensim/ Cheers, Carl Friedrich

2 1