Turned off the very verbose unit profiles as we don't currently use them. Wired
up SIGUSR1 to dump a report to the log.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4218 542714f4-19e9-0310-aa3c-eee0fc999fb1
Pecos. I'll sort out the per-project niggling bits in just a moment.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4209 542714f4-19e9-0310-aa3c-eee0fc999fb1
parameterized types will be easy to add, but I've not yet had occasion to use
them. We're all about "just in time" support.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4165 542714f4-19e9-0310-aa3c-eee0fc999fb1
returns a properly typed clone of the DSet in question.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4164 542714f4-19e9-0310-aa3c-eee0fc999fb1
on multiple ports, falling back from one to the next as appropriate.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4158 542714f4-19e9-0310-aa3c-eee0fc999fb1
These are the preferred way to get instances of Boolean, Byte,
Short, Character, Integer, Long, Float, and Double object.
It's always made sense for Boolean objects, and with 1.5 these factory
methods were blessed as the proper way to get instances unless one
absolutely needed a distinct object.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4145 542714f4-19e9-0310-aa3c-eee0fc999fb1
all generic references to E as DSet.Entry rather than Object which is what I
was assuming. So when I write:
(E[])new Object[...]
that gets rewritten to:
(Entry[])new Object[...]
which causes le freakout. We need to use Entry[] everywhere, which we happened
to be doing for everything except toArray().
I rewrote things to use E[] everywhere now that I know it will get rewritten to
Entry[]. I thought it was going to get rewritten to Object[] before so I didn't
genericize that stuff.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4059 542714f4-19e9-0310-aa3c-eee0fc999fb1
have to be parameterized on the type of the Comparable that is returned by
getKey(), but that turns out to be a twisty maze of generics that is not
obvious to me how to express using Java's generics syntax and it opens up
various cans of worms that I don't have time to solve right now. So we'll
settle for the DSet itself being parameterized on the Entry class and the Entry
class being non-type safe.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4051 542714f4-19e9-0310-aa3c-eee0fc999fb1
magically booches and causes an IncompatibleClassChangeError, so we're just
going to work around it.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4008 542714f4-19e9-0310-aa3c-eee0fc999fb1
genericize Narya data structures, nor make the existing code type safe. That's
going to be an extremely large project.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4007 542714f4-19e9-0310-aa3c-eee0fc999fb1
- if a pong response took more than 5 seconds to receive, another ping
would be sent. When the pong finally arrived the delta would be
calculated using the most recently sent ping.
Fix: don't send more pings while waiting on a pong.
- After a pong is received, the _deltas array is mangled while
calculating the server delta, making subsequent pongs possibly
overwrite earlier calculated deltas.
Fix: calculate using a copy.
Also, changed the delta calculation to be the mean of the deltas rather
than the median. Left code in to do it both ways if this change was not
kosher...
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3990 542714f4-19e9-0310-aa3c-eee0fc999fb1
AuthingConnection is replaced by a RunningConnection we need to transfer
over any associated overflow queue to the new connection object.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3989 542714f4-19e9-0310-aa3c-eee0fc999fb1
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
(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
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
previously redone the InvocationService and DObject generation tools but not
the InvocationReceiver tool.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3913 542714f4-19e9-0310-aa3c-eee0fc999fb1
need to be responded to. It turns out that a listener may not be
a marshaller if a server entity is calling a service request method
directly. The convenience method handles this and is also cleaner looking
for callers.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3832 542714f4-19e9-0310-aa3c-eee0fc999fb1
on the adpater user to sort that out, but it's easier to just log things here
and save everyone time and effort.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3814 542714f4-19e9-0310-aa3c-eee0fc999fb1
really ignored, but just never got responded to due to a bigger problem.
(The bigger problems are already logged.)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3810 542714f4-19e9-0310-aa3c-eee0fc999fb1
one event when our run() method is called and then let other (non-distributed
object) things get their chance to run in proper order.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3795 542714f4-19e9-0310-aa3c-eee0fc999fb1
Have invocation marshallers track whether someone ever ended up responding
to the client: if they get garbage collected without ever doing so
(and they're not the base class InvocationMarshaller, which can only report
errors), log an informative error message.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3792 542714f4-19e9-0310-aa3c-eee0fc999fb1
a round trip to the database after a user has changed user objects:
the ClientResolutionListener will get a ResultListener that it should
call when its all done.
Hopefully this doesn't break anything in bang or gardens...
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3766 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne