Hi Antonio,
I didn't answer before because I was on holidays.
> I can see that the function finds the last_results to compare with simply by
> doing last_revs[1]. What about changing this logic to pick the latest rev
> which actually contains at least one result for the current environment?
Tha
Hi Miquel,
On 28/07/11 11:04, Miquel Torres wrote:
Hi Antonio,
I'm afraid you are right, the solution I proposed makes no sense.
Sorry I gave you a wrong answer. A revision is unique for a project
(well, now to a branch of a project), and thus they are not separated
by environment. Codespeed wa
Hi Antonio,
I'm afraid you are right, the solution I proposed makes no sense.
Sorry I gave you a wrong answer. A revision is unique for a project
(well, now to a branch of a project), and thus they are not separated
by environment. Codespeed was not really designed with revisions in
mind that some
Hi Miquel,
On 25/07/11 21:09, Miquel Torres wrote:
Btw., in any case you can start saving results in separated
environments. That will at least make changes work right away, and it
does make sense to have "tannit 32 bits" and "tannit 64 bits".
are you sure that having two separate environments
Very nice!
2011/7/26 Antonio Cuni :
> On 25/07/11 21:09, Miquel Torres wrote:
>>
>> Btw., in any case you can start saving results in separated
>> environments. That will at least make changes work right away, and it
>> does make sense to have "tannit 32 bits" and "tannit 64 bits".
>
> ok, I did
On 25/07/11 21:09, Miquel Torres wrote:
Btw., in any case you can start saving results in separated
environments. That will at least make changes work right away, and it
does make sense to have "tannit 32 bits" and "tannit 64 bits".
ok, I did it. If everything goes well, we should have two sep
Btw., in any case you can start saving results in separated
environments. That will at least make changes work right away, and it
does make sense to have "tannit 32 bits" and "tannit 64 bits".
Miquel
2011/7/21 Miquel Torres :
> Ok, not much time right now, but we will look into it.
>
>
>
> 2011/
Ok, not much time right now, but we will look into it.
2011/7/21 Maciej Fijalkowski :
> On Thu, Jul 21, 2011 at 1:52 PM, Antonio Cuni wrote:
>> On 21/07/11 10:02, Miquel Torres wrote:
>>> Alternatively, the timeline view could allow to display several
>>> environments at the same time...
>>
>>
On Thu, Jul 21, 2011 at 1:52 PM, Antonio Cuni wrote:
> On 21/07/11 10:02, Miquel Torres wrote:
>> Alternatively, the timeline view could allow to display several
>> environments at the same time...
>
> I think this would work. How hard is it to implement?
> Maciek, any opinion?
No, not much opini
On 21/07/11 10:02, Miquel Torres wrote:
> Alternatively, the timeline view could allow to display several
> environments at the same time...
I think this would work. How hard is it to implement?
Maciek, any opinion?
ciao,
Anto
___
pypy-dev mailing list
Alternatively, the timeline view could allow to display several
environments at the same time...
2011/7/21 Antonio Cuni :
> On 21/07/11 09:13, Maciej Fijalkowski wrote:
>> I think having them at the same graph is more important than having
>> changes showing correct things. I might give it a go i
On 21/07/11 09:13, Maciej Fijalkowski wrote:
> I think having them at the same graph is more important than having
> changes showing correct things. I might give it a go if nobody wants
> to
Not sure. Having them in the same graph is important only to quickly spot
cases in which one backend is muc
On Thu, Jul 21, 2011 at 9:09 AM, Antonio Cuni wrote:
> Hi Miquel, Maciek, all,
>
> On 20/07/11 22:01, Miquel Torres wrote:
>
>> Thanks Maciej. It was just a case of adding the new branch parameter
>> to the result dictionary, as you did in
>> pypy/benchmarks/src/saveresults
>
> I think that there
Hi Miquel, Maciek, all,
On 20/07/11 22:01, Miquel Torres wrote:
> Thanks Maciej. It was just a case of adding the new branch parameter
> to the result dictionary, as you did in
> pypy/benchmarks/src/saveresults
I think that there was another issue: currently we pass a revision number like
12345:
> I fixed it. Having a working "changes" tab would be cool, but not
> immediately needed
Thanks Maciej. It was just a case of adding the new branch parameter
to the result dictionary, as you did in
pypy/benchmarks/src/saveresults
I wanted to save you the time to look it up and change it but well,
On Wed, Jul 20, 2011 at 3:56 PM, Miquel Torres wrote:
> sorry, I have currently two busy days and couldn't look yet at it.
> Will do as soon as I can
I fixed it. Having a working "changes" tab would be cool, but not
immediately needed
>
>
> 2011/7/19 Antonio Cuni :
>> On 18/07/11 22:36, Miquel T
sorry, I have currently two busy days and couldn't look yet at it.
Will do as soon as I can
2011/7/19 Antonio Cuni :
> On 18/07/11 22:36, Miquel Torres wrote:
>> Ok, it is fixed now.
>>
>> AND branch support is in. Results saved with branch other than
>> "default" will be available in the compari
On 18/07/11 22:36, Miquel Torres wrote:
> Ok, it is fixed now.
>
> AND branch support is in. Results saved with branch other than
> "default" will be available in the comparison view. Got to talk to
> fijal yet to see how we should benchmark branches...
wow, all of this is very cool, thank you!
Ok, it is fixed now.
AND branch support is in. Results saved with branch other than
"default" will be available in the comparison view. Got to talk to
fijal yet to see how we should benchmark branches...
Ciao!
Miquel
2011/7/18 Antonio Cuni :
> On 18/07/11 21:37, Miquel Torres wrote:
>> Hi,
>>
>
On 18/07/11 21:37, Miquel Torres wrote:
> Hi,
>
> speed.pypy.org currently shows a very encouraging performance picture
> for PyPy: it is "infinite times faster than CPython". No, it is note
> yet April 1st.
hooray! We finally finished pypy :-)
> Codespeed creates the front page plots using the
20 matches
Mail list logo
