On Tue, Jul 16, 2013 at 7:15 PM, Geoffrey Irving <irv...@naml.us> wrote:
> On Tue, Jul 16, 2013 at 4:51 PM, Anthony Scopatz <scop...@gmail.com> > wrote: > > Hi Geoffrey, > > > > Not to toot my own horn here too much, but you really should have a look > at > > xdress (http://xdress.org/ and https://github.com/xdress/xdress). > XDress > > will generate a wrapper of the Force class for you and then also create a > > custom numpy dtype for this class. In this way, you could get exactly > what > > you want. > > Unfortunately it's unlikely to work out of the box, since it uses > gccxml which appears to still be based on gcc 4.2. All of our code is > C++11, and we need to preserve portability to horrible places like > Visual Studio (yes, these two constraints are just barely compatible > at the moment). > Hey Geoffrey, I don't think that GCC-XML should be a show stopper. There are a couple of reasons for this. The first is that, correct me if I am wrong, but most of the C++11 updates are not really changes that affect top-level API elements -- which is the only thing that you care about when creating wrappers. So unless you are relying on a lot of lambdas or something, my guess is that GCC-XML might just work anyways. The second reason is that xdress is written to be *very* modular. There is no reason that it needs to rely on GCC-XML at all. Other parsers and ASTs, such as Clang or SWIG or ROSE, could be used. In fact there is a mostly complete version of a Clang AST present in XDress already. I have disabled it and am not worrying about it personally because the current Clang Python AST bindings do not support template arguments. Since this is a major use case of mine, I had to abandon that code line. However, other people could forge ahead with Clang in one of a few ways: 1. Use the nascent XML output of Clang, 2. Use the existing Clang Python AST bindings, understanding that they are incomplete 3. Fix the Python Clang AST bindings 4. Write your on Python Clang AST Bindings (I know people who have done this but they are not open sorce), possibly using XDress! In any event, none of this is super difficult, wouldn't impair xdress development at all, and everyone would benefit. Alternative parsers are something that is on my radar and I would love to support. > > If you run into any trouble, let me know and I'll be sure to help you > out! > > This is the kind of thing that xdress is supposed to do so bugs here are > a > > big priority for me personally =) > > We're currently using a custom Python binding layer which I wrote a > while ago after getting fed up with boost::python. I have been down that painful road =) > Our system is > extremely lightweight but also limited, and in particular is missing a > few key features like automatic support for named and default > arguments (since these can't be introspected inside C++). XDress supports these. > It'd be > great to chat more about our two feature sets and whether there are > opportunities for collaboration and/or merging. I'm not sure if this > list is a good place for that discussion, so we could optionally take > it off list or to skype if you're up for that (send me an email > directly if so). > I'd be happy to! My skype name is 'scopatz' or you can find me on Google+. I tend not to just hang out on skype and I have a lot to do tomorrow, so if you want to set a time that would probably be best. My schedule is pretty flexible if busy. Be Well Anthony > Here are links to our system, which unfortunately is undocumented at the > moment: > > https://github.com/otherlab/core > https://github.com/otherlab/core/blob/master/python/ClassTest.cpp > # Unit test for wrapping a class > > Geoffrey > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
