Hi Pim,
On 18 March 2016 at 13:25, Pim van der Eijk (Lists)
wrote:
> - For my test programs (the script in the issue on BitBucket is derived
> from one of them), PyPy is much slower.
If you're comparing the speed of scripts that have a large amount of
crossings of the cpyext layer (i.e. crossi
Hi Armin,
On 18-03-16 18:52, Armin Rigo wrote:
Hi Pim,
On 18 March 2016 at 15:08, Pim van der Eijk (Lists)
wrote:
- Memory use continues to grow up to over 80% at which time where my
laptop
starts swapping, whereas with CPython usage is never more than 4%.
This is more annoying. Can you
Did the lxml project indicate they will provide a new release soon that
incorporates these fixes?
I tried to build the latest development code from source, but run into
many issues (lxml build server down, source package missing the
pre-generated C code etc. etc.), and customer company pol
Hi,
On 17 March 2016 at 16:13, Pim van der Eijk (Lists)
wrote:
> There is a new lxml release as of today, unfortunately there is an issue:
> https://bitbucket.org/pypy/pypy/issues/2260/pypy-500-dumps-core-with-lxml-360
Yes, it's what we get when both sides (lxml and pypy) are half-hearted
about
On 18-03-16 14:57, Armin Rigo wrote:
- Memory use continues to grow up to over 80% at which time where my laptop
starts swapping, whereas with CPython usage is never more than 4%.
This is more annoying. Can you give us a way to reproduce this?
It already happens with the script I attached t
Hi,
I did some tests and there are no crashes.
However, compared to CPython 2.7.10 there are some serious issues:
- For my test programs (the script in the issue on BitBucket is derived
from one of them), PyPy is much slower.
script A: 256 seconds in PyPy versus 78 seconds in CPython
Hi again,
On 17 March 2016 at 17:27, Armin Rigo wrote:
> On 17 March 2016 at 16:13, Pim van der Eijk (Lists)
> wrote:
>> There is a new lxml release as of today, unfortunately there is an issue:
>> https://bitbucket.org/pypy/pypy/issues/2260/pypy-500-dumps-core-with-lxml-360
>
> Yes, it's what
Hi Pim,
On 16 March 2016 at 17:32, Pim van der Eijk (Lists)
wrote:
> Did the lxml project indicate they will provide a new release soon that
> incorporates these fixes?
You'll have to ask on the lxml mailing list.
Armin
___
pypy-dev mailing list
pypy-
There is a new lxml release as of today, unfortunately there is an issue:
https://bitbucket.org/pypy/pypy/issues/2260/pypy-500-dumps-core-with-lxml-360
On 16-03-16 18:07, Armin Rigo wrote:
Hi Pim,
On 16 March 2016 at 17:32, Pim van der Eijk (Lists)
wrote:
Did the lxml project indicate they
Hi Pim,
On 18 March 2016 at 15:08, Pim van der Eijk (Lists)
wrote:
>>> - Memory use continues to grow up to over 80% at which time where my
>>> laptop
>>> starts swapping, whereas with CPython usage is never more than 4%.
>>
>> This is more annoying. Can you give us a way to reproduce this?
>
ugh, btw, it seems someone broke embedding (as advertised, probably
the cffi embedding still works)
On Tue, Mar 8, 2016 at 4:53 PM, Maciej Fijalkowski wrote:
> in other words, it shows the last release of pypy, not "trunk"
>
> On Tue, Mar 8, 2016 at 4:52 PM, Maciej Fijalkowski wrote:
>> Cool, I'
in other words, it shows the last release of pypy, not "trunk"
On Tue, Mar 8, 2016 at 4:52 PM, Maciej Fijalkowski wrote:
> Cool, I'm happy to do the suggested fixes.
>
> We rerun it every release usually, changes by hand are done earlier.
> Should I start a run on the current release branch?
>
>
Cool, I'm happy to do the suggested fixes.
We rerun it every release usually, changes by hand are done earlier.
Should I start a run on the current release branch?
On Tue, Mar 8, 2016 at 4:46 PM, Armin Rigo wrote:
> Hi,
>
> On 8 March 2016 at 15:42, Maciej Fijalkowski wrote:
>> btw, should we m
Hi,
On 8 March 2016 at 15:42, Maciej Fijalkowski wrote:
> btw, should we mention packages.pypy.org?
I would do so but only under two conditions:
* it reports a post-cpyext-fixes result: which packages run or don't
run now, ideally on the current "release 5.0" branch, but at least
after the merg
I'm ok with making it official 5.0. We can always do 5.0.1 if there are problems
On Tue, Mar 8, 2016 at 4:15 PM, matti picus wrote:
> We could package it and upload as rc1, but version_info will not have rc1
> unless we rerun the builds. Confusing.
> I prefer to apologize if we get it wrong and
btw, should we mention packages.pypy.org?
On Tue, Mar 8, 2016 at 4:36 PM, Maciej Fijalkowski wrote:
> I'm ok with making it official 5.0. We can always do 5.0.1 if there are
> problems
>
> On Tue, Mar 8, 2016 at 4:15 PM, matti picus wrote:
>> We could package it and upload as rc1, but version_i
I am going to test it out , quite interesting release.
On Tue, Mar 8, 2016 at 8:12 PM Maciej Fijalkowski wrote:
> yay!
>
> can we call it rc1? if noone objects we'll make rc1 the release say in 24
> or 48h
>
> On Tue, Mar 8, 2016 at 1:49 PM, matti picus wrote:
> > It seems we have a release, v
Hi Matti,
On 8 March 2016 at 15:15, matti picus wrote:
> We could package it and upload as rc1, but version_info will not have rc1
> unless we rerun the builds. Confusing.
> I prefer to apologize if we get it wrong and release a 5.0.1 bugfix
+1. Go ahead as far as I'm concerned.
About the rel
We could package it and upload as rc1, but version_info will not have rc1
unless we rerun the builds. Confusing.
I prefer to apologize if we get it wrong and release a 5.0.1 bugfix
Matti
On Tuesday, 8 March 2016, Maciej Fijalkowski wrote:
> yay!
>
> can we call it rc1? if noone objects we'll ma
yay!
can we call it rc1? if noone objects we'll make rc1 the release say in 24 or 48h
On Tue, Mar 8, 2016 at 1:49 PM, matti picus wrote:
> It seems we have a release, version ad5a4e55fa8e. Is there a reason to wait?
> buildbots http://buildbot.pypy.org/summary?branch=release-5.x
> release notice
It seems we have a release, version ad5a4e55fa8e. Is there a reason to wait?
buildbots http://buildbot.pypy.org/summary?branch=release-5.x
release notice http://doc.pypy.org/en/latest/release-5.0.0.html
Hopefully we can release 5.1 once s360-x lands on default
Matti
___
21 matches
Mail list logo
