2010/1/11 Michael Bieri <michael.bieri@xxxxxx>:
Hi Edward I think the problem is that the initial relaxGUI was designed as a one-file script to be executed by the relax command. As the whole program was reformatted and split into different files (to simplify) and the prompt commands were exchanged to API commands, there are lots of changes.
This is exactly how relax started as well. It was simply a script used to run Art Palmer's Modelfree4 program and process the results. It was originally called modelfree, then mf, and finally relax. You can see the original modelfree script(s) by checking it out from the repository using: svn co http://svn.gna.org/svn/relax/0.1 v0.1 For a laugh, you can even see my very first initial script I wrote: svn co http://svn.gna.org/svn/relax/0.1@r1 v0.1_start here you'll find the file 'old_scripts/modelfree.pl' which is my original perl script I wrote during my honours year in the Gooley lab. The first revision of relax was just a translation of this 1500 line script into python. Since then the program has evolved hugely, but only by taking numerous very small steps.
I don't know anything about software development, but I think before committing every changes, there should be a program that works.
I also started with zero knowledge about coding. As for having a functional program when committing, for a branch this is not necessary at all! Most of my branches have stages whereby the code is non-functional. It just has to be functional, clean, and properly written before being merged back into the main line.
I haven't even started to incorporate the settings. The only changes are simplified: split the huge relax_gui.py file,
This I have already committed.
convert prompt commands to API (model-free part still not working),
This is not in yet. It is a real pity that this has not been separated - that would have really have helped me to help you to get everything functional. I could have commented on how to do things better, correctly, etc.
deleted easygui.py and wrote filedialog.py and message.py,
I think I have this committed already.
minor cosmetics such as T2 to R2 and '/' to os.sep.
These should have been separated :S These small changes completely hide the important changes that I really should be helping you with. Would it be possible to separate these out? I.e. take the repository version (many times if necessary) and re-make these changes. So there is one patch for T2 to R2, one for os.sep, etc.? The other thing that is hiding the change from generating and running a relax script to plugging directly into the relax API is that there are GUI interface changes :(
As the current shape of relaxGUI looks (almost) as the final version (only integration of settings parameters and fixing model-free calculation), I think your mentioned exception to write a huge commit would be ok. Then, I will commit every single changes as a new message. Last year, I tried to upload a commit, but I got some error messages. Is there something special that has to be applied?
Ah, you don't have commit access yet! First you have to prove you can create proper commits (i.e. only contain one type of change) with informative commit messages. Then after I apply a few of these and I and the other relax developers are satisfied that your skill level is good enough, we will have a vote to grant you commit access. Only then will you be allowed to modify the relax repository. Therefore for this large patch, would you be able to write the commit message and then post it on the mailing list? I can then apply the patch with the message. If your developments are too fast, in the near future as an alternative, we could grant you limited rights to modify just the bieri_gui branch. See how it goes with submitting small patches together with their commit messages first (both attached to https://gna.org/task/?6847). If I can't keep up with you, I can discuss this idea in private later on with the other developers.
In general I think the idea of commit every changes is a very good idea and may help to organize the software package (especially when becoming too complex).
I can't emphasize how important this is :)
So let me know if this is ok for you.
It is ok, but I might try to first fix a few of the basic cosmetic changes and commit these separately (i.e. a new patch will be needed). There are a number of problems still, but it is impossible to comment on almost 8000 lines of changes in one go! One, for example, is that the import statements using '*' must be eliminated. The "from xxx import *" notation is a debugging nightmare as it can unknowingly overwrite things in the namespace of the importing module. It can take days to debug these oddities. Others include how to better integrate into the relax API and also how to make the interface more flexible. Note that I'm not interested in the final product when looking at the changes - I'm interested making sure the code is good, even if the user will never see that. This will make it easier to maintain or extend the GUI in the future, even if you stop developing it. Cheers, Edward