Just return a string that is very unlikely to match an existing code.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@794 c613c5cb-e716-0410-b11b-feb51c14d237
screwing us on Whirled when we move members' stat sets between servers. This
means Bang will be transmitting a couple of extra bytes per Stat instance down
to the client but I'd rather not have some way to make some kooky distinction
between when we're sending Stat instances between servers versus to a client.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@745 c613c5cb-e716-0410-b11b-feb51c14d237
Note: this involves generated code from a samskivert patch I only just sent to mdb,
but he's in a meeting, so that won't show up for a little.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@741 c613c5cb-e716-0410-b11b-feb51c14d237
is already greater than or equal to the minimum requested, the stat is not modified.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@731 c613c5cb-e716-0410-b11b-feb51c14d237
let's not be checking in debug logging. Bang! Howdy calls these methods
hundreds of thousads of times a day and we don't really want the log spam.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@702 c613c5cb-e716-0410-b11b-feb51c14d237
assignment, not an entire method. Eclipse is helpfully stupid about this, but
we'll just have to use our big brains and help it out.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@701 c613c5cb-e716-0410-b11b-feb51c14d237
- IntSetStat and StringSetStat extend SetStat
- consolidated SetStat-related functions in StatSet, and added StatSet.getSetStatSize()
- she sells SetStat StatSets by the seashore
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@683 c613c5cb-e716-0410-b11b-feb51c14d237
Maybe these two classes should be merged into one? I'm worried that might break other code that already relies on MaxIntStat. Brighter minds: please advise.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@677 c613c5cb-e716-0410-b11b-feb51c14d237
this to automatically retry colliding stat modifications in the repository.
We'll also use the StatModifier to package up and send the modification to the
server that is hosting a user's in-memory stats so that the same adjustment can
be made to those. As a result of this requirement, Stat.Type became
Serializable which means that Stat will probably also need to be serializable
because the pattern we've adopted for our Stat.Type implementationsn is for
them to contain a prototype Stat object which is cloned to create new stats.
Maybe we'll stick with that and make Stat serializable, or maybe we'll do
something else. Not sure yet.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@669 c613c5cb-e716-0410-b11b-feb51c14d237
efficient (and almost certainly faster as well for sets of this size).
Modified add() to properly mark the stat as modified when it changes.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@668 c613c5cb-e716-0410-b11b-feb51c14d237
overridden to intercept such things if necessary (it's not necesary in this
case, we're just trying to set a good example for future programmers).
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@667 c613c5cb-e716-0410-b11b-feb51c14d237
ByteArrayOutputStream to a byte[] once and use that in the three places it's
needed. Some other small formatting tweaks.
git-svn-id: svn+ssh://src.earth.threerings.net/vilya/trunk@665 c613c5cb-e716-0410-b11b-feb51c14d237
Michael Bayne