is known by any invocation marshaller, and so the client does
not need to be passed in.
Just here on the actionscript side for now, but this change may
make its way to Java.
Other changes may follow...
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5904 542714f4-19e9-0310-aa3c-eee0fc999fb1
Jeez, this whole thing could *almost* go away if we moved to flash 10
and used Vector, but of course, there's no way to get the type of
Vector. Maybe there is, with describeType(). Can't experiment now.
I'd fall out of my chair if there were.
We need to know in case sending an empty array to the server,
it's still gotta be the right type (with non-empty we could
try examining the first element).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5742 542714f4-19e9-0310-aa3c-eee0fc999fb1
reviewing some of the first code written in it might be a good idea.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5741 542714f4-19e9-0310-aa3c-eee0fc999fb1
Have the FrameReader stop listening on the socket when we're done with it.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5707 542714f4-19e9-0310-aa3c-eee0fc999fb1
plainly. Actionscript prevents us from reliably using them.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5619 542714f4-19e9-0310-aa3c-eee0fc999fb1
- Sliiiiightly less efficient in a few cases.
- But: looking typed arrays up by class didn't work anyway,
there was some duplicated code in jname and class lookup,
and the jname thing handles Lists from the server. So
overall I think this is a win.
Less code is better code.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5610 542714f4-19e9-0310-aa3c-eee0fc999fb1
- Register Long.
(I could probably sweep through narya and re-jigger a bunch of
the actionscript code that was written while I was learning the
language.)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5609 542714f4-19e9-0310-aa3c-eee0fc999fb1
This was a bit of a rabbit hole and took longer than expected,
and I had a stupid bug that took a while to find,
but in the end there are way more lines of code removed than
added, so I'll call it a win. Streamer lookup is now via a Dictionary.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5608 542714f4-19e9-0310-aa3c-eee0fc999fb1
Thane apparently has a maximum stack depth of 64, and this is quickly getting eaten up by readAvailable() when lots of frames are sent down the tubes simultaneously. (mxmlc doesn't seem to optimize tail-recursive functions.)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5360 542714f4-19e9-0310-aa3c-eee0fc999fb1
- Before, the Input/OutputStream classes handled Streamables directly
and Streamers were never created for them. Simplified the code somewhat
by always creating a Streamer. It's now more like the Java side, too.
- No more BAD_STREAMER, since null now means "bad".
- Built-in support for streaming enums.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5352 542714f4-19e9-0310-aa3c-eee0fc999fb1
Zyraxxis to hork.
Deep within our streaming code, ArrayMask objects were being created with
zero length when streaming non-final arrays with a zero length. This tickled
a "feature" of Adobe's IDataInput code, which reads *all available bytes*
if you pass readBytes() a length of 0.
What's really annoying is that this worked fine if you were notified
of the zero-length array via a PropertySetEvent, because that event
would come in on its own frame and so if the array's length was zero then
there were no more bytes to read. But if you entered a game and had
to receive all the usercode properties at once, it booched.
There are clumps of my pulled-out hair all around my desk from that.
And: this is ultimately my own fault, as my old code didn't handle the
case of the passed-in ByteArray having 0 length.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4900 542714f4-19e9-0310-aa3c-eee0fc999fb1
Putting you at the top level screws up use of another Log class.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4874 542714f4-19e9-0310-aa3c-eee0fc999fb1
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
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
Use it in SimpleStreamableObject's toString(), with some new formatting.
Unfortunately, the order of public variables seems random.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4746 542714f4-19e9-0310-aa3c-eee0fc999fb1
for element types other than String.
- Changed streamer init to prevent the above change from triggering
a re-init when the delegate is looked-up.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4568 542714f4-19e9-0310-aa3c-eee0fc999fb1
I was looking up streamers by java name, but passing in the actionscript
name. This was only affecting Object[]'s containing String elements
due to the addition of String to Translations.
Previously, 'java.lang.String' wasn't getting translated into the
actionscript equivalent, so it just worked. Two bugs can cancel each other out.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4567 542714f4-19e9-0310-aa3c-eee0fc999fb1
that we don't try to access array element .125 at runtime.
The designers of flash need to be suspended over a tank of sharks while
people try to write a program in actionscript to reel them in. I bet half
the time it compiles into something that just lets those ropes go.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4334 542714f4-19e9-0310-aa3c-eee0fc999fb1
compiler never wanted to tell me about.
- I was trying to store read values into the streamer itself, referecing
it as "this[ii]". This turns out to be legal, even though the class is
sealed, because you can access public fields using the [] operator with
a string argument. At runtime, ii == 0, it got Stringdafied to "0" and
then a field called "0" was looked up on the class and oh no, it didn't
exist.
- Worse, I had a line that referenced "length" instead of "arr.length".
There is no length defined in the class, nor is there one in the superclass.
It turns out the base class Object has an undocumented constant called
length that seems to always be 0. Isn't that special?
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4333 542714f4-19e9-0310-aa3c-eee0fc999fb1
Ray Greenwell