On Thu, Jul 21, 2011 at 9:09 AM, Antonio Cuni <anto.c...@gmail.com> 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 was another issue: currently we pass a revision number like
> 12345:aabbccddee, but codespeed complained that it's not a valid hg revision
> (it was checking that it's exactly 40 chars long). I think that fijal fixed
> it, not sure how.
by commenting out a check. Exact length is nonsense since we might
pass 5 digits one day....
>
>> Regarding the broken changes table, it is obviously a related problem,
>> together with not making the user having to browse through empty data.
>> All of those issues are caused by only benchmarking some of the
>> executables with one revision, and other with different revisions.
>> Each can be more or less solved with a couple of lines of code, but it
>> would introduce quite a bit of overhead, so we need to consider
>> (test/benchmark) the possible solution carefully.
>
> I think that codespeed should fix the behavior soon or later, the current one
> looks broken to me. However, I'm fine for having just a workaround at the
> moment.
>
>> Could you imagine implementing Antonio's suggestion?:
>> Citing:
>>> A quick workaround would be to force buildbot to update to a more specific
>>> revision. E.g., "the highest revision of today at 00:00", or something like
>>> this. This should ensure to have the same revision for all our
>>> benchmarks/tests.
>
> unfortunately, it's not as simple. In mercurial there is no easy way to update
> to a specific date/time ("hg up --date" does not consider branches, so you
> might end up in a different branch than default).
>
> Moreover, we want to be able to manually kick a benchmark run just for e.g. 32
> bit but not on 64, so the workaround would not work in this case.
>
> I propose a new workaround: instead of having pypy-c and pypy-c-64 both in the
> "tannit" environment, what about having tannit-32 and tannit-64? I think this
> would fix the issues, at the cost of not being able to have both 32 and 64 bit
> plots in the same graph.
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
>
> What do you think?
>
> ciao,
> Anto
>
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
