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

[Noel O'B. <bao...@gm...>]

> > BTW, regarding branches - I'm thinking of creating separate branches
> > for parsers under development. This will cut down on the error
> > messages we get when we run the tests on the trunk (too many errors
> > and the tests become meaningless); and also avoid the mistakes I made
> > when when creating the 0.6 release. Any thoughts?
>
> I think this is a good idea. We should create a numbered branch for
> our next release. Is that going to be 0.7? And only stuff that we
> agree on goes in the numbered branch? Should we also try to put a
> flexible timeframe on the branch so that we know what goes in it?

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.

> 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.

> I'd say the release happens sometime in mid-January (things are a bit
> busy at the moment for me, but I should be able to get around to it
> eventually). What do you think?

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? :-)

> About the CDA method: I found the original CDA code for two fragments
> online. Do you think I can just "translate" it into Python and extend
> it for multiple fragments, or do I need to explain on the list what
> the code does and let you implement it for a more cleanroom-style
> implementation.

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 :-) )

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.

> Adam
>
>