On Tue, Jan 20, 2009 at 1:45 AM, Petr Novak <shaman@xxxxxxxxxxxxxxxxxx> wrote:
If 'generic_fns/relax_data.py' is the best, then I will use the
subversion command 'svn cp' to copy 'generic_fns/relax_data.py' to
some other file for you. This preserves the historic links between
the files in the repository so developers now and in the future can
see where you started from - this is essential. So I need to know
what you would like to call the new file. Once I have made the copy,
you can use 'svn up' on your checked out copy of the 'cst' branch to
get the code.
Aforementioned 'duality' in the templates makes me hasitate which file
should be the copied ('generic_fns/relax_data.py' or
'generic_fns/diffusion_tensor.py'). Is it good idea to simply add
'_cst', e.g. 'generic_fns/relax_data_cst.py' ?
The name has of this file has nothing to do with relaxation data. I
would suggest a name related to it's function, something that is also
generalisable for other chemical shift related functions. I would
therefore suggest:
generic_fns/chemical_shift.py
There may be a better suited name though that you could think of.
Obviously I haven't got the idea of this part. I am not editing directly
the file 'relax_data.py' itself but more like copying out usefull parts
of a code to the new file called 'cs_tensor.py' (if that's what you ask
for). In the same way I created 'prompt/cs_tensor.py' and
'data/cs_tensor.py'.
Rather than copying out parts, this should be done by copying the
entire file and then modifying it. Preserving history is important.
So that is why I created the generic_fns/chemical_shift.py file:
https://mail.gna.org/public/relax-commits/2009-01/msg00321.html
This was done - very importantly - by using the 'svn cp' command. I
used the module name 'generic_fns.chemical_shift' to future proof it.
For example I can see it being useful for dynamically averaged
chemical shifts, if anyone ever decides or tries to do anything with
that.
For creating new files, I have to do that as you do not yet have
access to the repositories. But this way you can watch what I do and
learn how subversion is used for this. So whenever you need a new
file, please first discuss this on relax-devel. Even when you have
commit access, everyone should discuss when new files are created.
That way, the design can be discussed as a group and the best solution
for integration into the relax design framework can be found. The new
code needs to play nicely with the old for it to be accepted.
Actually, any design concepts should be first discussed on
relax-devel.
relax> relax_data.delete(ri_label='R1', frq_label='600')
Traceback (most recent call last):
File "<console>", line 1, in ?
File "/home/shaman/relax/prompt/relax_data.py", line 195, in delete
relax_data.delete(ri_label=ri_label, frq_label=frq_label)
File "/home/shaman/relax/generic_fns/relax_data.py", line 410, in delete
self.run = run
NameError: global name 'run' is not defined
And this is the result. The relaxation data deletion code is
currently non-functional in the 1.3 line. It's not used much and is
not in a system test, hence why it hasn't been converted yet. But if
you convert it for your code, that will be very good for learning the
differences between the two lines.
Yes, I did the conversion for delete() function and after finishing this
email I will do the same for display() function. Do you want me to post
it here or should it be included in our patch ?
For this code, I would suggest one patch per small increment of code
you make - for example fixing the delete() function should be 1 single
patch.
So for each function one patch if I got it right. I found some more
functions to be repaired so I will try to submit patches for everything
I will able to fix.
Well, have a close look at the relax-commits archives
(https://mail.gna.org/public/relax-commits/). Some patches change
just 1 line! Especially bug fixes. The thing with open source is
that you commit small changes early. This makes it possible for
people to peer review your code as it comes in, and catch any
problems, clashes, or design issues early. So normally when I work on
one function, I make between 5 to 50 commits (depending on how big the
function is and how dependent it is on other code). If the function
is small, 1 commit is ok.
I have a question though, how do you know that this function now
works?
I started relax, input some of our data and then executed the delete()
function with appropriate parameters and checked for presence of the
(to-be-)deleted data. Similar way I used for testing display(), I just
input some data and checked if display() really displays the data correctly.
This should be placed into a system test then. You have essentially
executed a system test, and exactly what you are doing to get the
error should be placed in the system test framework. Then if the
function breaks in the future, due to other code changing, then the
test suite will instantly say that there is a problem that needs
fixing. The only difference with the system test is that you only use
the tiniest subset of input data required to produce the error. For
relaxation data, the required data for a system test is already there.
For your analysis the required data probably missing, but only data
from 1 or 2 spin systems is needed for the test.
You
should before you start anything have a system test which checks the
full behaviour of the modified analysis - carefully checking the
results to see if it is the same as what your code based on the 1.2
line returns. Do you have a link for that code that you could post
here, just for reference?
Uh, tbh although it worked somehow it was way far from being publicable.
We didn't bother with naming conventions and many other important things
because we kinda wanted to get it functional asap and see if it gives
some interesting results. As it gave something usefull we decided to do
it properly. So if you really want to see it I can give you a link to
our version, but I really have to stress that it is done in a
particulary awfull way.
It will be useful to see the code anyway, just for understanding the
perspective of the new code going into the 'cst' branch. It's not
legally necessary as you haven't distributed the code to anyone, but
it would be nice to see where the current development is coming from.
c) There is always some other option :-P :-)
I'm too slow converting the entire code base :)
As I understood it's now way bigger then original "script" for executing
Model free program and reading its results :-)
There is quite a lot of code in there nowadays!
Yeah, hopefully it will keep growing and absorbing features :-)
Thanks to the open source nature of the program, that's guaranteed -
even if I stop working on the project.
Cheers,
Edward
Re: generic_fns.relaxation_data.delete()