ThreadBoard ArchivesSite FeaturesActiveworlds SupportHistoric Archives |
Multiple Instances (Sdk)
Multiple Instances // SdkgeprNov 24, 1998, 9:09pm
Hey guys,
In the "Multiple Instances" section of the docs, the following sentence could be misleading: "All API methods operate on the current instance, which means a multi-instance application must typically call aw_instance_set before any other method in order to indicate which instance the call is for." Since I'm dealing with "objectifying" the SDK, I thought this might imply that one could set different handlers for the same event within the context of different instances. I think I showed that assumption to be wrong with an experiment, though. So, apparently only some API methods refer to a particular instance. aw_event_set isn't one of them. Am I right in this? It seems intuitive that only the bot-relevant methods would be instance specific (e.g. the get/set methods for bools, ints, and strings, when the attributes involved are bot attribs; destroy; enter; login; etc.) It might be good to clarify some of this in the Multi-Instance page for the documentation. For further reference, I *could* put in multiple instance support into Java so that the C SDK only saw one handler for each event, but the Java side would build up a database of handlers and sort through them as necessary. But, this seems pretty ugly to me. Are there any plans to make handlers instance dependent? It would also make multiple bots more efficient if they don't have to crawl through a big switch statement to decide which piece of code to run. (Of course, it's not really more efficient in total because the SDK would just take on that burden; but if we assume the writers of the SDK pay more attention to efficiency than the Bot writers, then we minimize the chance for inefficiency. [grin]) glen -- glen e. p. ropella =><= Hail Eris! the swarm corporation W:(505) 995-0818 <gepr at swarm.com> H:(505) 424-0448 roland vilettNov 25, 1998, 1:06am
Yes that's correct, you can only have a single function installed per
event/callback globally, so aw_event_set() and aw_callback_set() don't operate on a particular instance. I'll try to make that more clear in the docs.... -Roland [View Quote] edward sumerfieldNov 25, 1998, 11:59am
Ahh, a Java object model. Can I get a look?
More comments below. Edward Sumerfield [View Quote] > [snip] > For further reference, I *could* put in multiple instance support into > Java so that the C SDK only saw one handler for each event, but the > Java side would build up a database of handlers and sort through them > as necessary. The word database seems overkill. All you need is an array of { instance, object } that the single installed callback function looks in to work out which object to callback. I wrote a class call Callback and an interface called CallbackAvatarIF. The Callback class has a static method that it tells the SDK to call when an event is generated. It also has a setEvent(instance, CallbackAvatarIF *) methods that allows a robot to install its object as a called back object. Sample using Java syntax (if I remember it right) class Bot implements CallbackAvatarIF { Bot() { Callback::setEvent(instance, this); /* Note that this must be a static class. */ } void avatar_add() { /* Callback function. Called from Callback class */ } void avatar_change() { /* Callback function. Called from Callback class */ } void avatar_delete() { /* Callback function. Called from Callback class */ } } I think this is a very pretty way of routing events to the appropriate object and it is essential for any OO SDK to implement such a strategy. If you do not implement it then the programmer will have to implement their own anyway for every multi-instance bot they create. Think back to the first event model in Java. the "handle_events" method that was called for every object that generated an event from a frame. The case statement that resulted from that was really ugly. My current implementation in the AWCPP is wrong because I didn't make the Callback class static. This will be fixed for the AWCPP 0.4 release. > But, this seems pretty ugly to me. Are there any plans > to make handlers instance dependent? Can't be done in c. so I expect this will take a long time. > [snip] > > glen > -- > glen e. p. ropella =><= Hail Eris! > the swarm corporation W:(505) 995-0818 > <gepr at swarm.com> H:(505) 424-0448 walter knupeNov 25, 1998, 5:06pm
Edward,
Edward Sumerfield schrieb in Nachricht <365C0D30.17FF6C0F at poboxes.com>... >My current implementation in the AWCPP is wrong because I didn't make the >Callback class static. This will be fixed for the AWCPP 0.4 release. Did you manage to accidently pass a non static C++ member function as the call back function and a) the compiler did not complain and b) it worked somehow ? Just curious.... I just remember my early attempts on passing a pointer-to-member as function pointers, which were all blocked by the compiler at first sight. coming from a c background took me a while to figure why it doesn't make sense to even try :) Walter geprNov 26, 1998, 9:46pm
[View Quote]
> Ahh, a Java object model. Can I get a look?
Sure. The most recent working version is at <http://www.swarm.com/aw> in the awjni-blahblahblah file. But, it doesn't have any multi-instance support. I'm only now debating putting it in. Plus it's all really dirty. So, I wouldn't recommend reading it. > The word database seems overkill. All you need is an array of { instance, > object } that the single installed callback function looks in to work out which > object to callback. I tend to use database loosely (to say the least). What I mean here is to provide the SDK with the ability to store and find handler objects. That's basic database functionality. Actually I'm using the JGL, which has things like HashMaps and such. In one of my bots, which I can't distribute because I agreed tothe sdk license, i use a hash set as a database of object signatures acquired from the query handler. They're hashed on 3d space plus object number, which allows me to do real 3d navigation, instead of 2d columns. > I wrote a class call Callback and an interface called CallbackAvatarIF. The > Callback class has a static method that it tells the SDK to call when an event > is generated. It also has a setEvent(instance, CallbackAvatarIF *) methods > that allows a robot to install its object as a called back object. Sample using > Java syntax (if I remember it right) [...] > I think this is a very pretty way of routing events to the appropriate object > and it is essential for any OO SDK to implement such a strategy. If you do not > implement it then the programmer will have to implement their own anyway for > every multi-instance bot they create. This is basically what I did. I provided a set of global procedures for events and callbacks within the library of native C functions. The SDK calls those functions. Inside those functions are references to Java methods contained in Java Objects. I recently changed this so that there's a EventHandler and a CallbackHandler interface. That way you can either create new objects to do the handling or you can just implement the interface with the Bots themselves. Adding a dbase of handler objects will allow me to execute separate pieces of code in response to events and callbacks without the use of switch statements. > > Can't be done in c. so I expect this will take a long time. Yes it can. All that would be required is the administrative overhead required to pay atttention to the current instance during the call to event_set. *If* event_set is called before there is a valid instance, then it could be assumed that the user purposefully wants all the handlers to be the same for all the instances. Or better yet, one could set one generic handler before any bots were created, then for special bots, a special handler could be set for one or more of them as they are instantiated. It would require changes to the event/callback trigger code and the event/callback setup code; but, it can be done. glen -- glen e. p. ropella =><= Hail Eris! the swarm corporation W:(505) 995-0818 <gepr at swarm.com> H:(505) 424-0448 edward sumerfieldNov 29, 1998, 1:31pm
[View Quote]
> Edward,
> > Edward Sumerfield schrieb in Nachricht <365C0D30.17FF6C0F at poboxes.com>... > > Did you manage to accidently pass a non static C++ member function as the > call back function and a) the compiler did not complain and b) it worked > somehow ? No. I use the extern "C" {} method to prevent the callback functions from getting name mangled. So this static/global C function is what is called by the sdk then it manages the searching of the static array of objects by instance number to calls the appropriate method to effect the callback. See the code in Callback.C > Just curious.... I just remember my early attempts on passing a > pointer-to-member as function pointers, which were all blocked by the > compiler at first sight. coming from a c background took me a while to > figure why it doesn't make sense to even try :) You are right the GNU compiler traps this as well. It not conceptually possible once you understand the difference between object instances and static functions. > Walter |