logic. If we're inner and we're not static, we have a problem.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5019 542714f4-19e9-0310-aa3c-eee0fc999fb1
non-static member. Pre-1.5 VMs can't do all of these things and Retroweaver
freaks out at runtime when put to the task.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5018 542714f4-19e9-0310-aa3c-eee0fc999fb1
freakoutery as we try to stream the instance's implicit reference to its
containing class.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5001 542714f4-19e9-0310-aa3c-eee0fc999fb1
altogether as that also solves the "Class.getDeclaredFields() is not required
to return fields in declaration order" problem which has been looming. However,
this should work for now.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4701 542714f4-19e9-0310-aa3c-eee0fc999fb1
around of the interface (I wanted to automatically call getStreamerClass() for
the caller but that turns out not to be possible when unstreaming so fuck it).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4373 542714f4-19e9-0310-aa3c-eee0fc999fb1
are now correct, but unfortunately a little more complicated.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4371 542714f4-19e9-0310-aa3c-eee0fc999fb1
type, but we don't really want to pollute our class <-> id mapping with a bunch
of extra fiddly enum classes, so we stream all enums as instances of their
declared type and let Enum.valueOf() map back to the custom derived type when
it creates an instance during deserialization.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4370 542714f4-19e9-0310-aa3c-eee0fc999fb1
value to avoid future compatibility problems if someone saves an object to a
database and then later adds a new enum anywhere but at the end of the list,
thereby changing the ordinals.
If you want maximal network efficiency, don't use enums. For most of what we'll
do with them, it doesn't merit having the future incompatibility hitch of
sending the ordinal.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4369 542714f4-19e9-0310-aa3c-eee0fc999fb1
otherwise we'll just get the name. I'm killing StringUtil.getMessage().
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4304 542714f4-19e9-0310-aa3c-eee0fc999fb1
I was getting an IllegalArgumentException and the message was "null",
so this will at least log the name of the exception.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4263 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
our streaming system should work with multidimensional arrays: in fact it
kinda already did, if the element type of the outermost array was something
for which we already had a streamer. Thus, int[][] worked, Object[][] worked,
etc. One small method change and now arbitrary multidimensional arrays
will work.
Why bother? Consistency, and the way I'm working on doing even the int[][]
arrays in actionscript supports unlimited dimensions, so why not?
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3921 542714f4-19e9-0310-aa3c-eee0fc999fb1
String marshaller as a StreamerMarshaller is used for String fields.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3651 542714f4-19e9-0310-aa3c-eee0fc999fb1
field or fields of a streamed object. This allows us to add new fields to
the end of a streamable without causing all existing serialized versions
to become unreadable.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2629 542714f4-19e9-0310-aa3c-eee0fc999fb1
one instance of the nested exception failing to log anything useful when
it is reported at a higher level and we're seeing failures in the
low-level streamable decoding code which need debugging.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2087 542714f4-19e9-0310-aa3c-eee0fc999fb1
the object serialization code which means that we can automatically
serialize said data members. Hooray!
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2075 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne