unitsync java/python bindings kaput, r7068

[Tobi]

Modified: trunk/tools/unitsync/javabind.cpp
===================================================================
--- trunk/tools/unitsync/javabind.cpp 2008-11-18 19:20:23 UTC (rev 7067)
+++ trunk/tools/unitsync/javabind.cpp 2008-11-18 20:22:31 UTC (rev 7068)
@@ -26,7 +26,6 @@

DLL_EXPORT const char* __stdcall GetSpringVersion();
DLL_EXPORT void __stdcall Message(const char* p_szMessage);
-DLL_EXPORT int __stdcall Init(bool isServer, int id);
DLL_EXPORT void __stdcall UnInit();
DLL_EXPORT int __stdcall ProcessUnits(void);
DLL_EXPORT int __stdcall ProcessUnitsNoChecksum(void);
@@ -170,7 +169,7 @@
*/
JNIEXPORT jint JNICALL Java_aflobby_CUnitSyncJNIBindings_Init
(JNIEnv *env, jclass myobject, jboolean isServer, jint id){
- return Init(isServer,id);
+ return 1;
}

/*

Modified: trunk/tools/unitsync/pybind.cpp
===================================================================
--- trunk/tools/unitsync/pybind.cpp 2008-11-18 19:20:23 UTC (rev 7067)
+++ trunk/tools/unitsync/pybind.cpp 2008-11-18 20:22:31 UTC (rev 7068)
@@ -22,7 +22,6 @@

DLL_EXPORT const char* __stdcall GetSpringVersion();
DLL_EXPORT void __stdcall Message(const char* p_szMessage);
-DLL_EXPORT int __stdcall Init(bool isServer, int id);
DLL_EXPORT void __stdcall UnInit();
DLL_EXPORT int __stdcall ProcessUnits(void);
DLL_EXPORT int __stdcall ProcessUnitsNoChecksum(void);
@@ -94,7 +93,7 @@
int id;
if (!PyArg_ParseTuple(args, "ii", &isServer, &id))
return NULL;
- return Py_BuildValue("i", Init(isServer, id));
+ return Py_BuildValue("i", 1);
}

It's nice this made it compile again, but it silently breaks Java and Python bindings.

I'd rather have you just removed the bindings altogether then (or comment them out or so)

Now it's way to easy to not notice and/or forget about it and end up releasing java/python bindings in which Init is a no-op... (which even returns success..)

[AF]

If someone could generate a JNA class for unitsync then you could remove the java bindings. Someone talked about an AWK script for this IIRC.

[hoijui]

yeah, i will do that as soon as i changed trunk to use EXPORT().

[aegis]

I use the python bindings, but if I figured out how to replicate some of the more complicated structs, I could do the wrapper entirely in python.

[hoijui]

..i am currently doing the change from DLL_EXPORT ... __stdcall tp EXPORT(...).
aegis, you may have to rework some script that parses the pybind.cpp
is anyone else using pybind? springlobby maybe?

[Tobi]

No, as far as I know it was only used by older lobbies that are dead by now: omni, UnityLobby...

[hoijui]

ok, thanks

[imbaczek]

actually i had no idea what the proper fix would be legacy projects will still call Init, so i wanted to keep compatibility without breaking anything. didn't work but at least somebody cared

[hoijui]

Hey AF, this is the JNA wrapp stuff for unitsync.
It generates everything needed and compiles fine here.
have a look at the README.

Will you integrate it into the source under trunk somehow?

it was a fast job, so just ask if something is unclear.

[Tobi]

actually i had no idea what the proper fix would be legacy projects will still call Init, so i wanted to keep compatibility without breaking anything. didn't work but at least somebody cared

Heh well now you did neither

But no problem, at least the option of generating bindings comes up again, which is good

I'd +1 on generating both java and python bindings (possibly as part of build system).

[hoijui]

yeah... big parts of hte Java and the C# interface will also be generated with AWK, so i think it would be good to include it with mingwlibs and vclibs (its a single exe, about 500KB). it is usually installed on unix already.
aegis.. maybe we can have a talk about how you want the pybingdings, or you can adapt the awk scripts for Java yourself.

[imbaczek]

I'd +1 on generating both java and python bindings (possibly as part of build system).

at least for python, no bindings should be required, since as of python 2.5 it has FFI via ctypes. i'm actually +0 on dropping pybind.cpp. as for java, i find it hard to imagine it doesn't have something similar.

[Tobi]

There's always SWIG, if the platform itself doesn't have anything to generate bindings / do binding at runtime.

[hoijui]

well.. java does not have it built in.
but with JNA (3rd party open source lib), it is possible to call native libs from within Java without writing any native code.
still, of course you need some java code that relates to the native code you want to call. simplest possible thing:
you need a class in java that has functions wiht the same name and number and type of arguments like the native functions yo uwant to call. exactly that is what my AWK script generates:
a Java class that uses JNA to call to unitsync.
I am sure, something similar is needed for phyton.
Generating this with a script, saves us adjusting this part manually every time the unitsync API changes. We then just have to re-execute the script.

[bibim]

There's always SWIG, if the platform itself doesn't have anything to generate bindings / do binding at runtime.

Yeah, I've been using SWIG for Perl unitsync bindings for about 1 year now. Didn't get any problem.

[hoijui]

maybe we should standardize unitsync wrappers, eg this way:
tools/unitsync/wrappers/Java
tools/unitsync/wrappers/Python
tools/unitsync/wrappers/Perl

and what about renaming unitsync now? :D
ideas:
Spring-Interface
Spring-Meta-Interface
Spring-Data-Interface
Spring-Inspector-Interface
Spring-Lobby-Interface
or Callback instead of Iinterface? (i would say no)

[Auswaschbar]

I now get spammed by warnings:

/home/karl/spring/trunk/tools/unitsync/unitsync.cpp:2765: Warnung: Attribut »stdcall« wird ignoriert

edit: nevermind, fixed it myself

[aegis]

I'd +1 on generating both java and python bindings (possibly as part of build system).

at least for python, no bindings should be required, since as of python 2.5 it has FFI via ctypes. i'm actually +0 on dropping pybind.cpp. as for java, i find it hard to imagine it doesn't have something similar.

I was writing ctypes bindings but I couldn't figure out one of the structs.

[hoijui]

Auswaschbar, this is no fix, its just preventing the warnings, but it does not force stdcall anymore, which is not acceptable.
I am using gcc 4.2, where it perfectly works as it was before. Agon told me, he gets the same warnings you got, and he has 4.3, so i guess you too. As i do not want to install 4.3, i can not find the solution with try and error. Any help? Do you know how to do it Tobi?

aegis:
your problem wiht the structures is what?
I found a Python ctypes tutorial here:
http://www.python.org/doc/2.5.2/lib/cty ... nions.html
It should not be hard to adjust the awk script for i supplied a few posts ago to create ctypes bindings.
The only stucts are MapInfo and StartPos. They are in unitsync.h whereas the ret is in unitsync_api.h.
The scripts wrapp exactly these two things. the script for unitsync.h creates two files, one for StartPos and one for MapInfo, and the one for unitsyn_api.h creates one file containing all the functions.

[hoijui]

what it looks like now, for al GCC versions:

extern "C" __attribute__ ((visibility("default"))) int __attribute__ ((stdcall)) doSomething();

this gives no warning in 4.2, but does so in 4.3. So far, I assumed it works in 4.2, as there was no warning, but it may not.
if anyone knows how it should be, please help me. :D
possibly:

extern "C" __attribute__ ((visibility("default"))) int __attribute__ ((__stdcall)) doSomething();
extern "C" __attribute__ ((visibility("default"))) int __attribute__ ((__stdcall__)) doSomething();
extern "C" __attribute__ ((visibility("default"))) int __stdcall doSomething();