Re: [cclib-devel] [OpenBabel-scripting] OBMol.Rotate() using python wrapper

[Adam T. <a-t...@st...>]

> I need to think some more about this, as what I was proposing was
> slightly different. I think you're saying that we should do
> development on the 0.7 branch. I'm afraid it will get slightly
> confusing if we are developing both on the branch and the trunk (as
> changes may have to be merged in both directions). I was suggesting
> that development for new parsers should be done on a branch, e.g. the
> molpro parser branch. This would only have tests and data files for
> molpro, for instance, and wouldn't contain the bridges, methods, etc.
> modules, so that development would be more focused (and the only
> changes would be parser related). Since Jaguar is slated for inclusion
> in the next release, I think it'd be easier at this stage to leave it
> on the trunk and do the final development there.

I hadn't thought about the difficulty in maintaining a 0.7 branch and  
trunk. I do like the idea of a parser-specific branch for new  
parsers. I'm assuming you'll still include the more finished parsers?  
I'll let you handle it since you know what you have in mind.

>> My proposal for the 0.7 branch would be:
>>
>> Initial Jaguar parser (It parses most things, as i recall).
>> CDA method
>> DOS stuff?
>
> I'd like to get the volume stuff in shape and add that too. I think
> it's important to get some sort of volume data created so that some
> progress can be made on pop analysis methods that use volume data. In
> the course of getting this ready I will discuss its limitations on the
> list, and we can decide if it's enough.

Sounds good. You'll move the discussion about volume stuff to a new  
thread when you start working on it?

> Sounds good in general, but I should say that Christmas is an
> open-source free zone for me. mid-Jan...isn't that like, cclib's first
> anniversary? :-)

Ah, ok. I'm looking forward to Christmas break so that I can do some  
hacking. After visiting with the family of course!

> I think Step 1 is to reimplement it so that it gives the same answer
> as the original code, however you do it. Once this is done we can
> think about refactoring it. (I hope there are no computer scientists
> reading this list - we can call this prototyping if it makes them
> happier :-) )

So you don't think there's any problem with me basically translating  
the code I found into Python? Not even from a violating some license  
standpoint? I don't think there is since I'm going to write our  
method from the ground up using the CDA code as a guide, instead of  
just copying the code and altering after the fact. Also, I'm  
translating it to another language! So there will be unique code from  
my side anyways.

> I was thinking about whether it is important for all of the cclib
> algorithms to be 'identically' implemented, etc. In the end, I would
> just prefer to have implementations of various algorithms that work,
> rather than worry about this too much - after all, we would like
> contributions from outside cclib, and it's unlikely they will come
> packaged in the same way as our own functions/classes.

I agree with you, although I think we should try to keep things as  
consistent as possible. If we do get code contributions, I would  
suggest we should still create classes that have attributes which are  
created from a calculate function.

Adam