I was interpreting the lack of modification for $Id lines being people not setting auto props, but
it was actually svn not showing diffs for things it generates. Whoops.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6350 542714f4-19e9-0310-aa3c-eee0fc999fb1
If checking="true" on them, they generate their code to a String instead of a file, and compare that
against existing output. If any generation would produce changes, the build is failed.
As a side effect, generation will now only write files if it's going to modify them, which should
eliminate some spurious compiling.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6349 542714f4-19e9-0310-aa3c-eee0fc999fb1
Any Collection can now be streamed. You can send Collections.emptyMap()
back to a client, for example.
(It will unstream as a HashMap on the other side.)
This actually streams everything to the exact same bytes as before.
Using specific classes is discouraged: ArrayList, StreamableArrayList...
If a Streamer is created for a class that has a field of that type,
a warning will be generated, urging you to change the field definition
to the interface.
Also: that setup is now deferred until needed, because in clyde/projectx
there are a number of Streamable classes that have fields of specific
classes, like ArrayIntSet for example, but don't use standard streaming
to transmit them. In that case it's totally cool for them to have a more
specific type.
Since that setup is potentially deferred, one change may be observed
for a class that uses custom readObject() and writeObject() methods
but still calls defaultReadObject(). The field marshallers will now
be configured a little later in the game than before.
But, we're actually saving a bit of memory by not setting up those
marshallers for streamable classes that never use them. Woo.
Please let me know if this causes any space shuttle explosions or
spikes the punch at your quinceanera.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6348 542714f4-19e9-0310-aa3c-eee0fc999fb1
that does things much more nicely than our old approach. Specifically,
narya-tools is just the stock narya.jar but using a pom that expresses the
tools dependencies as non-optional.
This allows a project to define a special tools classpath that *just* depends
on narya-tools, and all of its myriad niggling dependencies will be taken care
of, without stuffing a second narya jar into the project classpath or adding a
bunch of narya tool dependencies to the projects server package.
Other projects that want to extend Narya's tool suite can export a foo-tools of
their own which can depend on narya-tools and thereby obtain all of narya-tools
dependencies and add their own tool-specific dependencies (if any).
I'm also committing this now with a stable 1.2 version, so that we can sneak it
into the last narya-1.2 stable release. The tools don't need the latest
snapshots, and it's nice if you don't have to go polling a maven server every
time you run "ant gendobj" etc.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6330 542714f4-19e9-0310-aa3c-eee0fc999fb1
signals for each field that can be listened to individually.
From the old:
barrel.addListener(new AttributeChangeAdapter(function (event :AttributeChangedEvent) :void {
if (event.getName() == BarrelObject.MONKEY_COUNT) {
// ... cast event.getValue() and use it
}
}));
to the new:
barrel.onMonkeyCountChanged.add(function (newValue :int, oldValue :int) :void {
// ...
});
Only AttributeChangedEvent have been signalified, but I'm planning to continue with the other
ChangeListeners shortly.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6328 542714f4-19e9-0310-aa3c-eee0fc999fb1
obtain containment and a stack of specifically typed outer class references to
accomplish what we need without misleading casts.
This will require changes to Yohoho which I shall make forthwith.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6320 542714f4-19e9-0310-aa3c-eee0fc999fb1
1. CrowdPermissionPolicy is an object that lives inside a BodyObject, thus it
cannot use server services like dependency injection, nor BodyLocator. However,
that's not a problem because it will never be used by a ClientObject that is
not a BodyObject. If there were a way to enforce with parameterized types that
it only ever be used in conjunction with a BodyObject, I'd do that, but
parallel inheritance hierarchies are not something that any OO type system I'm
aware of can reason about.
2. ClientResolver and its children are not singletons. One is created for each
client resolution process.
I have certainly fallen prey to the same errors during enthusiastic reactions:
it looks like a rose, it has thorns like a rose, oh wait, it's a blackberry.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6319 542714f4-19e9-0310-aa3c-eee0fc999fb1
from BodyObject, then it's your responsibility to make sure that your
BodyObject carries your Crowd permissions. Checking the ClientObject for your
Crowd permissions and then using those on your (separate) BodyObject is too
weird.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6318 542714f4-19e9-0310-aa3c-eee0fc999fb1
This client-side commit matches the new BodyLocator.forClient() method on the server by the addition of CrowdClient.bodyOf(), which should be subclassed by anyone who wants to do anything fancy.
The default implementation is just for the client to cast itself to BodyObject, matching the default (and historical) implementation in BodyLocator.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6317 542714f4-19e9-0310-aa3c-eee0fc999fb1
* Rename PrefixServer.Module classes to PrefixModule. They all implement guice's Module, and it's
hard to pass a class around as its interface if they share a name.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6303 542714f4-19e9-0310-aa3c-eee0fc999fb1
Charlie Groves