[Biococoa-dev] NSData

[Charles Parnot]

>> The symbolChar should just be one char, not a buffer of one char.
>> The ivar should be:
>>     ...
>>     char symbolChar;
>>
>
> I think you meant:
>
> unsigned char    symbolChar;

I don't think it makes a lot of difference in the end, as long as we  
are consistent.


> Can we then in the initWithChar method just use:
>
> symbolChar = aChar;  ?

Yes!! char is just like int, or float, or BOOL. It just happens to  
use only one byte. You can pass it around, and it is actually lighter  
than a pointer.


> OK, here we go :)
>
> I am now looking into updating the translation code. This is not my  
> field, so I hope I do it right, and therefore ask here before I  
> really screw up.
>
> 1. Should we keep the BCSequenceCodon subclass?
>
> 2. The translation code now uses symbolArrays. Should we keep this,  
> or do we need to rewrite these classes so that they use the char  
> array in NSData?

The whole translation stuff was set up by John in one flight over the  
atlantic (or was it the Channel?). It needed some work anyway, but  
the disappearance of BCSequenceCodon complicates things quite a bit.  
We could keep a private BCSequenceCodon class for now, or move the  
relevant code to the translation tool. I like the idea of a  
BCSequenceCodon type, though. Well, some more debate to come!


>>  One nice thing with CVS is you can see what changed, and you can  
>> always revert back to an old state. So I guess you should use CVS?  
>> If some source files don't compile, you can always temporarily  
>> uncheck the 'Target' box so they are not included in the build.
>>
>
>
> I rather not commit them to CVS until the classes are more  
> finalized. But if no-one objects, I will commit the updated files.  
> Or I can use a CVS branch. Anyone knows how to use branches within  
> Xcode?

I don't know how to use branches in CVS, I seem to recall it is a bit  
tricky and I don't think there is really a need for that. Nobody is  
working much on the code right now, except you, and things can always  
be put back the way they were (it is very easy with CVL to look at  
past versions of each file, and get a piece of the old code back if  
necessary; it is also possible to just go back in time for the whole  
project). It is not like we are developing a real separate branch.  
Also, if you commit changes, we can more easily look at it, and even  
make minor corrections. This is really the CVS goal, and we should  
just use that tool and take advantage of it.

I see no problem if you commit these changes, as they are needed and  
there was a decision to go forward.

cheers,

charles


--
Xgrid-at-Stanford
Help science move fast forward:
http://cmgm.stanford.edu/~cparnot/xgrid-stanford

Charles Parnot
charles.parnot at gmail.com