- when parsing set log levels, accept "warn" as an alias for "warning".
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5393 542714f4-19e9-0310-aa3c-eee0fc999fb1
Is that 'private' you see there? Omigod. It is.
Normally we eschew private because we feel like people should be
able to use our classes how they see fit.
However, you *really* shouldn't be futzing with these fields,
and them being protected would allow someone to write an Enum subclass
and fuck-up other unrelated Enum subclasses, so I'm making an exception here.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5365 542714f4-19e9-0310-aa3c-eee0fc999fb1
and so @param tags just match up to parameters based on order.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5364 542714f4-19e9-0310-aa3c-eee0fc999fb1
Rather than copy all the set levels to the level cache when a level is set,
just clear the cache and repopulate it when we look up a level.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5343 542714f4-19e9-0310-aa3c-eee0fc999fb1
Damn actionscript. "for" vs "for each" and each one uses (bla in foo), which
is also a statement in itself. That and the optional semicolons. I bet
the parser for the compiler was fun to write.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5342 542714f4-19e9-0310-aa3c-eee0fc999fb1
create var-args functions or make your existing functions varargs so that
they can react to events.
This might turn into more. I already did a bunch of impl and then KISS since
we don't use the advanced shit yet. It might be nice to tie this more
closely to CommandButton, et al.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5300 542714f4-19e9-0310-aa3c-eee0fc999fb1
Doing a loop on a null object works:
for (s in null)
But checking to see if a property is in a null object throws an error:
(s in null)
They're so similar!
So, protect against the NPE.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5233 542714f4-19e9-0310-aa3c-eee0fc999fb1
My change to ClassUtil broke this when serializing
ByteArrays and such from a sub ApplicationDomain.
Jesus this stuff is annoying.
I have no idea why it's not the same Class when you
create a standard flash library class from within a sub AppDom.
But let's go ahead and check the object by name, then.
Hopefully this doesn't break something ELSE.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5232 542714f4-19e9-0310-aa3c-eee0fc999fb1
Work around my issue another way, which is in some ways smoother: if the
object is a normal object from a normal class, get the class right off
instead of even doing the by-name stuff.
The appDom stuff could conceivably still be desired in the future, but
this will cover just about everything and we can always re-add this extra
business when need it.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5230 542714f4-19e9-0310-aa3c-eee0fc999fb1
If the arg specified is null, do not wrap it into an array! It prevents you
from being able to call a function and falling back to the default value
for the argument. Instead, only wrap non-null.
If you really do want to pass null as your arg, you'll have to wrap it in
an array.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5197 542714f4-19e9-0310-aa3c-eee0fc999fb1
current directory. The current directory is set to /.
So we can't read parameters.xml out of the current directory and we can't pass
the current directory in, because if we could do that we wouldn't need parameters.xml!
GAH! So read parameters.xml from the same directory as the SWF, because
that's the only thing we can reliably know about.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5133 542714f4-19e9-0310-aa3c-eee0fc999fb1
Ray Greenwell