fr., 16.07.2010 kl. 03.00 -0700, skrev smichr: > Hi all, > > I have a lot of work that I have separated out into about 35 issues. > The work deals with everything from minor editing of code, to handling > of non-commutatives in simplifications and (hopefully) a total purge > of power-rule infractions (e.g. allowing sqrt(x*y) to become > sqrt(x)*sqrt(y)). When all changes are made, the runtime of the test > suite drops by about 20%.[1] > > This work has survived through the new polys and the ploughing of the > core. If it's going to make it in I would really like to get some help > on reviewing these issues before any other major changes take place. > > ======== it's in branch t at smichr's' github > account =========== > > Everything is sitting in branch t at the smichr account at github. > Everything has been rebased on master. All tests and doctests passed > in 64 bit (but I am double checking after the rebase on the current > master). > > Although the first few commits are independent of each other the > commits that follow them become interdependent. I'm not sure what the > best way is to review these. I can' pull them off independently for > review since they won't rebase on master as independent; the term we > use on the issue page for such issues is "blocked on". The way I would > review these if they were on someone else's branch would be to use > gitk to view a single commit; if I wanted to confirm that the tests > passed I would checkout the particular commit and test it. > > So, >
Hi Chris, You have really been working hard, awesome! > 1) are there ideas of how best to review this? Given the complexity of the patchset, I would recommend to use the smartbear web hosted tool that Andy and I used for reviewing the fortran code generator. Andy fixed it so that we have a free hosting for the Sympy project on their demo server, see this post: http://groups.google.com/group/sympy/msg/40cf5f5327d9fcd3 I think you will benefit from that for two reasons: 1) On smartbear it is the final result that is reviewed, rather than each patch. This means it is possible to attach comments issues to specific lines in the final code, so there is emphasis on the big picture. 2) Everything is organized in phases. When you upload the code you start a review phase. When all reviewers have set their status to "done", it fixing time. When you are done it goes into a review phase again. The phases ensure that everyone knows when it is their move, and so it can speed up the process. If you are interested I can upload the patches for you, to get you started. Øyvind > 2) is there someone that has a fast 32-bit machine that would be > willing to run the tests to make sure that they run there? I am using > a script of Aaron's that makes this really easy: you just give the > starting and ending SHA for the commits and they are all tested and > the results sent to a file. > 3) is there someone who can profile this to identify any areas that > regressed significantly in terms of performance? > > [1] it's about 17% if the sympification of strings is done by default, > but that is something that can probably change with the converter- > option in sympify. This will no doubt come up in the review process. > -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sy...@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
