writing in the code generated by GenActionScriptStreamableTask.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6199 542714f4-19e9-0310-aa3c-eee0fc999fb1
If it's public, we try to shadow it in a subclass & wind up still
getting THIS one.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6083 542714f4-19e9-0310-aa3c-eee0fc999fb1
The purpose is to
- Ensure type checking for "fail-fast" detection of streaming errors.
- But simplify it so that callers don't have to cast themselves and
potentially screw up by using "String(obj)" or "Array(obj)", or miss out
on the fail-fastyness by using "obj as SomeType".
- But, at the same time, allow for the sveltest code possible.
// first one is a bit shorter!
_name = ins.readObject(Name);
_name = Name(ins.readObject());
// first one is a bit shorter!
_state = ins.readObject(String);
_state = ins.readObject() as String;
So, to sum up: the code is the shortest and doesn't require special-casing
if you are reading a String, Number, int, uint, Boolean, or Array.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5984 542714f4-19e9-0310-aa3c-eee0fc999fb1
Unless I have to roll this back because the like compiler in CS3
shits its pants trying to understand it (external references for
default parameter values seem to sometimes fail).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5969 542714f4-19e9-0310-aa3c-eee0fc999fb1
Note that we're using ints instead of units for offset/length.
Does anyone really need a byte array larger than 2^31?
And if so, wouldn't you then also be within sight of busting 2^32?
Why not make it a Number and support up to 2^53?
Number is no guarantee of a desire for a floating-point value in
the flash libraries, see Graphics.lineStyle()'s first parameter.
Actionscript, you fail for not having long.
And... I said I wasn't going to bitch at Adobe/Macromedia any more
but this is a total FAIL.
0 is a valid length. Everyone knows this.
Can you imagine if they picked a different constant?
length: the number of bytes to read, unless it's 9, in which case
it reads *all* the bytes. Your code should check to see if you're
about to read 9 bytes, and instead read 8 in one go and then
a follow-on byte.
uint.MAX_VALUE would have made tons more sense.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5968 542714f4-19e9-0310-aa3c-eee0fc999fb1
the Array length is 0, so let's make sure we don't cause any
streaming errors here.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5966 542714f4-19e9-0310-aa3c-eee0fc999fb1
streaming to our java server, so let's just make them streamable directly.
Does away with the need for custom Streamers.
Also made them Hashable, in case we read a StreamableHashMap containing
Integers as keys, for example.
Less code is better code.
(Why was BooleanStreamer added the other day? langBoolean was already Streamable
and was already in Translations)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5960 542714f4-19e9-0310-aa3c-eee0fc999fb1
Use String concatination in others (it's faster in actionscript than in Java)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5959 542714f4-19e9-0310-aa3c-eee0fc999fb1
The old HashMap class was a frankenstein one-size-fits-all mess of:
- storing simple objects
- storing Hashables
- having the capability to provide external functions to hash and check
equality of any other type of key.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5927 542714f4-19e9-0310-aa3c-eee0fc999fb1
support streaming them as bytes.
It's better than writing a modified UTF String, but
it'd be even nicer if we could avoid the short to read the class name
(Enums are final), but I suppose we still have to know whether one is null
or not. Hm.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5920 542714f4-19e9-0310-aa3c-eee0fc999fb1
including some implicit coercian to a Boolean, which can actually
be quite dangerous... but only with Strings and Numbers and whatnot.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5907 542714f4-19e9-0310-aa3c-eee0fc999fb1
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