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
it on Narya itself and there's no way to say "only execute this task if the
supplied condition is met" without bringing in extra bullshit from ant-contrib
which I really don't want to do.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4696 542714f4-19e9-0310-aa3c-eee0fc999fb1
and writer methods for private and protected fields. This will allow us to
preserve the current read and write ordering and in the future when we "fix"
read and write ordering, we won't be fucked by a bunch of generated methods
that force the ordering. (Someone is using Presents on the CLR which turns out
to take advantage of the loose specification of Class.getDeclaredFields() and
not return them in declaration order, yay!).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4692 542714f4-19e9-0310-aa3c-eee0fc999fb1
readObject()/no-readObject() havers otherwise everyone everywhere will have to
generate streamer methods which is way too big a PITA. Grumble.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4690 542714f4-19e9-0310-aa3c-eee0fc999fb1
use in non-sandboxed environments). Unfortunately we have to do this for all
Streamable classes, not just the ones that have protected/private members
because we need to be able to call super.readObject() and have that exist even
if our superclass contains only public members.
Doing magic streaming with combinations of classes that do and don't have
readObject() would start to get extremely complicated, particularly if the base
class had readObject() an intermediate class had none, then a later class had
one again. Madness. Doing things with compiled methods will be faster anyway...
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4686 542714f4-19e9-0310-aa3c-eee0fc999fb1
clientSessionDidEnd() which is called on the dobjmgr thread directly.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4680 542714f4-19e9-0310-aa3c-eee0fc999fb1
the controller has located the appropriate function.
- If the arg for a command or callback is an array, assume those are
the parameters for the function. If you desire passing a single array
argument, you've got to wrap it in another array, otherwise single
args will be automatically wrapped for you.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4676 542714f4-19e9-0310-aa3c-eee0fc999fb1
been disconnected (in which case there may be conflicts in lock
ownership) or are connected asymmetrically (A is subscribed to B, B is
not yet subscribed to A).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4674 542714f4-19e9-0310-aa3c-eee0fc999fb1
fake Entry implementation. This also avoids breakage if a DSet entry's key
itself implements DSet.Entry (which just happened for the first time in Narya
history).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4673 542714f4-19e9-0310-aa3c-eee0fc999fb1
- handle // @Override // blah style comments
- deal with fields that are assigned to anonymous inner classes (actually
anything with braces, which would also include array literals).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4667 542714f4-19e9-0310-aa3c-eee0fc999fb1
them to the appropriate ChatDisplay when we're doing chat in IM-style
individual windows.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4663 542714f4-19e9-0310-aa3c-eee0fc999fb1
something funny is happening with spurious objects dispatched across servers.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4657 542714f4-19e9-0310-aa3c-eee0fc999fb1
will not name, was trying to allow certain authentications to proceed directly
on the authenticator thread instead of making a round trip through the
invoker. This resulted in those authentications trying to post their results
from the authenticator thread, which is bad because all downstream messages
should be posted from the distributed object thread.
The only authentications that would "benefit" from this optimization were peer
authentications of which there would be extremely few (currently one in our
largest installation) compared to the hundreds of thousands of normal
authentications, which have to make the invoker thread round trip as a matter
of course.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4655 542714f4-19e9-0310-aa3c-eee0fc999fb1
process an authentication request if it is asked to do so before it has an
invoker (meaning the server is not yet initialized).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4654 542714f4-19e9-0310-aa3c-eee0fc999fb1
looks like it should be running on the dobjmgr thread.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4653 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne