a year since the refactor that inspired leaving this logging in.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3961 542714f4-19e9-0310-aa3c-eee0fc999fb1
We can revert these statements when/if that bug gets fixed.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3960 542714f4-19e9-0310-aa3c-eee0fc999fb1
Setting up a prototype const doesn't work, which is possibly a compiler bug.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3959 542714f4-19e9-0310-aa3c-eee0fc999fb1
(It may be the same thing under the hood, but our pal Occam would approve.)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3958 542714f4-19e9-0310-aa3c-eee0fc999fb1
- There seems to be a compiler bug that causes classes to be
imported spuriously, or something. Classes that import only one of the Log
classes are complaining about visibility of more than one of them.
- static constants are not inherited by subclasses, which is super annoying.
I will try switching to prototype consts, but there seems to be a problem
initializing those, and we don't want to make them vars...
- The fact that there are no inner classes combined with no method overloading
is making things very inconvenient. I've been experimenting with faking
an anonymous class by instantiating a dynamic object and attaching
functions to it, but it's not working. I'll continue experimenting, because
if we can't do this then someone shoot me.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3957 542714f4-19e9-0310-aa3c-eee0fc999fb1
Made ObserverList work with a passed-in function, actionscript style.
I might reconsider some earlier decisions to go away from ObserverList.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3952 542714f4-19e9-0310-aa3c-eee0fc999fb1
Created adapters for invocation services so that I can do inner-class like
things by passing references to private functions out to an external entity.
I will see if it's possible to merge my adapter with the marshallers
because it's still to have multiple wrappy classes.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3944 542714f4-19e9-0310-aa3c-eee0fc999fb1
the screen. In general the first frame is thrown off by the time it takes to
construct the window (which may be substantial) and the second might take a
while laying it out. After that though, we can smoothly slide things onto the
screen, and so we do.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3942 542714f4-19e9-0310-aa3c-eee0fc999fb1
otherwise, everything under it will inherit the "SKIP" mode,
which bypasses the render queues.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3940 542714f4-19e9-0310-aa3c-eee0fc999fb1
than it needs to be.
Broke streaming compatibility in order to be much more efficient over the wire.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3938 542714f4-19e9-0310-aa3c-eee0fc999fb1
Never in my life have I spent so much time debugging so little.
I think the flash player is full of bugs, I've learned to just run
everything two or three times and chase the error that happens the most. Fun!
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3929 542714f4-19e9-0310-aa3c-eee0fc999fb1
our streaming system should work with multidimensional arrays: in fact it
kinda already did, if the element type of the outermost array was something
for which we already had a streamer. Thus, int[][] worked, Object[][] worked,
etc. One small method change and now arbitrary multidimensional arrays
will work.
Why bother? Consistency, and the way I'm working on doing even the int[][]
arrays in actionscript supports unlimited dimensions, so why not?
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3921 542714f4-19e9-0310-aa3c-eee0fc999fb1