we can't rely on building a new client info at session end time because the
client's ClientObject will have been destroyed.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4250 542714f4-19e9-0310-aa3c-eee0fc999fb1
decrement the reference count of the client object as it is normally
incremented for every resolution listener.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4248 542714f4-19e9-0310-aa3c-eee0fc999fb1
required some serious bending and folding of the generic type system, but for
the most part we managed to avoid any mutilating. The gendobj task now
generates properly typed "addToXXX" and "updateXXX" DSet methods based on the
parameterized type of the DSet. This might cause unrecompiled code to break,
but I don't think there are many cases in the base toolkit where people call
DSet adders or updaters. We'll see and I'll add backwards compatibility
versions for cases where we need them to support GG games (everything else we
can just recompile).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4245 542714f4-19e9-0310-aa3c-eee0fc999fb1
construct that could be made to do what I want in a type safe manner. The
method returns Class<? extends NodeObject> which is correctly expresses the
valid types that can be returned.
However, I can't pass the capture <? extends NodeObject> (NodeObject extends
DObject) to a method that takes <T extends DObject>. I'm not entirely sure why
not, but I imagine it has something to do with the subtleties of type-erasure,
or maybe it's just a limitation of the inference that can be done by the
compiler. I don't know what type <? extends NodeObject> is considered to be, I
would have thought just NodeObject but apparently not.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4242 542714f4-19e9-0310-aa3c-eee0fc999fb1
resolution fails for whatever reason and we will properly track our pending
resolutions (not leaving them dangling if resolution failed) and do so more
elegantly (by simply acting as a ClientResolutionObserver ourselves).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4239 542714f4-19e9-0310-aa3c-eee0fc999fb1
make connections to other servers in the cluster and can exchange events (in a
limited fashion).
This is different than Liz's project wherein servers share an oid space and one
can interchangably work with distributed objects from any server. This package
provides a means by which certain services (by default, presence and chat) can
be communicated between servers to allow communication between players
scattered around a bunch of otherwise independent server instances.
This is less general purpose but also less likely to encourage people to write
code that tightly couples multiple servers and then falls over because it
generates gobs of network traffic as events are flung willy nilly behind the
scenes.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4238 542714f4-19e9-0310-aa3c-eee0fc999fb1
asynchronous exception, so we can't use it or badness will ensue.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4235 542714f4-19e9-0310-aa3c-eee0fc999fb1
code but new code should use the new logging style:
import static com.threerings.presents.Log.log;
and call log.info(), log.warning(), etc. We can migrate old code as the desire
grips us.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4231 542714f4-19e9-0310-aa3c-eee0fc999fb1
inheriting a socket channel inetd style. It doesn't actually work for annoying
reasons, but I figured I'd get the code in there and the type safety fixes and
maybe Sun will fix their stupid bug at some point (I should create a test case
and actually submit a bug report...).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4230 542714f4-19e9-0310-aa3c-eee0fc999fb1
synchronization problems and decided it would be a lot easier to just fix them.
The interval thread and the communication writer thread need to be properly
coordinated to avoid funny business.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4229 542714f4-19e9-0310-aa3c-eee0fc999fb1
which is currently accumulating on the server and always zero on the client.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4224 542714f4-19e9-0310-aa3c-eee0fc999fb1
Only reset our accumulating counters for the periodic reports.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4219 542714f4-19e9-0310-aa3c-eee0fc999fb1
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
Michael Bayne