On Apr 27, 2011, at 1:31 AM, Mateusz Paprocki wrote: > Hi, > > On 27 April 2011 09:20, Ondrej Certik <ond...@certik.cz> wrote: > On Tue, Apr 26, 2011 at 8:39 PM, Aaron S. Meurer <asmeu...@gmail.com> wrote: > > On Apr 26, 2011, at 7:08 PM, Ondrej Certik wrote: > > > >> On Tue, Apr 26, 2011 at 5:18 PM, Haz <christian.mu...@gmail.com> wrote: > >>> Couldn't some VM's do the trick? > >>> > >>> On Tue, Apr 26, 2011 at 8:05 PM, Mateusz Paprocki <matt...@gmail.com> > >>> wrote: > >>>> > >>>> Hi, > >>>> > >>>> On 26 April 2011 16:59, Ondrej Certik <ond...@certik.cz> wrote: > >>>>> > >>>>> On Tue, Apr 26, 2011 at 4:50 PM, Ondrej Certik <ond...@certik.cz> wrote: > >>>>>> On Tue, Apr 26, 2011 at 9:38 AM, Tom Bachmann <ness...@googlemail.com> > >>>>>> wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> so on my bus ride today I figured it would be nice to have an > >>>>>>> automated way to see to what extent open pull requests play along > >>>>>>> nicely. In particular this would be good when over the summer about > >>>>>>> ten of us will be working on fairly large projects: Here it would be > >>>>>>> helpful to see if there are conflicts between branches that are not > >>>>>>> even up for review yet. > >>>>>>> > >>>>>>> So I hacked together a small script [1]. The inspiration of this comes > >>>>>>> from linux-next. > >>>>>>> > >>>>>>> Here is the description from the file: > >>>>>>> > >>>>>>> # Tool to aggeregrate several branches, automatically merge them (if > >>>>>>> possible) > >>>>>>> # and create statistics about unit tests. > >>>>>>> # > >>>>>>> # Usage: sympy-next.py repo branches out-dir > >>>>>>> # where > >>>>>>> # repo is is the location of a clean repository (possibly > >>>>>>> empty) > >>>>>>> # that is going to be used. > >>>>>>> # branches is a file containing a list of branches, one entry per > >>>>>>> line, like > >>>>>>> # so: > >>>>>>> # https://github.com/sympy/sympy.git master > >>>>>>> # /home/ness/src/sympy 360_zoo > >>>>>>> # ... > >>>>>>> # out-dir Is the name of a directory where output is going to be > >>>>>>> created. > >>>>>>> # > >>>>>>> # This program walks the list of branches, fetches all of them, and > >>>>>>> tries to > >>>>>>> # merge them in order. If there are merge-failures the branch is > >>>>>>> dropped. After > >>>>>>> # all successful merges are done, the unit tests are run. Finally a > >>>>>>> report is > >>>>>>> # created of which branches could be merged, and which tests passed. > >>>>>>> # All commands run are logged to a file in the output directory. > >>>>>>> > >>>>>>> Notes: > >>>>>>> 1) This is hardly well-tested. All improvements are welcome. > >>>>>>> 2) The html output is ugly, and so is the code that creates it. This > >>>>>>> is the display of my complete lack of web-programming capabilities. > >>>>>>> 3) The tests are currently only run after all merges are complete, so > >>>>>>> there is no way to tell which branch introduced the problem. > >>>>>>> 4) Also the output is not at all pruned, so as branches go stale, and > >>>>>>> also with time, it will probably become too long. > >>>>>>> 5) If/When we set up a new buildbot there should probably be a nicer > >>>>>>> way to do this. But: > >>>>>>> 6) Is there any interest in this, and if so is anyone willing to run > >>>>>>> this script (or something similar) more or less manually for a while? > >>>>>>> I would imagine that person to mainting a branches file where > >>>>>>> additions/deletions can be requested by email, and then the script is > >>>>>>> run about once a day, with results published somewhere and perhaps > >>>>>>> some nagging emails being sent around. I suppose with a bit of > >>>>>>> fiddling this could be done basically automatically using a cron-job. > >>>>>> > >>>>>> Absolutely! I have a server, which currently is running > >>>>>> planet.sympy.org, and I would like to migrate the planet to some other > >>>>>> online service, and then use that server for exactly the purpose of > >>>>>> testing sympy patches (in several python installations and so on). > >>>>>> > >>>>>> One can also use this github pull request API: > >>>>>> > >>>>>> http://develop.github.com/p/pulls.html > >>>>>> > >>>>>> to automatically determine new pull requests and generate some > >>>>>> statistics, e.g. if all tests run and so on. > >>>>> > >>>>> So elaborating more, here is what we should do: > >>>>> > >>>>> 1) the sympy-next would automatically determine over the pull request > >>>>> github API that a new pull request was added, or more patches pushed > >>>>> to it. It would generate an automatic comment into the pull request, > >>>>> with saying "All tests pass + link to the test results", or "Tests > >>>>> failed + link to the stats and more details". > >>>>> > >>>>> 2) If the pull request is reviewed and all tests run (as tested by > >>>>> sympy-next and reported in the comment in the pull request), one can > >>>>> just click "Merge" in the pull request: > >>>>> > >>>>> https://github.com/blog/843-the-merge-button > >>>>> > >>>>> to merge it in. This will speedup trivial patch merging a lot, as I > >>>>> don't need to run it on my machine, as long as we trust sympy-next, > >>>>> but we can, by simply manually examining the logs, making sure that > >>>>> all is ok. > >>>> > >>>> A problem with this plan is that you need two machines (32- and 64-bit) > >>>> to > >>>> believe automated tests (at least on Linux). > >> > >> Also maybe building Python with 32 and 64 bit mode might help. I think > >> Aaron has some experience with this. > >> > >> Ondřej > > > > Yeah, there is no need to have two machines. It only matters what Python is > > compiled as, which can be either if you have a 64-bit machine. In my case, > > Python has precompiled 32-bit binaries for Mac OS X, and 64-bit Fink builds > > Python as 64-bit, so I have both of each. > > > > I figured out the flags to compile Python 2.6 as 32-bit, but I put them in > > a talk page on the old MediaWiki wiki :-\. Ondřej, do you still have > > backups of that somewhere? > > I just looked for it, and I found some old mediawiki database mysql > backup, but I would need to figure out a password for it. > > You can try this: > http://dev.mysql.com/doc/refman/5.5/en/resetting-permissions.html#resetting-permissions-unix > > Isn't it described in this blog? > > http://blog.devork.be/2009/02/compiling-32-bit-python-on-amd64.html > > It should be easily doable, you just need multilib for this (on Ubuntu it > should work out of the box). > > To sum up, SymPy requires the following configurations to be tested: > > T = {32-bit, 64-bit} x {2.4, 2.5, 2.6, 2.7} x {python, gmpy} x {pure, cython}
For the Python one, we should test it without gmpy installed, so that we know that it works in pure Python mode. This is trivial to do if you use tox, which I would recommend. Testing in pure Python is also important so that we don't accidentally introduce test failures if some external library isn't installed (like numpy or something). By the way, that's 32 possibilities. We really need some kind of buildbot to do this on. Going back to http://code.google.com/p/sympy/issues/detail?id=1117, should we maybe consider a cloud computing solution? Aaron Meurer > > We could try to emulate running tests on Windows under Wine, so T x= {Linux, > Windows}. It would be good to test SymPy on Mac, but this may require too > much effort. > > > > Ondrej > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to sympy@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. > > > Mateusz > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to sympy@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. -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@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.
