and the ProxySubscriber mechanism by which the server proxies for the client.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4730 542714f4-19e9-0310-aa3c-eee0fc999fb1
another server. The PeerManager needs both to rewrite the oid of the events
before dispatching them and to assign an eventId to them so that they will not
be filtered by PresentsClient when deciding whether or not to send them along
to its client. Also fixed compound event dispatch in the process. Now proxy
subscribers will be notified once of a compound event rather than of each
individual internal event.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4729 542714f4-19e9-0310-aa3c-eee0fc999fb1
because the oldValue variable didn't contain UNSET_OLD_VALUE, but
rather null because it was set that way in the constructor.
Additionally, some of the constructors would only set the old value
if it wasn't null, which is also wrong because an old value can
easily be null.
We could probably just rip apart most of this code, because for
the most part events are not constructed on the client anyway. We might be
able to get away with just making all the event constructors 0 arg, and
then we don't have to worry about UNSET_OLD_VALUE, we just always apply.
But let's try to be more similar to the Java code, and so now I emulate
multiple constructors by checking how many arguments were provided and
not configuring event-specific data if it wasn't actually provided
to the constructor.
Note: none of this would be necessary if we could just declare a constructor:
public function AttributeChangedEvent (
targetOid :int = 0, name :String = null, value :Object = null,
oldValue :Object = UNSET_OLD_VALUE);
But you can't use constants as the default value in a parameter list
(commence being boggled) so we have to use null instead of UNSET_OLD_VALUE
as the default value, and then check the 'arguments' special variable to
see if someone passed in null or whether it came from the default value. Aiya.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4726 542714f4-19e9-0310-aa3c-eee0fc999fb1
which parses a String like " 7pigs" as the value 7.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4723 542714f4-19e9-0310-aa3c-eee0fc999fb1
I'm not sure what I was thinking: we'll never want to auto-recognize
command:// urls in text. In the places where we'll use them we'll
format things ourselves.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4719 542714f4-19e9-0310-aa3c-eee0fc999fb1
(pre-applied and) posted before we received our object but processed (and hence
dispatched to us) after we received our object.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4715 542714f4-19e9-0310-aa3c-eee0fc999fb1
provided to the object when it was created, have the LocationDirector
initialize the manager caller when it receives the PlaceObject and have it use
its client distributed object manager which tags events with the proper
clientOid. This still prevents us from running multiple clients in the same VM,
so this will probably all have to change again but this works for now.
Also some widening.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4712 542714f4-19e9-0310-aa3c-eee0fc999fb1
instead of our native library. I've left the native library support in in case
the Sun stuff is not available, but that's so extremely unlikely in a server
environment (IBM recreates Sun's signal handling in their VM because it's so
dang useful) that I should probably just nix it altogether and simplify things.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4710 542714f4-19e9-0310-aa3c-eee0fc999fb1
Sigh. So not standard.
I suppose I could devise a whole system for registering protocols, and
adding registered protocols to this regexp, but we'll never have another
one of these and this is just easier for now.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4709 542714f4-19e9-0310-aa3c-eee0fc999fb1
sandbox. They should work exactly the same but there seem to be remaining
niggles, so we'll iron those out without impacting other projects.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4706 542714f4-19e9-0310-aa3c-eee0fc999fb1
writeObject() as that handles nulls for us (and of course because that's how
it's done when streaming using reflection).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4704 542714f4-19e9-0310-aa3c-eee0fc999fb1
- Added getLength().
- Took out crazy null-tolerance in equals(). If your line is malformed,
you may get NPE's trying to test equality with another line. Fix your line.
These are line segments anyway. We should maybe rename this
class to LineSegment.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4702 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
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
Michael Bayne