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
not especially fond of the @Generated annotation anyway, so I'd kind of rather
use this an excuse to remove it, but I'll just live and let live.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6229 542714f4-19e9-0310-aa3c-eee0fc999fb1
JDK users can continue function and persist in being a pain in our collective
asses (and persist in paying the salaries of most of the people whose assses it
pains).
You guys do know about Getdown's automatic JDK upgrade feature, don't you? You
should use it and then have the server record statistics about the JVM versions
of all of the clients. If nothing goes wrong (and I'm pretty sure we used it on
Bang and it worked well enough), then your 1.5 user base will disappear.
Oh wait, maybe you've already done that, or don't want to do it so that you can
continue to support the Mac OS users who run on some version for which Apple
will never provide Java 1.6. Well, Apple has abandoned Java completely, so
future Mac users probably won't be able to run Puzzle Pirates anyway. Joy.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6227 542714f4-19e9-0310-aa3c-eee0fc999fb1
the .classpath. I'm leaving optional="true" on the project entries in mute
protest of its non-workingness.
When project dependencies are met (since they come first in the list), Eclipse
will use those to find the code they export and everything will be groovy.
When they're not met, if you switch Window -> Preferences -> Java -> Compiler
-> Building -> "Incomplete build path" from Error to Warning, it will build and
just leave you with three annoying warnings in the Problems list about
unsatisfied project dependencies.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6226 542714f4-19e9-0310-aa3c-eee0fc999fb1
since been replaced by using the secret undocumented JDK APIs for doing the
same thing. AFAIK that works on all of our servers and we're not shipping
libsignal.so with anything.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6225 542714f4-19e9-0310-aa3c-eee0fc999fb1
not crap undesired directories onto Eclipse users' filesystems).
I first tried installing m2eclipse and then recoiled in horror as it started
doing crazy shit and didn't even work in the end. Then it took me 10 minutes to
figure out how to uninstall plugins from Eclipse. Who writes this software?
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6224 542714f4-19e9-0310-aa3c-eee0fc999fb1
That's now the canonical place to list the dependencies, which will make
eventual publishing of Narya to Maven Central easier, and will make using
things like m2eclipse smoother.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6223 542714f4-19e9-0310-aa3c-eee0fc999fb1
ActionScript bits remain belligerent, but the Java stuff is mostly shipshape.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6222 542714f4-19e9-0310-aa3c-eee0fc999fb1
Google's CTemplate) and got all hot and bothered, because it seemed like it
would be sufficiently powerful to replace Velocity for our Narya templating
needs.
I then sought out a Java implementation and found one, and quickly discovered
that it lacked the right level of awesome for my needs. So I foolishly decided
to write my own, because Mustache seemed simple enough that I could reimplement
it in a few hours.
A few hours later, I had a neat and tidy reimplementation of Mustache and then
set about to converting Narya to using it. Then the fun began.
I discovered that Mustache wants everything in a hash, but sometimes you just
want to iterate over the elements of a list, and print them into the template
whole-hog. So I extended Mustache with the special "this" variable for printing
the whole context instead of pulling values out of it by name.
Then I remembered that Velocity allows you to do a deep dive into objects,
calling methods and calling methods on the return values of those methods.
Velocity even allows you to pass constants as arguments to those methods (true,
strings, integers). Well, I reimplemented the compound keys, so that you can
call foo.bar.baz, but I didn't go so far as to support constant arguments. That
seemed a step too far into complexity land and to be the sort of thing that
Mustache tries to avoid. So with compound keys, I just had to add a few
alternative versions of methods we were already calling, since we only ever
passed true/false as an argument.
Then I realized that Mustache doesn't do any smart trimming of newlines, so if
you have:
{{#stuff}}
blah blah
{{/stuff}}
You get the annoying newline after the open-tag and after the close-tag. So I
modified my implementation to trim newlines in those circumstances, so that
template authors don't have to do a bunch of template-weirding whitespace
jockeying.
Then I discovered that Mustache doesn't support any notion of scope. So when
you're inside a so-called section, the only variables visible are those bound
by that section. The stuff outside the section is totally invisible. Well,
that's not how Velocity works, you can reference things outside your loop
iterations. It seemed no terribly affront to Mustache to make things work that
way as well, so I did that.
Then I discovered a problem with the fact that Mustache implicitly binds the
loop object to the root of the namespace, so if you have {{name}} outside the
loop and then your loop object also contains a {{name}} field, then you can't
see the outside {{name}} anymore because it's shadowed. Tough titties, in this
case, I just changed our code to not shadow the name.
Then I encountered a bunch of uses of $vidx to put a space before all but the
first element of a list. So I added two more special variables -first and -last
which allow you to do just that sort of thing (and more) in a more template
friendly way because you don't need a Turing complete language just to decide
whether or not you need to mind the gap.
Then I encoutered some uses of $vidx directly, where we were using it to assign
constants in invocation service related classes. So I added another special
variable -index which resolves to basically the same thing that $vidx resolves
to (a 1-based counter indicating which element you're on in your list
iteration). I rationalized to myself that if you wanted to automatically number
laundry lists in your templates, having -index would be nice.
Finally, I have Narya's templating stuff producing character-for-character
replicas of what it used to do with Velocity. Well, actually there's one
newline in a place where there didn't used to be one, but I think that newline
makes sense and it was maybe some sort of Velocity bug that caused it not to
exist.
I've tested the gendobj, genservice and genreceiver tasks. I have no tested
whatever uses streamable_as.tmpl, but I'm pretty confident that it will work
exactly as before because I modified hundreds of lines of other templates in
exactly the same ways and they all work just fine.
So the world gets yet another templating library:
http://code.google.com/p/jmustache/
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6218 542714f4-19e9-0310-aa3c-eee0fc999fb1
classes are found before the tools version, and class equality comparisions don't work.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6217 542714f4-19e9-0310-aa3c-eee0fc999fb1
Map and List types are streamed as fields, which are smaller on the wire. I'd deprecate them, but
yohoho uses them all over the place.
Handle generating code for StreamableArrayList and StreamableHashMap in actionscript for existing
code.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6215 542714f4-19e9-0310-aa3c-eee0fc999fb1
Not all streamable things are Streamable (e.g. String, Integer)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6211 542714f4-19e9-0310-aa3c-eee0fc999fb1
Is there a reason Map isn't Equalable? java.util.Map requires an equals implementation, and it has
the same lack of guarantee of its values implementing equals.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6201 542714f4-19e9-0310-aa3c-eee0fc999fb1
writing in the code generated by GenActionScriptStreamableTask.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6199 542714f4-19e9-0310-aa3c-eee0fc999fb1
GeneratedSourceMerger merges the latest version of generated source into a previously generated
version a la GenRecordTask SourceFile. Unlike them, it doesn't have a hardcoded set of sections to
update. Instead it finds any sections using the // GENERATED <name> START and // GENERATED <name>
END markers in newly generated version and replaces those same sections in the old version.
GenActionScriptStreamableTask creates actionscript Streamable classes from their Java counterparts
like GenActionScriptTask, but unlike GenActionScriptTask it doesn't attempt to parse Java source to
generate actionscript. It only generates actionscript code to do streaming and leaves any
custom implementation to the user.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6196 542714f4-19e9-0310-aa3c-eee0fc999fb1
CrowdContext service instead of sneaking it into the ChatDirector's
constructor. That way other CrowdContext users can make use of the
MessageManager as well.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6192 542714f4-19e9-0310-aa3c-eee0fc999fb1
have Narya and her myriad dependencies in tow, and need to put narya-tools into
their classpath.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6190 542714f4-19e9-0310-aa3c-eee0fc999fb1
reflection internally to look default implementations by class name. Sigh.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6188 542714f4-19e9-0310-aa3c-eee0fc999fb1
IsSerializable. If possible, it would be nice to keep GWT references out of
narya-base (where com.threerings.web ends up).
I'm already dealing with the breakage caused by GWT in narya-distrib, but I'd
rather not have to filter GWT out of narya-base *and* narya-distrib in every
Proguard configuration from here to Gomorrah, if possible.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6187 542714f4-19e9-0310-aa3c-eee0fc999fb1
version of Ant, it issues a warning if you fail to do so. Genius!
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6186 542714f4-19e9-0310-aa3c-eee0fc999fb1
unfortunate event that someone puts it on a real project classpath.
Modified GenTask to totally hide Velocity from derived classes so that external
libraries can make use of it in their own Ant tasks without inheriting a
Velocity dependency and also becoming booched because Velocity was renamed in
jarjar and won't link against an unrenamed Velocity.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6185 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne