I don't know why I'm surprised.
Alex
On Tue, Jul 12, 2011 at 3:43 PM, Philip Jenvey wrote:
>
> On Jul 12, 2011, at 3:03 PM, Antonio Cuni wrote:
>
> > On 12/07/11 21:28, Alex Gaynor wrote:
> >> A, I found why i was getting nonsense information, `hg log -r
> >> -r` does NOT do what I wanted, y
On Jul 12, 2011, at 3:03 PM, Antonio Cuni wrote:
> On 12/07/11 21:28, Alex Gaynor wrote:
>> A, I found why i was getting nonsense information, `hg log -r
>> -r` does NOT do what I wanted, you need to do `hg log
>> -r..`!
>
> uhm, I usually do "hg log -rA:B". Is it the same as -rA..B or is a
I *think* they are the same, but I really have no idea.
Alex
On Tue, Jul 12, 2011 at 3:03 PM, Antonio Cuni wrote:
> On 12/07/11 21:28, Alex Gaynor wrote:
> > A, I found why i was getting nonsense information, `hg log -r
> > -r` does NOT do what I wanted, you need to do `hg log
> -r..`!
>
>
On 12/07/11 21:28, Alex Gaynor wrote:
> A, I found why i was getting nonsense information, `hg log -r
> -r` does NOT do what I wanted, you need to do `hg log -r..`!
uhm, I usually do "hg log -rA:B". Is it the same as -rA..B or is again subtly
different?
>
> r45176
> |
> r45174
> / \
> r45156 \
> | r45170
> r45155 /
> \ /
> r45154
>
On a completely unrelated topic, I'm always impressed how you can pull
the skill to make ascii art meaningful in an email conversation :)
_
A, I found why i was getting nonsense information, `hg log -r
-r` does NOT do what I wanted, you need to do `hg log
-r..`!
Alex
On Tue, Jul 12, 2011 at 12:10 PM, Alex Gaynor wrote:
>
>
> On Tue, Jul 12, 2011 at 12:06 PM, Armin Rigo wrote:
>
>> Hi Alex,
>>
>> On Tue, Jul 12, 2011 at 8:50 PM
On Tue, Jul 12, 2011 at 12:06 PM, Armin Rigo wrote:
> Hi Alex,
>
> On Tue, Jul 12, 2011 at 8:50 PM, Alex Gaynor
> wrote:
> > speed.pypy.org shows 27df (45168) as being fast, but 058e (45254) as
> being
> > slow, I narrowed it down to 45168:45205, ad there's only one reasonable
> > commit in that
Hi Alex,
On Tue, Jul 12, 2011 at 8:50 PM, Alex Gaynor wrote:
> speed.pypy.org shows 27df (45168) as being fast, but 058e (45254) as being
> slow, I narrowed it down to 45168:45205, ad there's only one reasonable
> commit in that range.
The trick is that the two revisions I identify as culprit ar
speed.pypy.org shows 27df (45168) as being fast, but 058e (45254) as being
slow, I narrowed it down to 45168:45205, ad there's only one reasonable
commit in that range. http://paste.pocoo.org/show/437119/ are my benchmark
runs (64-bit, local laptop), and the hg log which seems to correspond:
http:
Hi Alex,
On Tue, Jul 12, 2011 at 8:36 PM, Alex Gaynor wrote:
> I just investigated the spitfire regression, it appears to have been caused
> by 27df060341f0 (merg non-null-app-dict branch)
That's not the conclusion I arrived at. The speed.pypy.org website
says that revision 27df060341f0 was sti
I just investigated the spitfire regression, it appears to have been caused
by 27df060341f0 (merg non-null-app-dict branch)
Alex
On Tue, Jul 12, 2011 at 11:31 AM, Armin Rigo wrote:
> Hi,
>
> On Tue, Jul 12, 2011 at 1:20 AM, Maciej Fijalkowski
> wrote:
> >
> http://speed.pypy.org/timeline/?exe=
Hi,
On Tue, Jul 12, 2011 at 1:20 AM, Maciej Fijalkowski wrote:
> http://speed.pypy.org/timeline/?exe=1&base=none&ben=spitfire&env=tannit&revs=50
This was introduced by the changes we did to the GC to better support
resizing big lists: 1bb155fd266f and 324a8265e420. I will look.
A bientôt,
Ar
Hi Andrew,
On Tue, Jul 12, 2011 at 6:34 PM, Amaury Forgeot d'Arc
wrote:
>> Hello I am running into some snags developing an executable in pypy with
>> translate.py and wondering what the best method for me to do this with my
>> code would be.
In addition to the previous answer, there is also the
2011/7/12 Andrew Evans
> Hello I am running into some snags developing an executable in pypy with
> translate.py and wondering what the best method for me to do this with my
> code would be. I am developing an Exploit Framework and one of the features
> I would like to have is compiling an execut
On Tue, Jul 12, 2011 at 9:12 AM, Andrew Evans wrote:
> Hello I am running into some snags developing an executable in pypy with
> translate.py and wondering what the best method for me to do this with my
> code would be. I am developing an Exploit Framework and one of the features
> I would like t
Hello I am running into some snags developing an executable in pypy with
translate.py and wondering what the best method for me to do this with my
code would be. I am developing an Exploit Framework and one of the features
I would like to have is compiling an executable. I am wondering if this is
e
On Tue, Jul 12, 2011 at 10:53 +0200, Miquel Torres wrote:
> They *are* being merged. The question here is to have branches *now*,
> as we can't know how long it will take for speed.python.org to be
> online.
yes, makes sense. Better invest your time in getting branch benchmarking to
work right no
They *are* being merged. The question here is to have branches *now*,
as we can't know how long it will take for speed.python.org to be
online.
All things considered, I think the way to go would be to keep current
speed.pypy.org hosting if at all possible until PyPy moves to
speed.python.org. If t
On Tue, Jul 12, 2011 at 09:19 +0200, Maciej Fijalkowski wrote:
> On Tue, Jul 12, 2011 at 9:16 AM, Miquel Torres wrote:
> > Branches are already implemented. speed.pypy.org just needs to be
> > upgraded to Codespeed 0.8.x and its data migrated.
>
> I can help you with that, but that means having l
On 12/07/11 09:19, Maciej Fijalkowski wrote:
> On Tue, Jul 12, 2011 at 9:16 AM, Miquel Torres wrote:
>> Branches are already implemented. speed.pypy.org just needs to be
>> upgraded to Codespeed 0.8.x and its data migrated.
oh, this is very cool, thank you :-)
> I can help you with that, but tha
On Tue, Jul 12, 2011 at 9:16 AM, Miquel Torres wrote:
> Branches are already implemented. speed.pypy.org just needs to be
> upgraded to Codespeed 0.8.x and its data migrated.
I can help you with that, but that means having local changes from
speed.pypy.org commited somewhere else.
>
> That has n
Branches are already implemented. speed.pypy.org just needs to be
upgraded to Codespeed 0.8.x and its data migrated.
That has not yet been done because we wanted to move to ep.io, which
has not yet happend, and we are working on speed.python.org and
somehow things have stalled.
Migrating current
On 12/07/11 09:01, Maciej Fijalkowski wrote:
> I'll follow up on the branches, but the issue is a bit irrelevant - we
> still have performance regressions by trunk checkins as well.
it's not irrelevant. I won't solve the current issues, but it will help having
more in the future.
ciao,
Anto
_
On Tue, Jul 12, 2011 at 1:29 AM, Antonio Cuni wrote:
> On 12/07/11 01:20, Maciej Fijalkowski wrote:
>> Hi
>>
>> I'm a bit worried with our current benchmarks state. We have around 4
>> benchmarks that had reasonable slowdowns recently and we keep putting
>> new features that speed up other things.
24 matches
Mail list logo
