> I'm a bit skeptical of adding builders for different variable length
> encodings to the library, simply because there are so many
> possibilities. I think creating a binary-vle (for variable length
> encoding) package would be worthwhile. I have an implementation of the
> VLE used in protocol buf
On Fri, Apr 29, 2011 at 10:25 AM, Evan Laforge wrote:
> Indeed, and I was starting to do that... well, I would make my own
> project specific Serialize class, since the type dispatch is useful.
> But copy pasting a UTF8 encoder, or the variable length Integer
> encoder, or whatever seemed kinda un
> When I need to comply with a specific binary format, I never rely on
> Binary/Serialize class instances - I always fall back on the primitive
> operations on Words of varying sizes (perhaps defining my own type
> classes for convenience). The 'Builder' type makes this pretty easy.
>
> If I were w
Hello,
You might consider using safecopy, which explicitly supports the case
where the serialization format or the datastructure itself changes and
the data needs to be migrated to the new format?
http://acid-state.seize.it/safecopy
- jeremy
On Thu, Apr 28, 2011 at 10:00 AM, Evan Laforge wrote
On Thursday 28 April 2011 17:00:49, Evan Laforge wrote:
>
> Speaking of that Double instance... both data-binary and cereal use
> decodeFloat and encodeFloat which mean they suffer from the same
> problems as realToFrac, namely that -0 becomes 0 and NaN becomes
> -Infinity (I'm not sure why the la
On Thu, Apr 28, 2011 at 10:00 AM, Evan Laforge wrote:
> It's been remarked to me that relying on the Binary and Serialize
> classes is dangerous, because there's no guarantee they won't maintain
> a consistent format. So if my app uses the Serialize instances that
> come with cereal, it could sud
> Speaking of that Double instance... both data-binary and cereal use
> decodeFloat and encodeFloat which mean they suffer from the same
> problems as realToFrac, namely that -0 becomes 0 and NaN becomes
> -Infinity (I'm not sure why the latter happens since the decoded
> values differ... must be a
It's been remarked to me that relying on the Binary and Serialize
classes is dangerous, because there's no guarantee they won't maintain
a consistent format. So if my app uses the Serialize instances that
come with cereal, it could suddenly fail to read old saves after an
upgrade to cereal.
Howev
