(ByteArray is a special class for dealing with bytes. It does not extend
the normal Array).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4452 542714f4-19e9-0310-aa3c-eee0fc999fb1
the client with the proper source oid. Normally this happens when the client's
event is received over the network but in local mode events never go over the
network and thus all appear to have originated on the "server".
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4435 542714f4-19e9-0310-aa3c-eee0fc999fb1
an arbitrary Java class which we are converting to ActionScript (the language,
not the class). Hopefully this will appease the compiler.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4419 542714f4-19e9-0310-aa3c-eee0fc999fb1
aren't magically in scope for ActionScript, we have to generate import
statements for them.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4414 542714f4-19e9-0310-aa3c-eee0fc999fb1
when we encounter the pattern "new SomeClass[0]". Le whee!
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4410 542714f4-19e9-0310-aa3c-eee0fc999fb1
field/method names for the ActionScript version of a class (or to omit
something entirely). This removes the need for special case hackery for
toStringBuilder().
In order for annotations to work, however, we have to require that the
GenActionScriptTask be loaded from the same classloader that loads the classes
to be reflected upon. Before we only reflected on the target classes, never
instantiated them. Annotations are actually instantiated, so we have to be able
to create an instance of the ActionScript.class that is compiled into our
target classes and assign it to a reference that is compiled into
GenActionScriptTask. Beware the complexities of dealing with multiple class
loaders.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4405 542714f4-19e9-0310-aa3c-eee0fc999fb1
because we can't do that in ActionScript; properly handle static var and
non-static const.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4404 542714f4-19e9-0310-aa3c-eee0fc999fb1
interfaces, and Marshallers for same. The remaining snag has to do with the
annoyance of ActionScript not supporting inner classes, which means that
ChatService.TellListener for example has to become ChatService_TellListener.
The code for generating the Java marshaller knows to add an import for
ChatService if some random invocation service interface happens to reference
ChatService.TellListener, but now it needs to be made to know to add an import
for ChatService_TellListener in ActionScript land and it has to do it in a way
that doesn't fuck up the Java code generation. Whee!
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4397 542714f4-19e9-0310-aa3c-eee0fc999fb1
Java. Of course this is a very limited translation facility that is mainly
focused on auto-generating Streamable ActionScript classes from their Java
originals, and it doesn't actually convert method bodies, just field and method
declarations, initial values, and such.
Most of our Streamable classes don't have much in the way of real methods, and
the autogenerator will stick new methods in when they show up on the Java side
so at least we'll *know* that they need to be implemented. And the main thing:
readObject and writeObject are in fact implemented by the code generator so at
least we won't be plagued by annoying streaming errors when we change something
on the Java side and forget to change the ActionScript side.
Next up, auto-generating InvocationService interfaces and InvocationMarshaller
implementations in ActionScript and ActionScript versions of DObjects.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4394 542714f4-19e9-0310-aa3c-eee0fc999fb1
checkin, tihs will be a non-issue when we start devoting an entire separate JVM
to each game (which we will have to do for all games that run server code)
because then all a game can do is stick a fork in its own JVM and render itself
unplayable.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4388 542714f4-19e9-0310-aa3c-eee0fc999fb1
stick a fork in the server otherwise malicious or broken code can generate an
AbstractMethodError or some other error and cause the server to decide to quit.
It may still be possible for malicious code to throw an OutOfMemory error, and
if that's the case then I don't know what we can do to both gracefully get the
fuck out of dodge when things are pear shaped and avoid the wrath of the
kiddies.
Incidentally, it was stupidity, not malice that brought this to my awareness.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4387 542714f4-19e9-0310-aa3c-eee0fc999fb1
unmarshalled into an ArrayList on the receiver. Along the way, I improved
support for generic types as arguments to invocation services (which required
one unfortunate "sweeping" warning suppression, but since this is in generated
code, I think we can be sure it won't be doing anything untoward).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4375 542714f4-19e9-0310-aa3c-eee0fc999fb1
process and keep that information around in case the server ever wants to know.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4356 542714f4-19e9-0310-aa3c-eee0fc999fb1
This is actually kind of sketchy, because the resolver can't depend on it
because there are methods to resolve a client object without having an
authenticated connection.
For now, I'll leave this in.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4350 542714f4-19e9-0310-aa3c-eee0fc999fb1
looking for something assignable from Object (rather than the other
way around) when the argument was null.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4346 542714f4-19e9-0310-aa3c-eee0fc999fb1
like Groovy and JRuby. Created a DynamicEventDispatcher that automatically maps
attribute, element and set events to methods. Say you have a field:
public DSet occupantInfo;
you can create a method in any class:
public void occupantInfoAdded (BodyObject source, OccupantInfo entry);
and then bind that class as a listener using the dynamic event dispatcher:
_myobj.addListener(new DynamicEventDispatcher(object));
I also created a nicer replacement for the MessageHandler system which is
clunky but still way simpler than using a full InvocationService. Basically we
dispatch MessageEvent as if it were a method call.
For example, in AtlantiManager I define:
public void placeTile (BodyObject placer, AtlantiTile tile)
which receives a request by a player to place a tile on their turn. Then in
AtlantiController, I simply call:
_atlobj.manager.invoke("placeTile", tile);
Of course, in JRuby and Groovy, that's going to look like:
_atlobj.manager.placeTile(tile);
which is all part of the fun.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4344 542714f4-19e9-0310-aa3c-eee0fc999fb1
distributed objects by reflection since we don't allow clients to create
objects, furthermore we needn't do it asynchronously. The object creation
methods were moved into the server-side only interface and made "immediate", so
the caller creates a derived instance of DObject and registers it with the
system instead of creating it with a Subscriber callback.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4342 542714f4-19e9-0310-aa3c-eee0fc999fb1
We need to set up the preference interval (but not start it) before we try to open the connection. Otherwise, we won't have it around if we get a shutdown call during that opening (which can and does happen).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4274 542714f4-19e9-0310-aa3c-eee0fc999fb1
where we don't think it ever will.
Instead of returning null, or the exception, always throw a runtime
with just the CloneNotSupportedException as the argument, as this will
contain the most information and will preserve the stack trace.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4264 542714f4-19e9-0310-aa3c-eee0fc999fb1
inner bits are all clear and ready to try logging on to a new server. We
specifically wait to call clientLogonFailed() until after everything is
cleared, but I don't want to change the behavior of clientDidLogoff() for fear
that any one of the zillion directors depends on something being around during
that call.
Instead I added another callback clientDidClear() that is called when a
successful session is fulled cleared out (basically when we're not calling
clientLogonFailed()) so that entities that are waiting for a logoff to finish
so that they can logon somewhere else have a clean way of doing so.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4255 542714f4-19e9-0310-aa3c-eee0fc999fb1
Ray Greenwell