Immediately after writing them I considered that they didn't
really belong in ArrayUtil, since they don't operate on Arrays.
Util is better, since it's less specific.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5686 542714f4-19e9-0310-aa3c-eee0fc999fb1
Hopefully nothing was setting the values.
If so, maybe we'll see compile-time errors/warnings.
Maybe.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5677 542714f4-19e9-0310-aa3c-eee0fc999fb1
test cases I've made, it just doesn't work in *other instances*,
which I haven't yet been able to control for.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5676 542714f4-19e9-0310-aa3c-eee0fc999fb1
Apparently they enhanced AMF3 encoding in flash 10. Dictionaries
seem to be encoded differently. I'm sure they thought that they
could sneak this in because it's backwards-compatible, but they
thought wrong. If a Flash 10 client encodes a Dictionary, it
can't be read by a flash 9 client because it's not forwards-compatible.
If you change the spec, you gotta change the version number, because
this shit might be persistent.
So: work around it. Might be sketchy. Let's keep an eye on it.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5673 542714f4-19e9-0310-aa3c-eee0fc999fb1
preferences or just providing a runtime place for them to live.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5671 542714f4-19e9-0310-aa3c-eee0fc999fb1
If there's an error when calling the callback function,
we were assuming it was an argument-related error and trying again.
However, this is sorta bad behavior as we don't want to call
twice into a callback. In the case I was seeing, the first time
in caused an NPE, but popped up a panel, and the second try
was no-opping because the panel was already up (but misconfigured).
So: don't even try a second call, because it looks like
flash will accept args to an argless function.
We'll have to try this out for a while and see if it works.
If so, I can neaten this code. If not, I'll uncomment
some of this and try a more surgical approach (only catch
ArgumentError, only retry if we had 1 boolean arg.)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5585 542714f4-19e9-0310-aa3c-eee0fc999fb1
(We are parsing a URL, and even though it represents a file, it's still
a URL, so it uses the standard slash and not the microsoft slash.)
This will make SDK testing work on Windows.
We suck a lot for not fixing this sooner, but
- I didn't have Windows set up for development.
- It was broken for so long, we deprioritized and then sorta forgot about it.
This has been broken for over 5 months, when I last touched this file
to make it work on Macs.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5506 542714f4-19e9-0310-aa3c-eee0fc999fb1
except the actual throttling part. Need to think about a good way to do this
without blocking the whole client when we hit the throttle.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5428 542714f4-19e9-0310-aa3c-eee0fc999fb1
- Added an ERROR level, along with an error() method.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5395 542714f4-19e9-0310-aa3c-eee0fc999fb1
- 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
Ray Greenwell