The spec defines the encoding profiles, e.g. prohibit binary (we don't need it, binary support is our main motivation to consider moving to MessagePack), or restrict key types to strings (this is actually something we need).

Any view on how it could be added?

As seen on the stackage build server:

Preprocessing executable 'msgpack-parser' for data-msgpack-0.0.5...
[1 of 1] Compiling Main             ( tools/msgpack-parser.hs, dist/build/msgpack-parser/msgpack-parser-tmp/Main.o )
Linking dist/build/msgpack-parser/msgpack-parser ...
Preprocessing benchmark 'benchmark' for data-msgpack-0.0.5...
[1 of 1] Compiling Main             ( bench/benchmark.hs, dist/build/benchmark/benchmark-tmp/Main.o )

bench/benchmark.hs:6:1: error:
    Failed to load interface for ‘Data.MessagePack.IntBench’
    Perhaps you meant
      Data.MessagePack.Instances (from data-msgpack-0.0.5)
      Data.MessagePack.Object (from data-msgpack-0.0.5)
      Data.MessagePack.Spec (needs flag -package-key messagepack-0.5.3)
    Use -v to see a list of the files searched for.

bench/benchmark.hs:7:1: error:
    Failed to load interface for ‘Data.MessagePackBench’
    Perhaps you meant
      Data.MessagePack (from data-msgpack-0.0.5)
      Data.MessagePack (needs flag -package-key messagepack-0.5.3)
      Data.MessagePack.Get (from data-msgpack-0.0.5)
    Use -v to see a list of the files searched for.

How I reproduced this locally:

$ stack unpack data-msgpack-0.0.5
$ cd data-msgpack
$ stack init --resolver nightly-2016-10-24
$ stack build --bench

Changed in TokTok/hs-msgpack-types#3. Please update the tests. Perhaps we need to move these tests into the -types package.

Is there an adaptor for Aeson that works with this fork?

msgpack-aeson wants another library

could help call-haskell-from-anything get on stackage.

I'm trying to unpack msgpack into my type that has no lists:

data UniverseView = UniverseView
	{ planets :: Object
	, star_systems :: Object
	, current_id :: Object
	, empires :: Object
	, planets_in_star_systems :: Object
	, starlanes :: Object
	, star_systems_in_empires :: Object
	, ships :: Object
	, ships_in_star_systems :: Object
	, ships_in_empires :: Object
	, controlled_empire :: Object
	--, turn_number :: Word
	, turn_number :: Object
	} deriving (Show, Eq, Generic)

instance MessagePack UniverseView

On running my program, i get this:

*** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace: 
  Data.MessagePack.unpack,
  called from Main.rpc,
  called from Main.main
test: user error (invalid encoding for list)

This behaviour seems incorrect. The code employed is

	decRetVal <- unpack $ BL.fromStrict retVal
	--print $ (decRetVal :: Object)
	print $ (decRetVal :: UniverseView)

It woks ok if i decode it as an Object. The printed Object has a top-level array with the same number of items as my data type: http://dpaste.com/0F6045T

You broke compatibility multiple times on minor release, this is pretty bad.

Plus, you remove Object, Get and Put from the public module and I really don't see the reason (could this be explained in a changelog maybe?).

It's enough for me, i decided to use packer-messagepack instead.

https://hackage.haskell.org/package/packer-messagepack

Currently, records and tuples are encoded the same way. Reordering or adding fields in records will break the serialisation format. We could add an option to use field names as map indices. This would only break if fields are renamed. We could also add an option to be lax about accepting input: extra fields are ignored. To be lax about missing fields, we would need to require a Default instance for every field type, effectively making MessagePack a subclass of Default.

We should check that the tarball produced by cabal sdist actually includes all source files, including all test and bench sources.

We are currently tied to the binary package for serialisation. While very elegant, it may not be the best performing binary serialisation library. store seems to be faster. By separating the types and the specific serialiser, we can give the user a choice, and we can provide at least two implementations: one correct one (the existing one) and one fast one. We can then do random quickcheck-style equivalence testing between the two to make sure the fast one is also correct.

I was trying to update some old code which was still using the msgpack package, so I tried switching to this fork. I see the MessagePack class now has

fromObject :: (Applicative m, Monad m) => Object -> m a

instead of

fromObject :: Object -> Maybe a

Can you explain the rationale for this change? I see no reason why fromObject needs to work polymorphically over all monads, it has nothing to do with monads at all! You end up using just the fail method for all your instances. At best, you could change Maybe a to Either Error a using an Error datatype.

Would be nice to have them. Original msgpack lib used Data.Vector for arrays.

Would you release a new version?

I don't think so. Float to Double is perfectly fine, but not vice versa.

First of all, you should not actually use Float in haskell code :)
https://wiki.haskell.org/Performance/Floating_point

https://github.com/msgpack/msgpack/blob/master/spec.md#types-limitation

a value of an Integer object is limited from -(2^63) upto (2^64)-1

This implementation stores it in Int64, which won't adequately represent Unsigned Integers, which are greater than (2^63) - 1.

Add a test that generates random messagepack objects and serialises them with both data-msgpack and msgpack-c, checking whether they are the same. Do the same for deserialisation.

Hi.

data-msgpack depends on the package groom, which is used only in the msgpack-parser executable. groom is a heavy dependency since it pulls in haskell-src-exts.

Can you get away without groom? I suppose it's a too high price to pay for exactly one usage.

Why is there a magic transformation of Ints to Words in putInt: https://github.com/TokTok/hs-msgpack-binary/blob/master/src/Data/MessagePack/Put.hs#L75

This is not according to spec and means data serialized with putInt can't be deserialized with getInt.

This case is special and IMO should be implemented this way. Otherwise this realization will be useful for Haskell to Haskell communications only.

Original msgpack package instantiated it like that, so why did you change that?

Hackage version doesn't contain commit which adds MessagePack instance for Either as well commit for Void by @Martoon-00. They are very useful, so it would be cool to see them on hackage ASAP.

@robinlinden fill in thoughts here.