that sorta behaves like our controllers in java. I might be able to make
this better.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4161 542714f4-19e9-0310-aa3c-eee0fc999fb1
The basic whirled stuff is here; compiling and working.
'Spot' still to come.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4133 542714f4-19e9-0310-aa3c-eee0fc999fb1
package, use those. The ResourceBundle stuff is not quite working now due
to bugs in beta3, but I'll loop back to it later.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4126 542714f4-19e9-0310-aa3c-eee0fc999fb1
- Track the size of non-simple keys separately so that we really know when
to resize the map.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4121 542714f4-19e9-0310-aa3c-eee0fc999fb1
- Renamed HashMap Hashtable, because I wanted a version without ties to
mx.* code. User-defined hashing functions may be specified.
- Created a subclass of Hashtable called HashMap which uses
functions in mx.utils.ObjectUtil to hash non-Hashable complex keys.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4120 542714f4-19e9-0310-aa3c-eee0fc999fb1
Internally, three different things may be done for storage:
- Simple keys can utilize the Dictionary class, we just use one of those
inside the map.
- If the key implements Hashable, we can hash it.
- Otherwise, use mx.utils.ObjectUtil to generate a hash for any other key and
also to compare the keys. Keys are then wrapped in a KeyWrapper object
that implements Hashable. This last case will also handle null as a key.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4117 542714f4-19e9-0310-aa3c-eee0fc999fb1
of the output.
Update code to recognize the new format and stop working around the old bugs.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4108 542714f4-19e9-0310-aa3c-eee0fc999fb1
InvocationRegistration had a constructor called Registration. I wonder if
that was causing the compile error with beta2.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4104 542714f4-19e9-0310-aa3c-eee0fc999fb1
"Still purple and bruised, sir!"
I'm working around more bugs. In theory everything should log in and join
the chat room, but the browser crashes- every single time.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3986 542714f4-19e9-0310-aa3c-eee0fc999fb1
Boy, fun.
I guess I'm embracing the 'adapter' construct for emulating anonymous
classes, but I wish I wasn't.
I have half an idea to start over from scratch and write a very
actionscripty dobj/services/receiver system that ends up looking very
different on the client but still speaks to the server in the same way.
Probably things would just get more and more complex until I was back here.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3983 542714f4-19e9-0310-aa3c-eee0fc999fb1
Use Long instead of long. I had them both (it may be useful so that we
know if we're streaming an object or just 8 bytes of value) but Windows
couldn't fucking tell them apart (case insensitivity) so I nixed one.
Reference some more marshallers in the client so that the classes will
be compiled in.. gawd.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3977 542714f4-19e9-0310-aa3c-eee0fc999fb1
I'm now pounding my head against new limitations that I'd not seen before, now
that the Client class that I'm using is not in the presents.client package.
Macromedia can go fuck themselves with a hot poker.
The .swf is already 200k and I've barely begun working on UI elements.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3972 542714f4-19e9-0310-aa3c-eee0fc999fb1
Ray Greenwell