proper interface like all the other new invocation service backends.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4795 542714f4-19e9-0310-aa3c-eee0fc999fb1
altogether as that also solves the "Class.getDeclaredFields() is not required
to return fields in declaration order" problem which has been looming. However,
this should work for now.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4701 542714f4-19e9-0310-aa3c-eee0fc999fb1
it on Narya itself and there's no way to say "only execute this task if the
supplied condition is met" without bringing in extra bullshit from ant-contrib
which I really don't want to do.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4696 542714f4-19e9-0310-aa3c-eee0fc999fb1
and writer methods for private and protected fields. This will allow us to
preserve the current read and write ordering and in the future when we "fix"
read and write ordering, we won't be fucked by a bunch of generated methods
that force the ordering. (Someone is using Presents on the CLR which turns out
to take advantage of the loose specification of Class.getDeclaredFields() and
not return them in declaration order, yay!).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4692 542714f4-19e9-0310-aa3c-eee0fc999fb1
use in non-sandboxed environments). Unfortunately we have to do this for all
Streamable classes, not just the ones that have protected/private members
because we need to be able to call super.readObject() and have that exist even
if our superclass contains only public members.
Doing magic streaming with combinations of classes that do and don't have
readObject() would start to get extremely complicated, particularly if the base
class had readObject() an intermediate class had none, then a later class had
one again. Madness. Doing things with compiled methods will be faster anyway...
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4686 542714f4-19e9-0310-aa3c-eee0fc999fb1
larger build process get them from dist/lib at the top-level.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4455 542714f4-19e9-0310-aa3c-eee0fc999fb1
the snapshot so that it contains all appropriate dependencies regardless of
from where the local build got them.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4427 542714f4-19e9-0310-aa3c-eee0fc999fb1
some kind of annoying fiddling to allow its dependencies to come either from
the build directory of its dependee or from lib/.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4423 542714f4-19e9-0310-aa3c-eee0fc999fb1
Java. Of course this is a very limited translation facility that is mainly
focused on auto-generating Streamable ActionScript classes from their Java
originals, and it doesn't actually convert method bodies, just field and method
declarations, initial values, and such.
Most of our Streamable classes don't have much in the way of real methods, and
the autogenerator will stick new methods in when they show up on the Java side
so at least we'll *know* that they need to be implemented. And the main thing:
readObject and writeObject are in fact implemented by the code generator so at
least we won't be plagued by annoying streaming errors when we change something
on the Java side and forget to change the ActionScript side.
Next up, auto-generating InvocationService interfaces and InvocationMarshaller
implementations in ActionScript and ActionScript versions of DObjects.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4394 542714f4-19e9-0310-aa3c-eee0fc999fb1
Pecos. I'll sort out the per-project niggling bits in just a moment.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4209 542714f4-19e9-0310-aa3c-eee0fc999fb1
genericize Narya data structures, nor make the existing code type safe. That's
going to be an extremely large project.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4007 542714f4-19e9-0310-aa3c-eee0fc999fb1
previously redone the InvocationService and DObject generation tools but not
the InvocationReceiver tool.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3913 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne