Wrappers and AIs
-
- Spring Developer
- Posts: 1254
- Joined: 24 Jun 2007, 08:34
Wrappers and AIs
Because the merge of the caiinterface branch is near, I would like to know how we should handle the bindings (wrappers). Right now, hoijui has a C, a C++ and a 2 Java-bindings.
Now Agon has asked to merge his mono-wrapper. The question is, should we include all wrappers in the main repo?
I could basically think of 2 possibilities:
1. Include them all in spring-repo
pro: easy to do
con: repo will grow, the amount of wrappers might grow, need to merge every change from the forks
2. Submodules (git submodule)
pro: maintainers have full control over their submodule, spring repo will not grow because they are modular and optional
con: never done before, not as easy as 1
Some git submodule tutorial, to see how it works: http://git.or.cz/gitwiki/GitSubmoduleTutorial
Opinions? I would favour trying 2 first, we can still mergethem in the repo later
edit: bibim said I got something wrong, now waiting for him to make a diagramm to explain.
Now Agon has asked to merge his mono-wrapper. The question is, should we include all wrappers in the main repo?
I could basically think of 2 possibilities:
1. Include them all in spring-repo
pro: easy to do
con: repo will grow, the amount of wrappers might grow, need to merge every change from the forks
2. Submodules (git submodule)
pro: maintainers have full control over their submodule, spring repo will not grow because they are modular and optional
con: never done before, not as easy as 1
Some git submodule tutorial, to see how it works: http://git.or.cz/gitwiki/GitSubmoduleTutorial
Opinions? I would favour trying 2 first, we can still mergethem in the repo later
edit: bibim said I got something wrong, now waiting for him to make a diagramm to explain.
Re: Wrappers and AIs
i am currently assembling a diagram to explain the code sturcture of the new C Interface. i suggest you all wait till you saw it, before thinking about this.
eta: very soon
no really, should come today
eta: very soon
no really, should come today
Re: Wrappers and AIs
I'm not sure the increase in repo size is big enough to be noticeable. I'm not against trying submodules, but I'm +1 for inclusion in the engine repo anyway (as long as build is optional so I don't have to download epic amounts of dependencies.)
Re: Wrappers and AIs
Here it is!
C 26KB
Java 207KB + 1.5MB Java libs (*.jar files)
+1 for direct inclusion in main repo
An alternative Idea
We could try submodules for upcomming new AIs. Expecially non native AIs (eg. Java or Mono AIs) would be well suitet for this. Code-Wise, they will genereally be very loosly coupled to the engine. For example in the case of Java, they only need AIInterface.jar from the Java AI Interface.
This way, we would aquire practical knowledge about git submodules, and if we see that it would work well with interfaces aswell, we could still put them into such modules later.
An other thing to consider is, that small maintainance work on the interfaces can be done by all spriong devs, if they are in the mian repo, whereas we would have to rely on one or a few maintainers per AI Interface otherwise.
Edit:
for more diagramms concerning the workings of the itnerface, see:
viewtopic.php?p=328843#p328843
Repo size of the Interfaces:C 26KB
Java 207KB + 1.5MB Java libs (*.jar files)
+1 for direct inclusion in main repo
An alternative Idea
We could try submodules for upcomming new AIs. Expecially non native AIs (eg. Java or Mono AIs) would be well suitet for this. Code-Wise, they will genereally be very loosly coupled to the engine. For example in the case of Java, they only need AIInterface.jar from the Java AI Interface.
This way, we would aquire practical knowledge about git submodules, and if we see that it would work well with interfaces aswell, we could still put them into such modules later.
An other thing to consider is, that small maintainance work on the interfaces can be done by all spriong devs, if they are in the mian repo, whereas we would have to rely on one or a few maintainers per AI Interface otherwise.
Edit:
for more diagramms concerning the workings of the itnerface, see:
viewtopic.php?p=328843#p328843
Re: Wrappers and AIs
btw I'm -1 for having jars under version control.
-
- Spring Developer
- Posts: 1254
- Joined: 24 Jun 2007, 08:34
Re: Wrappers and AIs
1.5 mb seems a bit larg'ish, despite the fact there are ubuntu packages for it (also debian / gentoo, rpm's seems missing)
Re: Wrappers and AIs
As discussed with Agon and Auswaschbar, the java libs will be moved to mingwlibs on windows, and i will write SCons and CMake find scripts to find them under POSIX. For this to work, i will need all possible paths (including filenames) to the *.jar 's from libjna and libvecmath when installed with your package manager, plus the .so from libjna.
so please donate some!
on Ubuntu it is:
i hope to be able to use regex to find them, so the version does not matter.
so please donate some!
on Ubuntu it is:
Code: Select all
/usr/share/java/vecmath1.2-1.14.jar
/usr/share/java/jna-3.0.4.jar
/usr/lib/jni/libjnidispatch.so
-
- Spring Developer
- Posts: 1254
- Joined: 24 Jun 2007, 08:34
Re: Wrappers and AIs
Gentoo:
/usr/share/vecmath/lib/vecmath.jar
No jna because gcc was not built with libffi.
/usr/share/vecmath/lib/vecmath.jar
No jna because gcc was not built with libffi.
Re: Wrappers and AIs
those paths should be configurable, preferably during runtime, perhaps by an environment variable or a simple spring config var.
Re: Wrappers and AIs
On thing I can't quite figure out. What is the bottom right box labeled AI/Interfaces/Java/..., that is autogenerated?
Re: Wrappers and AIs
yes, it is auto generated (AWK scripts parsing the C interface and one of the generated .java files). They create a bunch of other .java files that create an OO layer over the basic Java wrapper.
The C interface uses a lot of IDs (unitId, groupId, weaponId, unitDefId, ...) plus, it has a flat hirarchy, obviously, as we cant have classes. the basic Java layer works just like that, it is a direct wrapper over the C interface. When you use this layer, you do only Java, and Jav ais OO only, as we know, ubt it just does not feel like OO. It is like a direct Java wrapper of OpenGL. Just one big class with a few hundred functions. The Java OO wrapper changes this: you should not have to use IDs, but you use the Unit, Weapon, UnitDef, etc. classes. Also, the callback, having function pointers like this in C:
looks like this in Java:
And like this in the Java OO wrapper:
The C interface uses a lot of IDs (unitId, groupId, weaponId, unitDefId, ...) plus, it has a flat hirarchy, obviously, as we cant have classes. the basic Java layer works just like that, it is a direct wrapper over the C interface. When you use this layer, you do only Java, and Jav ais OO only, as we know, ubt it just does not feel like OO. It is like a direct Java wrapper of OpenGL. Just one big class with a few hundred functions. The Java OO wrapper changes this: you should not have to use IDs, but you use the Unit, Weapon, UnitDef, etc. classes. Also, the callback, having function pointers like this in C:
Code: Select all
int (CALLING_CONV *Clb_WeaponDef_Shield_getRechargeDelay)(int teamId, int weaponDefId);
Code: Select all
class AICallback {
int Clb_WeaponDef_Shield_getRechargeDelay(int teamId, int weaponDefId);
}
Code: Select all
class OOAICallback {
List<WeaponDef> getWeaponDefs();
}
class WeaponDef {
Shield getShield();
}
class Shield {
int getRechargeDelay();
}