It looks like you're new here. If you want to get involved, click one of these buttons!
Well, a char * could mean many things, but in the vast majority of the cases, it points to a null-terminated string, so SWIG takes liberty in assuming it as such. Besides a char * is all you need to properly access a null-terminated string. For a char ** though, is it a null-terminated list of null-terminated strings? Is it the address of a pointer to a single null-terminated string? Or is it what it is in this case? So, SWIG doesn't attempt anything fancy when it sees a char ** by default. You can make it wrap a char ** however you wish with some SWIG-fu(you can define typemaps which tell how to map types), but in this case, i didn't think it was worth it for a single function.
As for the "reserve", I agree, it's such an easy and harmless optimization that there's no excuse not to do it here, aside from that, this code is going to talk to Python , besides, we're constructing an extra vector<string> in the first place, and I don't think it's at all possible to avoid that, since most of the target languages keep their strings as unicode, and worse, they're not even null-terminated.
In general, I really ignore most performance considerations while writing language bindings, since the activity is excessively wasteful to begin with.
Well, I'm probably not as comfortable with the orx codebase as you are, so whenever I see a platform-specific #define I'm afraid that it'll cause SWIG to emit different wrappers on each platform. Besides, I'd prefer to have complete control over how SWIG wraps, say, orxFLOAT, so that the wrappers work correctly and similarly on each platform.
I see, I guess Windows.i would be essential in a codebase that has declspecs and such all around the codebase, but thanks to your consistent use of macros, we should be able to avoid that problem without it. As I said, I'd prefer to stay away from anything that implies a platform dependency, so a "#define orxFASTCALL // empty" feels much more innocent since we know it'll work the same way on all platforms.
Ah, case in point, if those are private functions, what's the officially recommended way of using the config module in isolation? I've discovered that you need to call the following first:
I definitely agree, I hate it when I unnecessarily complicate things . As Einstein said “A clever person solves a problem. A wise person avoids it.”(Conclusion: I'm definitely not wise). We could even manually upload the cross-platform binding packages for chosen releases, no need to complicate the build setup.
Great, I'll set it up as soon as possible.
I guess it depends on which kind of unicode encoding they're using. If it's Go, for example, it'd be UTF-8, which is also what orx is using internally. I do not know what other languages use.
You could avoid the internal heap allocation altogether by using a stack-allocation for storing the pointers before sending the list to orx.
"death by thousand paper cuts"
I understand and it's totally fine with me to do a cherry-picking approach, I was just trying to learn more about SWIG and its limitations, it's really a brand new world to me.
Excellent, let's start with this approach then. We can always iterate and improve it over time, of course.
I hope you like SWIG. As a C/C++ lover, SWIG has enabled me to use C++ under circumstances that would make it impossible to use C++ otherwise. In today's IT world, I think SWIG gives superpowers to a C++ programmer. In my experience, the best way to approach SWIG is to focus on what it can do, rather than what it can't. It almost always does the most dangerous and ugly bits automagically, while you can find clever solutions to fill in the gaps.
How would you like to proceed? I can create a pull request for an initial version that only wraps the config module (as that's what the current potential users, me included, need.). We could try to get the build setup going with that. We can wrap the rest of the orx headers over time. CAUTION, AMBITIOUS DREAM AHEAD: One day, we could even package orx with a Python interpreter, along with the wrappers and build a cross-platform python environment to develop mobile games! That would be very much appreciated in the Python community. end of AMBITIOUS DREAM.
How would like the code to be organised? I can put all the SWIG stuff under code/build/bindings. I can create a cross-platform CMake build setup to generate and compile the bindings, CMake + SWIG works well.
What branch would you like to keep these in?
About the build slave; I've tried to set it up as a system service, so it should be up as long as my dev machine is on (and that would be the case on most week days), but as a Mac noob, there's a good chance that I didn't set it up correctly, so could you confirm that it's working?
I've heard very good things on SWIG for quite some time now, I just never got into it as my favourite high-level scripting language isn't supported: Rebol.
A pull request on a new branch, named, say, SWIG, sounds good to me. /code/build/bindings sounds like a good place as well. We'll merge everything back in the default branch when it's stable.
Do we really need CMake? What tasks will it run precisely? If it's the SWIG command line invocation, I believe that can be handled directly in buildbot or through a python script (I'm just trying to avoid adding new dependencies on the slaves unless they're mandatory ).
Your slave is up and running, you can see its status here:
I'll try to update to 10.10 locally and see if I can get the newer version of xcode to run on my old macbook in the coming days.
I had never heard about Rebol before, I've checked it a bit and it definitely seems interesting. However, it also seems very similar to LISP, why do you prefer it over LISP? Is it because Rebol has an interpreter more suitable for embedding?
I'm a bit confused at this point, I think this paragraph is in conflict with our previous agreement of including the SWIG generated wrappers in the repository. In that case, the slaves wouldn't need to call SWIG anyway, so the slaves wouldn't even depend on SWIG. In any case, I can easily drop cmake for this setup. It would probably create more problems than it solves.
I think I've fixed my slave. As I said, I'm a noob at mac, and I wasn't very successful at setting the slave up as a system service running as an isolated user. Now I've fixed it, so the slave should be up whenever my computer is on.
By the way, fixing the slave was harder since I had to wait for the build to be triggered by some means. Is there any way I can trigger a build the next time I need to fix anything? If so, I could attempt to fix the iOS build myself.
It's actually much higher level and simpler than LISP. For example, the source of the "read" function can be a file as well as an URL or even a block/object. It makes writing scripts very easy and fast, no matter which resources one is handling.
It supports file path, URLs, dates, etc... as first citizens.
But it does have some strong similarities with LISP, such as the homoiconicity property (ie. data and code are stored in the same way).
There's now some work done by the Rebol community on Red, a Rebol-based language suited for both low and high level development. The language is still in its infancy:http://www.red-lang.org/p/about.html
- When a .h file is modified and/or the .i files are
- Buildbot will trigger a "SWIG" build on one of the capable slaves
- This build would create the new wrappers by calling SWIG
- And it would then commit/push the wrapper changes to the repository
Does it sound reasonable? How would you see the whole process?
Ah, thanks! Regaarding the build triggering, yes, there's a way to do it, I'll send you the credentials by PM. Once logged with them on the master, you can request new builds.
You've definitely put Rebol and Red on my radar, though I have my sights set on Haskell these days. Incidentally, Haskell also suffers from a lack of SWIG support, though that's probably because object-oriented imperative programming is so alien to Haskell.
That's great, I initially thought we'd manually commit the wrappers, but that's better. For now, I'll focus on generating complete bindings and writing some tests/examples for them.