that would cause this class matching script to fail in unexpected ways?
I'm sure to soon find out.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2724 542714f4-19e9-0310-aa3c-eee0fc999fb1
is a problem with starting a transaction, we don't get an exception
for failing to commit the transaction.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2712 542714f4-19e9-0310-aa3c-eee0fc999fb1
distinguish between uninitialized and various file errors, and hopefully
get us some better logging output. (If there are errors with a file,
lastModified() returns 0, which would have caused resolveJarFile to think
that the bundle just wasn't ready yet and not create the JarFile object,
which resulted in a NPE, and not useful IOEs.)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2709 542714f4-19e9-0310-aa3c-eee0fc999fb1
in the low-level invocation services whereby after a disconnect, any
InvocationReceiver registration would be wholly ignored due to the
previous registrations being left in the receivers set and DSet refusing
to add duplicate instances of the registration. This wasn't immediately
apparent because the initial set of registrations always happens in the
same order and thus are equally useful after the reconnect and any other
registrations are removed during the normal course of affairs. But if a
user disconnects *during* a puzzle, they will leave that puzzle's
registration around and be unable to play that (or any) puzzle again until
they log off and back on.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2707 542714f4-19e9-0310-aa3c-eee0fc999fb1
circumstances where they aren't around when they should be.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2702 542714f4-19e9-0310-aa3c-eee0fc999fb1
- Require a Comparable key in get() and containsKey().
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2698 542714f4-19e9-0310-aa3c-eee0fc999fb1
allowing things to get out of hand. Since getOccupantInfo may normally
return null, doing so in our strange failure case will not cause further
freakout.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2697 542714f4-19e9-0310-aa3c-eee0fc999fb1
code did that due to eventuall getting out of the loop, the "fixed" code
failed to do it if we failed to fill our buffer up on the first read.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2695 542714f4-19e9-0310-aa3c-eee0fc999fb1
the loop, so I'm rolling back to the previous version since I can't even
log in to my server with this change. Mike if you want to take a look or
tell me what jimmyjamming needs to be done to make this change work, that
would be great.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2694 542714f4-19e9-0310-aa3c-eee0fc999fb1
frame size was exactly the same size as the buffer and no future messages
came down the pipe to wake us up again. This probably would have had to
happen very early in the session as the buffer gets bigger and bigger to
accomodate the largest frame seen during the entire session and
asynchronous messages are coming in more frequently as well. Thus it's
extremely unlikely that this ever actually hung. In any case, we now log
that circumstance (and do the right thing) so we can see if the log
message turns up in future bug reports.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2693 542714f4-19e9-0310-aa3c-eee0fc999fb1
catastrophic fuckola, but we can wait until later to freak out.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2690 542714f4-19e9-0310-aa3c-eee0fc999fb1
hotspot, which does not need to be the upper left coordinate. So we let
the sprite do the right thing and we just center on the hotspot.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2681 542714f4-19e9-0310-aa3c-eee0fc999fb1
beginning. To do this more efficiently, we end up having to do some
jockeying.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2679 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne