Re: [pypy-dev] New version of Codespeed (0.7) for speed.pypy.org
Hi Miquel! I would gladly hear other ideas. Here are my two cents! On Fri, Jan 21, 2011 at 08:49, Miquel Torres tob...@googlemail.com wrote: So one idea would be: - Every revision has a branch associated to it (a problem though is that subversion has the same revision number for all branches, while mercurial and git not) This suggests (to me) that a revision would be associated to a specific branch, but then I don't get expressions like all the branches for a revision. Maybe you mean that you would replace revisions with pairs (Revision, Branch)? [...] - There are problems with this approach. In the Changes view, when you select a revision that doesn't have results for the currently selected branch, nothing would be displayed. You're referring to an SVN context, right? Otherwise I can't make sense of it. I guess you can use, on other branches, the closest revision available, after defining a linear order on revisions across branches. You have that order in SVN; since you don't have that in Git, why don't you just use the _date_ of a revision as the ordering key? [For the data structures to implement this, I've seen even seen interfaces to tree-based dictionaries allowing navigating to the key-predecessor and key-successor, which might be especially handy here (such as NavigableMap in Java, dunno about Python).] Of course, that's suitable just as default, so you need to be able to navigate between revisions independently for each branch. Please note that with complex merge histories, using the date does not necessarily make sense - so that at least Git tools provide many linearization algorithms. The problem is that a commit might be made on a certain date in some repository, but be merged on mainline much later, especially when many developers are not committers themselves; one solution is to consider only revisions which were committed directly on the branch or merged shortly after. I also would believe this use case does not appear for PyPy. See help about git log --topo-order and --date-order (such docs used to be more complete, though). You would need to blindly search for your results. An option is to always display all branches for a revision, but sometimes a revision will contain results for a branch, sometimes for others. Outside of the SVN context, I'm not sure I get what you mean here, because revisions in different branches are not necessarily comparable. -- Paolo Giarrusso - Ph.D. Student http://www.informatik.uni-marburg.de/~pgiarrusso/ ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
[pypy-dev] rPython
Hi, It is possible through the PyPy toolchain check if a program is a rPython program? I know the tool Pylint (RPylint) gives an idea, but it seems to me that this tool gives some errors that result from being a little outdated. Thanks, Eva Maia. ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] rPython
On Fri, Jan 21, 2011 at 5:03 PM, Eva Maia eva_m...@sapo.pt wrote: Hi, It is possible through the PyPy toolchain check if a program is a rPython program? I know the tool Pylint (RPylint) gives an idea, but it seems to me that this tool gives some errors that result from being a little outdated. Thanks, Eva Maia. ___ Hi. This tool is completely broken. Primary reason is that this tool operates on the level of source code, while RPython operates on live python objects and that's a huge difference. That said, I don't think there is any other way of finding what's RPython without compiling it. In fact, RPython is defined as a thing that can be accepted by our translation toolchain :-) PS. Why you want to write RPython in the first place? Cheers, fijal ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] New version of Codespeed (0.7) for speed.pypy.org
Hi Paolo, - There are problems with this approach. In the Changes view, when you select a revision that doesn't have results for the currently selected branch, nothing would be displayed. You're referring to an SVN context, right? Otherwise I can't make sense of it. The opposite. For subversion, revisions mark the whole repository, so a revision could have results for both trunk and a branch. That is not the case in mercurial. Regarding my explanation, I understand it is a bit difficult to visualize this UI issues without images. You would need to blindly search for your results. An option is to always display all branches for a revision, but sometimes a revision will contain results for a branch, sometimes for others. Outside of the SVN context, I'm not sure I get what you mean here, because revisions in different branches are not necessarily comparable. Same as above. So the differences between version control systems really suggest that you cannot add a branch dimension to a revision. More like a result is not only associated to a project, revision, and executable, but also to a branch... 2011/1/21 Paolo Giarrusso p.giarru...@gmail.com: Hi Miquel! I would gladly hear other ideas. Here are my two cents! On Fri, Jan 21, 2011 at 08:49, Miquel Torres tob...@googlemail.com wrote: So one idea would be: - Every revision has a branch associated to it (a problem though is that subversion has the same revision number for all branches, while mercurial and git not) This suggests (to me) that a revision would be associated to a specific branch, but then I don't get expressions like all the branches for a revision. Maybe you mean that you would replace revisions with pairs (Revision, Branch)? [...] - There are problems with this approach. In the Changes view, when you select a revision that doesn't have results for the currently selected branch, nothing would be displayed. You're referring to an SVN context, right? Otherwise I can't make sense of it. I guess you can use, on other branches, the closest revision available, after defining a linear order on revisions across branches. You have that order in SVN; since you don't have that in Git, why don't you just use the _date_ of a revision as the ordering key? [For the data structures to implement this, I've seen even seen interfaces to tree-based dictionaries allowing navigating to the key-predecessor and key-successor, which might be especially handy here (such as NavigableMap in Java, dunno about Python).] Of course, that's suitable just as default, so you need to be able to navigate between revisions independently for each branch. Please note that with complex merge histories, using the date does not necessarily make sense - so that at least Git tools provide many linearization algorithms. The problem is that a commit might be made on a certain date in some repository, but be merged on mainline much later, especially when many developers are not committers themselves; one solution is to consider only revisions which were committed directly on the branch or merged shortly after. I also would believe this use case does not appear for PyPy. See help about git log --topo-order and --date-order (such docs used to be more complete, though). You would need to blindly search for your results. An option is to always display all branches for a revision, but sometimes a revision will contain results for a branch, sometimes for others. Outside of the SVN context, I'm not sure I get what you mean here, because revisions in different branches are not necessarily comparable. -- Paolo Giarrusso - Ph.D. Student http://www.informatik.uni-marburg.de/~pgiarrusso/ ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] rPython
Hi, Eva I assume you are asking if there is a program is a valid rpython program, right? Since rpython is a subset of python, you can check if it is a valid python program and then verify the restrictions imposed by rpython. RPython: a Step Towards Reconciling Dynamically and Statically Typed OO Languages lists these. PyPy impementation of rpython appears to check these constraints at initialization time, which is in a sense, python runtime. The result is, I think, to try and see if it compiles. Come to think of it, vaildity and correctness are blurred in dynamic languages. Syntax is checked, but then Imports and asserts can affect if all of the program is even considered. Alternatively if you want to quickly distinguish practical rpython code from python, I guess you could look for clues such as what types are used, what modules imported, etc. Dima On 21 January 2011 08:03, Eva Maia eva_m...@sapo.pt wrote: Hi, It is possible through the PyPy toolchain check if a program is a rPython program? I know the tool Pylint (RPylint) gives an idea, but it seems to me that this tool gives some errors that result from being a little outdated. Thanks, Eva Maia. ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] New version of Codespeed (0.7) for speed.pypy.org
On 21/01/11 08:49, Miquel Torres wrote: @Anto Yes, branches are a pending item that has been requested a couple of times now. yes, I think most of the requests has been by me :) The current solution is actually not to abuse an environment like you say, but to create a new project for a branch. That way it gets cleanly separated, and in a way branches are like different projects. But it is of course not optimal. Technically it is very easy to come up with several solutions (add a branch dimension, for example), but interface-wise it is not easy to find something that doesn't clutter things. Uhm, I don't think that using a different project is a good idea. For branches, we are usually not much interested in the branch history, but in the comparison with trunk (ideally, with trunk at the point we created the branch, or at the point of the last merge from trunk). As for visualize changes, I think that we don't need anything fancy, for example it would be already immensely useful to have the possibility of displaying the Changes page in a way that it compares the performances of the branch against trunk. ciao, Anto ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] New version of Codespeed (0.7) for speed.pypy.org
On 06:14 pm, anto.c...@gmail.com wrote: On 21/01/11 08:49, Miquel Torres wrote: @Anto Yes, branches are a pending item that has been requested a couple of times now. yes, I think most of the requests has been by me :) The current solution is actually not to abuse an environment like you say, but to create a new project for a branch. That way it gets cleanly separated, and in a way branches are like different projects. But it is of course not optimal. Technically it is very easy to come up with several solutions (add a branch dimension, for example), but interface-wise it is not easy to find something that doesn't clutter things. Uhm, I don't think that using a different project is a good idea. For branches, we are usually not much interested in the branch history, but in the comparison with trunk (ideally, with trunk at the point we created the branch, or at the point of the last merge from trunk). As for visualize changes, I think that we don't need anything fancy, for example it would be already immensely useful to have the possibility of displaying the Changes page in a way that it compares the performances of the branch against trunk. How about a Branches checkbox (per project? per executable? per graph? One of those maybe). When it's checked, branch results within the revision horizon (last 10, 50, 200, etc) get plotted on the same graph as the trunk data is plotted. Each branch could be a different color, perhaps (but would at least have hover info telling you what it is). This implies adding a branch column to the results table (or is it the revisions table?). Maybe that's just the obvious way to do it and everyone else already thought of and discarded it already, though. Actually, in general I'd like a way to plot more things on one graph. So maybe this is just a special case of that. Jean-Paul ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] Branches in the mercurial repository
On Fri, Jan 21, 2011 at 10:10 AM, Bea During b...@openend.se wrote: On Thu, Jan 20, 2011 at 10:33 AM, Samuele Pedroni samuele.pedr...@gmail.com mailto:samuele.pedr...@gmail.com wrote: Samuele ctypes-stable Fri Apr 11 15:44:57 2008 Samuele run-django Sat Jul 12 09:46:07 2008 ... closed just means that they are no longer being used (and won't be shown in the default list of branches), I tihnk those are safe to close. +1. closed Samuele ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
