In addition to the streamable generation, there were also issues with the receiver stuff, mostly to do with import
ordering. Modernizing that code to use ImportSet and {importGroups} seems to have fixed it.
NOTE: This is also broken in narya 1.9, but it not really worth the effort to fix that. It's easier just to move all
the projects that need it back to trunk. Hurray bleeding edge!
Testing done: gencode in orth and who, checked no diffs were generated.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6727 542714f4-19e9-0310-aa3c-eee0fc999fb1
InvocationProviders that take that type instead of just ClientObject.
Also, use the full set of import groupings no matter what. If that's the way we like it, that's the
way we like it.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6682 542714f4-19e9-0310-aa3c-eee0fc999fb1
* Add importGroups template variable, set to the two groups: one for java, one for threerings.
* Omit Client import the client-side generated code. This was removed some time ago.
* Omit the blanket int -> Integer replacement, this was only needed for the marshaller
* Add the as boxing imports when generating the marshaller (this gets the Integer import for int types in marshaller signatures)
* Change the templates to put space between each group of imports.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6677 542714f4-19e9-0310-aa3c-eee0fc999fb1
streamed property of the event. It turns out to be cleaner to just set it in
the places where we know that we want a specific transport anyway.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6581 542714f4-19e9-0310-aa3c-eee0fc999fb1
Bug 4464323 was filed 10 years ago, bringing this to Sun's attention, and has
been acknowledged as a known bug. Apparently this has not annoyed anyone on the
Java team enough to merit fixing. Sigh.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6532 542714f4-19e9-0310-aa3c-eee0fc999fb1
match DSets and setting attributes. With the old behvaior, if a client subscribed to a DObject and
modified an OidList on it in a single pass, it could miss the modification. The DObject is
serialized immediately when the server gets the subscription request, but events aren't sent for
that subscription till it's processed the next time the omgr queue comes round.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6420 542714f4-19e9-0310-aa3c-eee0fc999fb1
calls on the Java side, to match this added convenience we introduced to the
ActionScript side some time ago.
Before arms are raised into the air and waved like they really do care, bear
the following in mind:
Nothing will change at all on your project until you take some action to do so.
That action could include any of the following:
1. Continue to use narya-tools-1.2 to run genservice and you'll get the old
style "pass a Client reference for every service method invocation" marshallers
and you can continue to live happily in the past.
2. Leave some of your stuff un-regenerated, but generate new stuff using the
new tools and use the Client-reference-free style for new services. This is
likely to engender some PITA if you're trying to use both styles in the same
project because genservice just wants to operate on everything, but I offer it
as an option in case some other PITA motivates the tolerance of this
(presumably smaller) PITA.
3. Embrace the brave new world of simplicity and wield your good friend sed for
fun and profit:
(make necessary build.xml updates to start using narya-tools-1.4-SNAPSHOT)
% find src -name '*Service.java' | xargs sed -i 's:Client client, ::g'
(this will remove the Client argument from most of your services, some manual
fixes may be needed)
% ant genservice
% find src -name '*.java' | xargs sed -i 's:_ctx.getClient(), ::g'
(this will fix most of the places that pass a client reference into an
invocation service, some manual fixes will probably be needed)
I did this on Vilya and it magically took care of like 95% of the places where
changes were needed. The remaining half dozen changes were painless. Clearly
something like Yohoho vastly dwarfs Vilya in scope, but someone looking for an
hour or two of mindless typing to distract them on a lazy Sunday afternoon
would likely breeze through even that vast codebase without breaking a sweat.
Two more notes:
1. I'm going to switch Narya and Vilya over to the new style, and I'll be
fixing all the projects that use their services.
2. I lied (a teeny bit) about nothing changing. I made the old Client-taking
sendRequest methods deprecated, so projects that don't switch to the new style
will be presented with a large number of deprecation warnings. If this is too
terrible a burden to bear, I can remove the deprecation annotations on those
methods.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6395 542714f4-19e9-0310-aa3c-eee0fc999fb1
(Hope I'm not stepping on anyone's toes with this; I'm happy to revert if there are strong arguments against.)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6390 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
It provides code generators for streamables, services and receivers, but not DObject. It uses
Apple's CFNetwork for its sockets and builds with XCode, so it's limited to OS X and iOS. It should
be straightforward to replace both to make it cross-platform.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6264 542714f4-19e9-0310-aa3c-eee0fc999fb1
Jamie Doornbos