The ActionScript code is now under aslib and is built via Maven (and Ant). The
CPP code is under cpplib and is ignored by everything (other than service
generation), but now at least it's not crufting up the Java submodule with its
XCode project.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6783 542714f4-19e9-0310-aa3c-eee0fc999fb1
This will allow us to properly ship narya-tools.jar to Maven Central which is
necessary for Nenya and Vilya (and any other Narya-using project) to themselves
be built.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6776 542714f4-19e9-0310-aa3c-eee0fc999fb1
deploy" is used by the build server and installs javadocs and source.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6730 542714f4-19e9-0310-aa3c-eee0fc999fb1
headers on the associated Java files were being stripped.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6534 542714f4-19e9-0310-aa3c-eee0fc999fb1
This has a few benefits over the old system:
* We don't have to copy our Maven, Java, and Actionscript settings to every project
* Maven dependency fetching uses a cache in dist until clean is run instead of checking for
snapshots on every build
* Building aslibs no longer needs to generate a configuration file, which grows confusingly stale
* Nailgun can be used to run mxmlc. This cuts actionscript compile time in half. It can also
generate a script to call nailgun, which avoids the few seconds of Java startup required to run Ant.
This means we're using Flex 4 to compile naryalib.swc now, but we released a 1.7 recently. Any
projects wishing to stay out of Flex 4 land can pin to that.
If this goes off without too much turbulence, I'll migrate our other projects in a couple days.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6513 542714f4-19e9-0310-aa3c-eee0fc999fb1
less polluted. Between build systems, IDEs and IDE-specific-build-systems we've
got half a dozen metafiles knocking around the top-level directory. It's
mayhem.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6359 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
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
the real source code. That's where reusable classes live. Amazing!
Also cleaned up some build.xml bits and nixed the Retroweaver stuff. I thought
we might have still been using that, but then I saw the hardcoded path to
/usr/local/jdk1.4 and knew that it couldn't be so.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6285 542714f4-19e9-0310-aa3c-eee0fc999fb1
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
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
<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
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
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
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
Ray J. Greenwell