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
runtime. The only way to learn what might be thrown is to read all the
documentation for a method. (Complaint suppressed.)
Anyway, let's cope if we encounter an error reading from our socket.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4292 542714f4-19e9-0310-aa3c-eee0fc999fb1
- Import bleeding may be fixed, as I had to import a bunch of things I
should have had to earlier.
- NOW they make duplicate variable definitions bad (but without block
scoping... yay).
- Another hoopjump.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4233 542714f4-19e9-0310-aa3c-eee0fc999fb1
Tom Conkling