simply a function from K to V. Sorry to break users but I know you're few and
being able to integrate with all the excellent Google Collections functional
stuff is a juicy reward for a little egg breaking.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5976 542714f4-19e9-0310-aa3c-eee0fc999fb1
* Apparently, a couple of whitespace cleanups my gvim did awhile ago while I was looking around in
here.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5971 542714f4-19e9-0310-aa3c-eee0fc999fb1
getting that adds the default value to the map. I opted for fetch() which at
least means something close to get() and can be documented as also inserting
the default value. I also considered obtain() and acquire() but those both felt
like they had something to do with locks. apply() seemed too functional.
wangle() seemed like a strong contender for a while.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5965 542714f4-19e9-0310-aa3c-eee0fc999fb1
inspection and approval and Matt's eventual use.
Note that we can't put this in samskivert as it depends on Google
Collections. Perhaps we should create an ooo-utils library for things like this
(and possibly move Narya's Serialization replacement therein since it is pretty
general purpose; Nate is using it for Riposte, for example).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5952 542714f4-19e9-0310-aa3c-eee0fc999fb1
logs that it's listening on its configured ports, when start() is called. It
does so on a separate thread, but I don't believe the subtle ordering
possibilities there are something that's actually causing/likely to cause
problems and/or needs to be called out.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5947 542714f4-19e9-0310-aa3c-eee0fc999fb1
support streaming them as bytes.
It's better than writing a modified UTF String, but
it'd be even nicer if we could avoid the short to read the class name
(Enums are final), but I suppose we still have to know whether one is null
or not. Hm.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5920 542714f4-19e9-0310-aa3c-eee0fc999fb1
No need to tell the server the callerOid, it already knows it.
This saves 4 bytes for every listener you pass into an invocation request.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5908 542714f4-19e9-0310-aa3c-eee0fc999fb1
checking the PresentsInvoker itself and the DObjectMgr. Expose waiting for all theses queues to
empty on PresentsInvoker such that Presents servers can do things like wait for all the queues to
empty before opening to the public.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5898 542714f4-19e9-0310-aa3c-eee0fc999fb1
interface. The way this works is a little tricky, but it all works out.
We have a service SceneService with SceneMoveListener declaration. You can make
FooSceneService and have a method in that service take a FooMoveListener which
extends SceneMoveListener. An instance of FooMoveMarshaller will only be
created if you call the method on FooSceneService and that will result in an
object on the server side that implements SceneMoveListener, but calls to the
SceneMoveListener response methods will result in the FooSceneService response
codes being marshalled and sent back to the caller.
So you can pass the FooMoveListener around to code on the server that expects a
SceneMoveListener and it will magically do the right thing when server code
calls through the SceneMoveListener interface. You can even turn around and
pass the FooMoveMarshaller to another invocation service method (on a peer
perhaps) that takes SceneMoveListener and it will work because the SceneService
call will generate a SceneMoveMarshaller on the remote server, which will use
the SceneMoveMarshaller's codes to communicate the response back to the first
peer, which will unmap those and call the methods on the SceneMoveListener
interface which will remarshal them with the FooMoveListener's codes and send
them back to the client, and bob is everyone's uncle.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5891 542714f4-19e9-0310-aa3c-eee0fc999fb1
Charlie Groves