Hi Christian,
On Fri, Jan 24, 2014 at 3:40 AM, Christian Hudon wrote:
> First, I kicked the buildbots yesterday, and there are a *lot* of errors due
> to tests not being able to import the MAXREPEAT constant from the _sre
> module. But it seems to me that it is defined in
> pypy/module/_sre/__ini
On Thu, Jan 23, 2014, at 06:40 PM, Christian Hudon wrote:
> Hello,
>
> I'm working again on the stdlib-2.7.5 branch of Pypy. I have a couple
> questions, but since nobody seems to be around on irc right now, I'm
> asking them here. :-)
Cool. Did you see lib-python/stdlib-upgrade.txt?
>
> Firs
Hello,
I'm working again on the stdlib-2.7.5 branch of Pypy. I have a couple
questions, but since nobody seems to be around on irc right now, I'm
asking them here. :-)
First, I kicked the buildbots yesterday, and there are a *lot* of errors
due to tests not being able to import the MAXREPEAT
On 23 January 2014 20:54, Steven D'Aprano wrote:
> On Thu, Jan 23, 2014 at 01:27:50PM +, Oscar Benjamin wrote:
>
>> Steven wrote:
>> > With a UTF-8 implementation, won't that mean that string indexing
>> > operations are O(N) rather than O(1)? E.g. how do you know which UTF-8
>> > byte(s) to l
On Thu, Jan 23, 2014 at 10:45:25PM +0200, Elefterios Stamatogiannakis wrote:
> >But having said all this, I know that using UTF-8 internally for strings
> >is quite common (e.g. Haskell does it, without even an index cache, and
> >documents that indexing operations can be slow). CPython's FSR has
>
On 23/1/2014 10:54 μμ, Steven D'Aprano wrote:
On Thu, Jan 23, 2014 at 01:27:50PM +, Oscar Benjamin wrote:
Steven wrote:
With a UTF-8 implementation, won't that mean that string indexing
operations are O(N) rather than O(1)? E.g. how do you know which UTF-8
byte(s) to look at to get the cha
On Tue, Jan 21, 2014 at 11:01 PM, Johan Råde wrote:
> At the Leysin Sprint Armin outlined a new design of the PyPy 2 unicode
> class. He gave two versions of the design:
Why spend brain cycles on a Pypy unicode class, when you could just
move on to Pypy3? The majority of the Python community is
Hi Alex,
(I'm a little unclear what it means to represent "void*" as an array (array
of what?),
exactly. A PyCObject is useless by design (but lacking in PyPy AFAICT, other
than in cpyext, which use would be slow), as is an array of void. It is the
best equivalent I could come up with ...
I f
On Thu, Jan 23, 2014 at 01:27:50PM +, Oscar Benjamin wrote:
> Steven wrote:
> > With a UTF-8 implementation, won't that mean that string indexing
> > operations are O(N) rather than O(1)? E.g. how do you know which UTF-8
> > byte(s) to look at to get the character at index 42 without having to
>
> Some code is in, on the reflex-support branch (to be merged once it is
> documented): void* is represented as an array (I didn't see a PyCObject or
> PyCapsule outside of cpyext), both for returns and data members. There is
> a special case cppyy.gbl.nullptr (C++11 style), which is a unique obj
Hi Manuel,
On Tue, Jan 21, 2014 at 1:50 PM, Manuel Jacob wrote:
> So we have to solve this in
> a non-technical way. Everyone should feel responsible for tests that fail
> and check whether he broke that test by accident. If not, he should feel
> free to blame others on IRC or the mailing list.
Hi Oscar,
Thanks for explaining the caching in detail :-)
On Thu, Jan 23, 2014 at 2:27 PM, Oscar Benjamin
wrote:
> big saving. If the string comes from anything other than utf-8 the indexing
> cache can be built while decoding (and reencoding as utf-8 under the hood).
Actually, you need to walk
On 2014-01-22 08:01, Johan Råde wrote:
Next, would such a change break any existing Python 2 code on Windows?
Yes it will. For instance the following code for counting characters in
a string:
f = [0] * (1 << 16)
for c in s:
f[ord(c)] += 1
I would like to qualify this statement.
Get
On Wed, Jan 22, 2014 at 2:08 PM, Ron Reiter wrote:
> Something really strange is happening to me. I've stumbled upon a memory
> leak that happens only when answering a POST request using Twisted and Pypy.
>
> The problem is described here:
>
>
> http://stackoverflow.com/questions/21063842/using-t
On Thu, Jan 23, 2014 at 2:44 PM, Marko Tasic wrote:
> Hi Ron,
>
> Exactly same problem I have discovered yesterday in one of my production
> servers running PyPy 2.2.1, Flask==0.10.1, gunicorn==18.0 and tornado==3.2
> on ArchLinux updated on daily basis. I do not have more details on this,
> but
On Thu, Jan 23, 2014 at 4:17 PM, Donald Stufft wrote:
> Apologies as I’ve just recently sub’d to pypy-dev so I don’t know it’s
> normal
> speed and such.
>
> Is there enough here that a patch to do (a) would be a reasonable next step?
>
> On Jan 22, 2014, at 12:45 PM, Donald Stufft wrote:
>
Hi D
Hi Jean.
Sorry for not keeping everyone updated, we're working on this stuff,
hope to write something about pygame soon ;-)
On Wed, Jan 22, 2014 at 6:51 PM, Jean-François Caron wrote:
> Hi Devs, I just lurk on the mailing list so I know stuff is happening, but
> I've noticed that the PyPy Statu
Yeah, I think writing the patch for the backport (off by default... for
now) is a good next step. If you send a PR or create a branch I can review
it.
Alex
On Thu, Jan 23, 2014 at 9:17 AM, Donald Stufft wrote:
> Apologies as I’ve just recently sub’d to pypy-dev so I don’t know it’s
> normal
>
Apologies as I’ve just recently sub’d to pypy-dev so I don’t know it’s normal
speed and such.
Is there enough here that a patch to do (a) would be a reasonable next step?
On Jan 22, 2014, at 12:45 PM, Donald Stufft wrote:
>
> On Jan 22, 2014, at 12:40 PM, Alex Gaynor wrote:
>
>> (a) is a no
Hi Ron,
Exactly same problem I have discovered yesterday in one of my production
servers running PyPy 2.2.1, Flask==0.10.1, gunicorn==18.0 and tornado==3.2
on ArchLinux updated on daily basis. I do not have more details on this,
but I can say only that POST requests takes at least 10x slower then
On Wed, Jan 22, 2014 at 06:56:32PM +0100, Armin Rigo wrote:
> Hi Johan,
>
> On Wed, Jan 22, 2014 at 8:01 AM, Johan Råde wrote:
> > (I hope this makes more sense than my ramblings on IRC last night.)
>
> All versions you gave make sense as far as I'm concerned :-) But this
> last one is the clea
On Wed, Jan 22, 2014 at 08:01:31AM +0100, Johan Råde wrote:
> At the Leysin Sprint Armin outlined a new design of the PyPy 2 unicode
> class. He gave two versions of the design:
>
> A: unicode with a UTF-8 implementation and a UTF-32 interface.
>
> B: unicode with a UTF-8 implementation, a UT
22 matches
Mail list logo
