Re: [cclib-devel] C bridge and changes to the progress updater

[Adam T. <ate...@gm...>]

And here I thought when you extended Avogadro to parse a file with cclib,
Avogadro had a python interpreter built in. It's actually calling the
system Python and its installed packages? Well, it's possible to actually
imbed an interpreter, load modules, and play around with Python objects (
http://docs.python.org/2/extending/embedding.html). The API has a bit of a
learning curve, so I figure if cclib provided functions that took care of
most use cases, others might find it useful.

The C-functions don't really impact the Python source (except for the
callback function changes I've already made). But since I'm still working
on the C-functions, I'm ok with those going into a separate branch (or the
website).

As far as the callback changes I've made, do you also want those in a
separate branch? Or can they go in trunk for the 1.1 release? It involved
only a handful of changes to logfileparser.py and the progress classes, and
I think it's ready to go out with the next release. The changes also make
implementing custom progress classes more flexible since instead of needing
both (and exactly) initialize and update functions, it only needs a
function (with any name) that expects a number and text.

Adam


On Sat, Feb 9, 2013 at 12:54 AM, Noel O'Boyle <bao...@gm...> wrote:

> I've never heard of calling a Python library from C++, but sounds very
> interesting. Regarding the API change, that will need a cclib 2.0. I
> have no particular objection to this if necessary but you should
> probably check this into a branch while I get out this release. Unless
> there's a way to support the existing behaviour while adding the new
> one.
>
> - Noel
>
> On 9 February 2013 07:32, Adam Tenderholt <ate...@gm...> wrote:
> > Hi all,
> >
> > I've been thinking about how to make cclib a bit more friendly towards
> > non-Python developers/users. Specifically, those that wish to incorporate
> > cclib into their existing C/C++/Obj-C codebases, but don't want to deal
> with
> > getting into too much of the mess that is the Python C-API or have the
> > overhead of Boost (which is C++) or others. I propose creating a handful
> of
> > C functions that handle most of the nitty-gritty of this.
> >
> > For instance, I envision a simple #include "cclib.h" with functions like
> > getParserModule() and ccopen(), to return the cclib.parser module and a
> > logfileparser object. I've already begun the implementation of these
> > functions. There may still need to be some calls to the Python C-API, but
> > this bridge should be as simple as possible. Seem reasonable? Or have a
> > better suggestion?
> >
> > Also, related to this is a minor required change to the progress part of
> > logfileparser API. Since I want this to be rooted in C, it should not be
> > dependent on classes. So instead of passing a progress object to the
> > initializer, a callback function should be passed. I've already made
> these
> > changes (uncommitted to SVN though) and updated the TextProgress and
> > Qt4Progress classes by passing their update functions to the
> logfileparser.
> >
> > Cheers,
> >
> > Adam
> >
> >
> >
> ------------------------------------------------------------------------------
> > Free Next-Gen Firewall Hardware Offer
> > Buy your Sophos next-gen firewall before the end March 2013
> > and get the hardware for free! Learn more.
> > http://p.sf.net/sfu/sophos-d2d-feb
> > _______________________________________________
> > cclib-devel mailing list
> > ccl...@li...
> > https://lists.sourceforge.net/lists/listinfo/cclib-devel
> >
>