tasks are, so let's split out the generation of C++ streamable classes into a
genstream class rather than letting it run on the build server which causes
breakage like just now when Ray changed something that caused differently
generated C++ streamable classes to be generated on build1.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6280 542714f4-19e9-0310-aa3c-eee0fc999fb1
closer to working. Firstly, we need to not skip the asdoc build if the aslib
build happens to have generated an up to date .swc. Second, asdoc needs to know
about our library dependencies. Third, we need not to tell it to look for
sources in the non-existent src/player directory.
It's still failing, claiming:
[java]src/as/com/threerings/presents/util/SafeObjectManager.as(30):
col: 37 Error: Definition com.threerings.presents.dobj:SubscriberAdapter
could not be found.
[java]
[java] import com.threerings.presents.dobj.SubscriberAdapter;
which is nonsensical. If it can find SafeObjectManager to try to generate
documentation for it, then it can damned well find SubscriberAdapter which is
also part of this project. SubscriberAdapter depends on no other classes
itself, so it can't be a problem with a dependency of SubscriberAdapter.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6279 542714f4-19e9-0310-aa3c-eee0fc999fb1
The big win is that getKey() now exists on each of those event types.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6278 542714f4-19e9-0310-aa3c-eee0fc999fb1
and then clean out the crap that we don't care about. This downloads all the available source and
javadocs to the maven repository, so if you run that command in your copy of narya, you'll be able
to navigate into library sources in your Eclipse as well.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6274 542714f4-19e9-0310-aa3c-eee0fc999fb1
The presents-specific portions of ConnectionManager like reading Message subclasses and sending
datagrams are now in PresentsConnectionManager. PresentsServer should behave identically, except
during shutdown. Before, connections would be accepted and datagrams would be read until the OMgr
thread exited. Now, both stop as soon as the server begins its shutdown. This seems like an
improvement to me, but let me know if it causes issues and I can rework it.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6270 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
touches the _handlers Map which should only be modified on the
ConnectionManager thread. Add transferAcceptedSocket for outside socket
acceptors to call. It sticks new sockets into a queue, which are then passed
to handleAcceptedSocket as part of ConnectionManager's iterate.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6250 542714f4-19e9-0310-aa3c-eee0fc999fb1
The help message for /help <command> was using the translated/aliased string,
which meant that you had to have a usage translation for each command alias.
This became unmaintainable in Project X, where we had artists adding emotes
with lots of aliases, and I'm guessing it was booched in the Y!PP translations,
since they seem to lack translations for things like m.usage_escuchar. Let's
instead use a usage message based on the untranslated command, then compose
the actual command used into that (for aliases). This should be mostly
backwards-compatible, but I will be updating Yohoho and Bang in addition to
Project X: this involves replacing the command name in the usage translations
with {0} and returning getUsage(command) instead of "m.usage_blabla".
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6248 542714f4-19e9-0310-aa3c-eee0fc999fb1
Looks like eclipse merrily reformatted various lines in my last commit
and added this. Yay.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6240 542714f4-19e9-0310-aa3c-eee0fc999fb1
<java clonevm="true" dir="foo"> not doing the right thing.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6235 542714f4-19e9-0310-aa3c-eee0fc999fb1
on the DObject and invocation services in src/tests/java and checks that
nothing changed.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6234 542714f4-19e9-0310-aa3c-eee0fc999fb1
100K dist/narya-base.jar
676K dist/narya-distrib.jar
68K dist/narya-tests.jar
88K dist/narya-tools.jar
rather than this:
860K dist/narya.jar
Anyone who uses Narya uses narya-base and narya-distrib, and beyond that we're
looking at another 160k which is silly to split out.
To avoid disruption, I'm keeping the other jar files around, so that everything
will continue to work as before while I convert things over.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6231 542714f4-19e9-0310-aa3c-eee0fc999fb1
version has helpfully not been uploaded to Maven Central, but to the JBoss
Maven repository. Anyway, this should fix problems with narya-tools-full.jar.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6230 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne