I’ve come up with a name for the python thingy (which I still haven’t worked on… been LAZYTOWNING LOL).

Non-Intrusive Python Embedding Library (NIPEL)

Pronounced “NIPPLE”.

5 comments

I don’t feel like coding, so this thread is now about pictures of hot/cute chicks.

Spam pics of hot chicks pls. Danke.

13 comments

lolol okay, almost done with the basic data-sharing. Here’s the usage I’ve worked out for it:

You take your happy user-defined POD struct. Well, it doesn’t have to be a POD, since Python takes the offsets into the struct just fine. I guess it isn’t going to handle inheritence at this point, but whatever. SO YOU HAVE A POD CLASS ANYWAY:

struct Rah {
        int arg1;
        char* arg2;
};

You then call some code to get a registration stub, which you use to set up exactly which members you’d like to expose to python, what you’d like them to be referenced as, blah blah then you finalize the stub (which deletes it!!!) -

   StructRegStub* stub = exposeDataType( "Rah" );
        stub->exposeMember( "arg1", &Rah::arg1 );
        stub->exposeMember( "arg2", &Rah::arg2 );
        stub->finalize();

And then boom your class is now recognized in Python and you can send them back and forth and stuff. Except you can’t yet because I haven’t coded that. Well, I might of (actually, I think I did). But I haven’t tested it yet.

And besides there’s still a couple bugs in the first part (lol, shit breaking: offsets, members overwriting each other, etc.) so I have to fix that first :3

1 comment

Ack, I know no one cares about my Pythong blabbery, but I’ve been spending a lot of time thinking about it (in one way or another). Anyway.

I’ve been working out how the shared data stuff is supposed to work. And I’ve got a prototype working, but it isn’t pretty at all. And its only going to get worse from here; its hard as hell to make a nice user interface.

Anyway. For us to use our C structs in Pythong we have to prefix them with a bunch of Pythong data headers so Pythong knows how to eat it. This is easily wrappered -

template < class T >
struct WRAPPER {
        PyObject_HEAD
        T data;
};

Cool. So now we can just instantiate an instance of that template to create a wrappered version of the user’s structs.

But then SHilbert came a long and was like “lol how do you handle live references?” and I was like “wtf…. OH DAMMIT”.

Basically, if you declare yourself an instance of your user struct, say -

struct foo { ... };

void blah() {
foo myfoo;
call( "some_python_func", myfoo ); // takes a reference.
}

What happens is that struct foo has to get converted to struct WRAPPER. Which means a copy construction. Which means you’re getting data passed by-value, not by-reference.

BUT WAIT!

What if, from Pythong -

myfoo = foo();
call( "some_c_func", myfoo );

The Pythong->C function handler will be called, and extract the struct foo from the struct WRAPPER* passed up from Pythong, then pass that (hopefully by refernce) to the expectant C-function. WHICH MEANS ITS BEING PASSED BY REFERENCE.

I’m not really sure what to do about this. I’m really really tempted to leave it like this, because, honestly, that’s good enough for me. Wish I could do it by-ref both ways, but the limitations of C make it not so.

Opinions?

3 comments

Python -> “calls” C -> “calls” Python -> Propagates expected value!

Yayayayay. Now to flesh out the templates so they accept more than 2 argument functions (lolol lots of repetitive template code to write :O) and then to do the data sharing between Python<->C. Basically, registering C structs as Python object types.

Also, I think I’ve found a way to get around the dilemma discussed before (the call('funcname') syntax with Pythong) – functions can be represented in Python as an object which implements __call__ (essentially a function object). If I (from C++) create such an object whose __call__ method passes the arguments AND a unique string to identify which function is being called to the function call handler in C++, then I can effectively use the desired (normal) syntax funcname(args). Which is cool.

It’ll take a couple more days to implement that though :(

2 comments