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