a TypedArray of int work if people fill it with strings like "4" or "9".
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4854 542714f4-19e9-0310-aa3c-eee0fc999fb1
DObject. There will never be multiple instances with the same oid that
represent "equal" objects and it's possible that in certain (controlled and
limited) cirumstances, objects with different object managers might have the
same oid even though they are different objects.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4853 542714f4-19e9-0310-aa3c-eee0fc999fb1
(Dictionary supports null keys, so we merely call null a 'simple' key.)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4848 542714f4-19e9-0310-aa3c-eee0fc999fb1
inserts the element just before--not after--the last element.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4845 542714f4-19e9-0310-aa3c-eee0fc999fb1
that EZGame can batch up state change requests which are all invocation service
requests.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4844 542714f4-19e9-0310-aa3c-eee0fc999fb1
superclass chain. Other such annotation "inheritance" is needed for methods,
but that I'll do later.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4840 542714f4-19e9-0310-aa3c-eee0fc999fb1
unit's public API.
handleResult() and handleFailure() could also be protected but we're adapting
Invoker.Unit to something that appears to provide a different (persistence
friendly) public API even though the invoker doesn't actually call it, but
rather the normal Unit public methods call the new public methods. But we still
want to maintain the "feel" of these being the PersistingUnit's "main thing.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4839 542714f4-19e9-0310-aa3c-eee0fc999fb1
ClientCommunicator which does stuff like try to save its preferred connection
port using the Java preference system (which is no longer available to server
processes due to the removal of their home directories).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4836 542714f4-19e9-0310-aa3c-eee0fc999fb1
(which runs on the server) that we do in a normal client (which runs on a
user's computer). Eventually we'll make a custom Communicator for use on the
server that integrates with the ConnectionManager's polled socket I/O which
will be easier now that this bit of factoring has been done.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4835 542714f4-19e9-0310-aa3c-eee0fc999fb1
Also, added logging to the PresentsDObjectMgr to check for this type of thing and dump stack if anyone is trying to register objects anywhere but the DObj thread (assuming we're sufficiently far started up that there is one).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4832 542714f4-19e9-0310-aa3c-eee0fc999fb1
separate thread and racing against other client actions. Also nixed a pointless
type check and cast.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4828 542714f4-19e9-0310-aa3c-eee0fc999fb1
informative (and clean ><)...
While testing the ability to go straight to someone in a game from My Whirled, I was getting
decoding streaming problems (but only sometimes) when fetching the game data. After many hours
of looking for the problem and swearing up and down that it was nothing but consistent, malicious
bitrot, I've tracked it down to this.
In Underwhirled Drift (which is the game I was testing this on), I have a couple of property arrays
that get set when the game is first started up with this:
_control.set(PLAYER_STATE, new Array(numPlayers));
This allows me to fill in the proper indices at a later time in random order. This was working
fine for multi-player games, and after what I've discovered here, I think I can get away with
something simpler, but that can wait for later.
When this was getting encoded, the expected effect would be to encode a TypedArray with a null
in each spot that is defined in the source array (numPlayers long). In fact, it was creating an
empty, zero length TypedArray. I'm not sure why - but that was confusing the system somewhere
along the line so that when that set of bytes was read back from the server on another client
(for instance, when fetching the EZGameObject when trying to join an in-progress game). Of course,
zero-length TypedArrays should go over the wire just fine, so I'm not entirely convinced that I've
tracked down the entire problem (or if that is in fact the issue, then it needs to be addressed).
The diffs here will cause the encoding and decoding to correctly pull nulls out of the array, and
put them in the TypedArray. The moral of this story is to watch out for this construct:
for each (var obj :Object in arr) {
}
...it may not always be doing what you would rightfully expect...
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4827 542714f4-19e9-0310-aa3c-eee0fc999fb1
the dobjmgr thread to relieve the caller of the burden of knowing what thread
they are on.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4826 542714f4-19e9-0310-aa3c-eee0fc999fb1
call didShutdown, so we can't stop listening to it until then.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4824 542714f4-19e9-0310-aa3c-eee0fc999fb1
manager can be collected even if the object lingers about for a while and
because it sets a good example.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4823 542714f4-19e9-0310-aa3c-eee0fc999fb1
being compared with a non-Name but I'm almost certain that never happened and
was just Ray being kooky.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4821 542714f4-19e9-0310-aa3c-eee0fc999fb1
configuration information to other peers so that they all remain in sync.
Also nixed constructor arguments to the peer manager so that it can be created
at server construct time like all other managers and be available for the
twisty maze of inter-registration that takes place during the manager init
process.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4814 542714f4-19e9-0310-aa3c-eee0fc999fb1
them to a single number becomes inconvenient for values larger than an single int, and tricky
when the value is negative (i.e. in two's complement split into two words, with sign bit only
in the high int).
Instead of splitting a long into two ints, we store it internally as a byte array that corresponds
exactly to Java's serialized version (sequence of eight bytes, high byte first), and we provide
accessors to convert to and from Actionscript numbers. This makes Java Long values readable in
Actionscript, and vice versa.
Unfortunately, Actionscript does not have a native 64-bit integer - the closest equivalent is the
Number class. Since this is a double float with a 52-bit mantissa, very large long values will
suffer precision loss during conversion.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4811 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne