1  |   Order by index

Nov 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

Nov 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]

Nov 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

Nov 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

Nov 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

Nov 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

1  |   Order by index