On Aug 17, 2010, at 11:07 AM, Brian Granger wrote: > On Tue, Aug 17, 2010 at 9:23 AM, Christian Muise > <christian.mu...@gmail.com> wrote: >> One thing that was pressed on me was the desire to have every commit run >> clean. Regardless of what point in the commit history, all tests should >> work, or at the very least the system should install (broken imports could >> alter this). I'm currently compiling an exhaustive execution of 'bin/test >> sympy/physics' for every one of the 140 commits, and many of them don't >> work. Many have import issues too, which throws a wrench into the mix. I've >> attached the output until the script I'm using runs into an infinite loop >> (it tries to keep unrolling the commit history), called output.txt.
That's a nice script that you're using :) By the way, I don't know if that will really be testing everything in a history with merges, because HEAD~1 is not unique for a merge commit. > > For complex code written by 3 people I don't think it is reasonable to > expect that every commit runs clean. There were many times that one > of us would commit partially working code that the others would pick > up and continue with. So I am sure there are many points in the > history where tests don't pass, code doesn't work or modules are not > even importable. So how independent is your code from the rest of sympy? Will "from sympy import *" still work in those commits? If not, I will have to agree with Christian. The reason is that commits like these make bisecting the code very difficult. Now personally, I don't care if the rest of sympy imports fine even if the physics module doesn't, but you might if you ever wish to bisect the physics code in the future. Test failures aren't as important, but you should consider fixing the commits where it doesn't even import correctly. > >> Now I don't think rebasing like mad is really an option -- I only had to >> deal with dozens of commits for my branch, not 140 :p -- but there needs to >> be some sort of amalgamation of the commits before it's brought into the >> trunk. A question for the rest of the community: What's the best way for >> Matt and Addison to go about achieving this? One single commit of the >> physics module? > > Trying to rebase these commits into a set of self contained commits > that all run cleanly will be nearly impossible. Also, with three of > us working on this code, the history of commits and merges is an > important part of the development process that I don't want to loose. > It is also important from the attribution and authorship standpoint. > If we squash all of these into a single commit, all of this > information is lost. I agree. Squashing into one commit removes the whole point of using a source code management system like git. Aaron Meurer > > The code review for this stuff should be done on a file by file basis, > not a commit by commit basis. The reason this works for this branch > is that all we really did was create new files. We didn't (IIRC) > touch the existing code base at all, which does make things easier in > this case. > >> Ideally there should be something you can do that would make reviewing the >> branch / commenting within github easier. As it stands, comments would be >> scattered throughout the 140 commits which will become unwieldy quite fast. >> Final concern before I take a gander at any of the code is that the HEAD >> version of the hilbert2 branch doesn't pass all the tests (see the attached >> head.txt). Is this expected? > > No, that should be fixed. > > Cheers, > > Brian > >> Cheers >> Christian >> >> On Mon, Aug 16, 2010 at 3:19 PM, Matt Curry <mattjcu...@gmail.com> wrote: >>> >>> Addison and I have been working on adding features to sympy.physics >>> for our GSoC project. We started off working on separate branches, >>> but, as time progressed, our two branches merged together. Here is a >>> description of what we have added: >>> >>> We have added a general quantum mechanical framework using Dirac >>> notation. This includes the ability to create bras, kets, inner/outer >>> products, and other useful objects for symbolic quantum mechanics. The >>> base classes for states can be sub-classed if users wish to create >>> their own states with custom representation. We have created custom >>> quantum versions of the Mul, Add, and Pow classes in order to preserve >>> the special operation rules between these objects. Hilbert spaces from >>> the hilbert.py file are used to check the dimensions of objects for >>> validation of binary operations. We have also included an example file >>> (particle in a box: piab.py), which gives a taste of how this module >>> can be used. >>> >>> Also included in the branch is a module for modeling quantum >>> computation. The module (which uses the quantum base) gives the user >>> the ability to create quantum gates (both single qbit and multi-qbit >>> gates) as well as the qbit states on which they act. These gates can >>> be either applied directly, or represented in their matrix form. Also, >>> the module has a notion of measurement and can preform the quantum >>> Fourier transform using elementary gates. The underlying framework is >>> flexible enough that further addition of gates can be accomplished by >>> simply sub-classing Gate and specifying its matrix. >>> >>> The branch has extensive tests and documentation (including doctests). >>> The code is ready for review and can be found at >>> http://github.com/mattcurry/sympy/tree/hilbert2/sympy/physics/. >>> >>> Cheers, >>> Matt Curry and Addison Cugini >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "sympy-patches" group. >>> To post to this group, send email to sympy-patc...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> sympy-patches+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/sympy-patches?hl=en. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sympy-patches" group. >> To post to this group, send email to sympy-patc...@googlegroups.com. >> To unsubscribe from this group, send email to >> sympy-patches+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/sympy-patches?hl=en. >> > > > > -- > Brian E. Granger, Ph.D. > Assistant Professor of Physics > Cal Poly State University, San Luis Obispo > bgran...@calpoly.edu > elliso...@gmail.com -- You received this message because you are subscribed to the Google Groups "sympy-patches" group. To post to this group, send email to sympy-patc...@googlegroups.com. To unsubscribe from this group, send email to sympy-patches+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy-patches?hl=en.
