mneumann / rust-msgpack

[DEPRECATED] msgpack.org implementation for Rust language. Please use https://github.com/3Hren/msgpack-rust

⚠️ WARNING: This is no longer maintained nor works with current versions of Rust! Please use https://github.com/3Hren/msgpack-rust instead.

rust-msgpack

Msgpack implementation for Rust language.

Installation

Simply include the rust-msgpack in your Cargo dependencies.

[dependencies.msgpack]

git = "[email protected]:mneumann/rust-msgpack.git"

Quickstart

extern crate msgpack;

fn main() {
  let arr = vec!["str1".to_string(), "str2".to_string()];
  let str = msgpack::Encoder::to_msgpack(&arr).ok().unwrap();
  println!("Encoded: {}", str);

  let dec: Vec<String> = msgpack::from_msgpack(str).ok().unwrap();
  println!("Decoded: {}", dec);
}

To enable your own data structures to be automatically serialized from and to msgpack, derive from Encodable and Decodable as shown in the following example:

extern crate serialize;

#[deriving(Encodable,Decodable)]
struct MyStruct {
  a: Vec<u32>,
  s: String
}

Testing

cargo test

License

This code licensed under the same terms as Rust itself: dual MIT/Apache2 license options.

rust-msgpack's Issues

Travis builds failing since bbd93a7

All of your Travis builds have been failing since commit bbd93a7.
From the log:

$ rustc -v
rustc: error while loading shared libraries: librustc-4e7c5e5c.so: cannot open shared object file: No such file or directory
The command "rustc -v" failed and exited with 127 during .

Didn't see any sign of working towards a fix, thought I should point it out.

It doesn't compile with byteorder v1.2.1

Doesn't compile out of the box. There is error with byteorder::Error

error[E0433]: failed to resolve. Could not find Error in byteorder
--> src\lib.rs:712:38
|
712 | Err(e) => Err(byteorder::Error::Io(e))
| ^^^^^ Could not find Error in byteorder

msgpack-rpc

I'm just wondering how to use the msgpack-rpc code that's in the repository, or
if that's a work-in-progress?

Out of touch with master.

rust-lang/rust@5a68892 is the last rust/master tag to work for me with the most recent copy of rust-msgpack from forked projects.

Build without rustpkg

rustpkg has been removed by rust-lang/rust@25fe2ca. Until we have new package managers, we have to build rust-msgpack using make.

port to rust 1.0.0 alpha

Is it possible to get rust-msgpack updated to latest Rust version?

Differentiate between [u8] and binary.

[u8] will be encoded as arrays of integers, which is not very efficient as every byte potentially needs two bytes. It would be better to encode it as a msgpack binary (when supported). But with the current Decodable trait this seems to be not possible as we cannot specialize code for a specific element type.

A solution is to introduce a type binary = [u8].

Nullary option variants corrupt the next element in the decoder.

If an Option<T> is enclosed inside some other type (struct, enum, map, tuple, etc.) and the None variant is present: the element following the decoded None will be read as a nil since the nil-byte is still in the stream.

This is because read_option uses _peek_byte() to determine if a nil value is in the stream but it does not consume that byte if a None was present. Thus when the next token is read from the stream it will be read as a nil.

This can be fixed by simply consuming the nil if we successfully read a None variant.
I added a test and fix on my fork: feature/fix-option-nullary however it will be blocked on PR #39 being merged.

Build is broken against nightly

I was trying to fix it here:
https://github.com/achanda/rust-msgpack/commits/master

However, my rust-fu is too weak to get past what I already have. Will appreciate some help. I can open a PR if necessary.

Add enum support.

It'd be nice to be able to make use of enums - it's a feature I used with capnp that was quite helpful for weird datastructure shenanigans. Opening an issue to collect thoughts before I give it a stab.

Support the new spec for msgpack

rust-msgpack only partially supports the new spec. The new spec is not fully backwards compatible, so provide a way to conform to either specification.

Value is not Decodable after the move to associated types

I have a branch that has been tracking rustc-serialize: drbawb/rust-msgpack/feature/rustc-serialize

After the latest changes to the serialize crate (see rust-lang/rust/pull/20514) I have been having lots of issues adopting the current architecture of the library to use associated types.

The biggest hurdle is that the signature of Decodable has changed to the following:

pub trait Decodable {
    fn decode<D: Decoder>(d: &mut D) -> Result<Self, D::Error>;
}

Where D is bound by the trait serialize::Decoder.

This means that inside the decode function we do not have access to the concrete msgpack::Decoder<R> any more.

The previous definition of serialize::Decodable for Value relied on calling the msgpack::Decoder::decode_value() method, which is obviously not accessible through the Decoder trait.

I can't see any way to get access to the concrete decoder.
I even tried std::mem::transmute but because the type parameters for the underlying Reader is also removed from the serialize::Decoder trait: we lack the necessary type information to perform such a cast.

---

It would appear that the only option left is to re-implement msgpack::Decoder#decode_value() in terms of the generic serialize::Decoder trait.

Structs are encoded w/ map type but are not valid msgpack maps!

I've been doing interop with other msgpack libraries this weekend, namely the official msgpack-javascript.

The problem is that we currently call _emit_map_len() before encoding a Rust struct into the stream.
This pops the msgpack type fixmap (0x8<len>) onto the stream.

However when encoding struct fields we only encode the value of the field, which means this is not a valid msgpack map entry.

I have a fix for this over on my fork (though it's written on top of PR #39): feature/fix-struct-interop

The fix involves emitting the field-name when encoding; and reading/checking the field-name when decoding.

---

Again this only affects non-Rust readers: as they are expecting a map-key where one is not present. In my experience this means the fixmap is decoded into a single key (containing all the bytes of the struct) and then the rest of the stream is corrupted.

Would such a fix be welcome? Though it changes the semantics of how we're encoding structs?

Register with Travis CI

See http://hiho.io/rust-ci/

Necessary steps: http://hiho.io/rust-ci/help/

Fails to pack/unpack

Here is a test case:

#[test]
fn test_circular_str_vec() {
    let mut v: Vec<String> = Vec::new();
    v.push("VPRYWQT-JW47HTA-Y2ZTRGH-7MF2DGU-FY2X6E2-N3DKDRF-KCFBN4W-KOX4ZQ7".to_string());

    assert_msgpack_circular!(v);
}

I'm not sure what is so special about this string as initial test with "test" worked correctly.

Build failing on serialise::Decoder trait

I'm getting the following error message when building:

src/lib.rs:255:1: 477:2 error: not all trait methods implemented, missing: `error` [E0046]
src/lib.rs:255 impl<'a> serialize::Decoder<IoError> for Decoder<'a> {
src/lib.rs:256     #[inline(always)]

I am very new to rust. First code written today. This patch fixes the build error but I've no idea what the correct implementation is. That IoError line is partially copied from further up the file:

diff --git a/src/lib.rs b/src/lib.rs
index 9b23b89..28e2146 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -474,6 +474,10 @@ impl<'a> serialize::Decoder<IoError> for Decoder<'a> {
         -> IoResult<T> {
             self.read_tuple_arg(idx, f)
         }
+
+    fn error(&mut self, _err: &str) -> IoError {
+        IoError{kind: InvalidInput, desc: "", detail: None}
+    }
 }

 impl<'a> serialize::Decodable<Decoder<'a>, IoError> for Value {

An example from the rust code base can be seen here:

https://github.com/rust-lang/rust/blob/5bd8edc1121a5736994d69b2dc9cf3efb6fbc116/src/libserialize/json.rs#L2076

From the commit history, it looks like it was added 3 days ago. Possibly merged even more recently.

Thanks for writing the msgpack support.

Mark this library as deprecated

It doesn't work with recent versions of byteorder and it uses rustc-serialize (which is deprecated in favor of Serde).

To avoid new users troubles, this library should be marked as deprecated in favor of https://crates.io/crates/rmp-serde

Clone Trait

Is there any reason why instances of msgpack::Value aren't clonable?

Doesn't compile with the latest rust

As of rustc 0.12.0-pre-nightly (5419b2ca2 2014-08-29 22:16:20 +0000):

Compiling msgpack v0.0.1 (file:///home/derek/code/rust/rust-msgpack)
/home/derek/code/rust/rust-msgpack/src/lib.rs:492:17: 492:27 error: explicit lifetime bound required
/home/derek/code/rust/rust-msgpack/src/lib.rs:492     wr: &'a mut io::Writer
                                                                  ^~~~~~~~~~
error: aborting due to previous error
Could not compile `msgpack`

Publish to crates.io

It would be great if rust-msgpack was available on https://crates.io

Support rust enums

Hi,

is there any reason why enums are not supported?
I know there is no Enum type in Msgpack spec, but it seems to me there is a realy simple workaround.
Enum type can be decomposed into its variant index (uint) and rest of data whatever they are.

I have already tested it and it seems to work.
PR?

Does not compile with rustc 1.7.0

Complains about #![feature(slice_splits)] not available on stable channel.

The version 0.1.0 on crates.io does not compile either.

Improve documentation

task '<main>' failed at 'called `Option::unwrap()` on a `None` value'

I'm probably doing this all wrong, but this fails:

extern crate serialize;
extern crate msgpack;

#[deriving(Encodable,Decodable)]
struct MyStruct {
  a: Vec<u32>,
  s: String
}

fn main() {
    let m = MyStruct{ a: vec![1u32, 5], s: "hi".to_string()};

    let enc =  msgpack::Encoder::to_msgpack(&m).ok().unwrap();
    println!("{}",&enc); //[130, 146, 1, 5, 162, 104, 105]
    let dec: msgpack::Value = msgpack::from_msgpack(enc).ok().unwrap();
    println!("{}", &dec);
}

Won't Compile with rustc 1.15.0-nightly (8f02c429a 2016-12-15)

A lot of "error[E0412]: type name byteorder::Error is undefined or not in scope" errors, plus a few others.

Earlier I tried it with stable but that wasn't happy either: "error[E0554]: #[feature] may not be used on the stable release channel", something about "#![feature(slice_splits)]".

Is this library getting left behind? (Is there a newer msgpack Rust library that I should try instead?)

Thanks,

-kb