edma2 / clojure-msgpack Goto Github PK

It would be great to have keys generate as keywords. Maybe upon applying some flag. This would be similar to how Cheshire will unpack to keywords.

Would be nice to take advantage of laziness

When serializing ints, we figure out how to pack it based on the size of the input, not the input type itself. But we always (incorrectly) assume that the size of the input fits in a 64-bit value. To reproduce:

(seq (pack 0xfffffffffffffffffN)) ; => nil

We get back nil because pack-int does a no-op since none of the cases match, so we get an empty output stream.

Perhaps it's an issue with how this library is referenced in clojars, but i'm unable to use this with lein try.
I tried : lein try clojure-msgpack , lein try edma2/clojure-msgpack, lein try clojure-msgpack/clojure-msgpack and they all fail.
In the meantime other libraries work, for example: lein try reiddraper/simple-check or lein try clj-msgpack.
Update: i'm not sure if it's related to sonatype ? sonatype_ops tweet

In my opition, the main purpose of msgpack library is converting an object to msgpack-formatted byte-array or a byte-array to an object.

But msgpack.core/pack returns (seq (.toByteArray output-stream)). Why do you need use 'seq' here?
In older version of clojure-msgpack simplly returned a msgpack-formatted byte-array.

In 1.0.0, I need to convert the seq into a byte-array again before sending it into network...

current: 1.6.0
latest: 1.8.0 (stable)

I have a record like this:

(defrecord Foo [a b])

and I would like to make it serializable, like this:

(extend-msgpack
  Foo
  21
  [v] (msgpack/pack (into {} v))
  [bytes] (map->Foo (msgpack/unpack bytes)))

However, this causes undefined behavior because a Foo record is also an IPersistentMap. Sometimes the record gets serialized correctly, sometimes it gets serialized as a simple map.

What's the best solution to this problem?

Currently project.clj specifies version 1.5.1.

Could you please add a compatibility switch to force clojure-msgpack to create str16 serializations instead of str8.

Hi,
Thanks for writing this library. We needed to switch to binary data transmission for an IOT project involving lots of real-time data, and this helped a lot. In order to create a full solution that we could use with Sente over websockets to transmit binary typed arrays from a Clojure server to a Clojurescript web app, I needed to use both this library as well as the msgpack-cljs here: https://github.com/pkcsecurity/msgpack-cljs, which credits you for doing the initial hard work. Well, I'm now unifying them both to share common interfaces and extension points. This lets us program against them identically, and more importantly, I'd like to test and verify that we have shared Clojure types, typed arrays, dates and times, etc., which work seamlessly between server and client. To do this I've pulled the cljs lib into clojure-msgpack, and then done some refactoring of both. I wanted to reach out to you to see if you are still interested in maintaining this library and accepting this update, or whether I should just publish a new library? If so, I'm happy to give you guys all the credit for doing the hard work, and it would be great if you could link to the new library so we don't have a confusing set of libs for the Clojure community to have to navigate.

My current work is here: https://github.com/rosejn/clojure-msgpack/tree/cljc and we are using this live today so it's up and running. I've still got work to do to make the cljs code extensible using the same macro as this library, but I already extended both sides to support the full set of typed arrays. I'll go ping the other author as well, and I look forward to your reply. Thanks!

Linter produces a lot of warnings. Run lein eastwood to see them.

Hi,
Could you provide some information about the version of the spec that's implemented? I'm trying to unpack some test data, previously packed from Clojure, in, e.g., Python, and the result I get is just a literal 0.

Here's the example of the output (assuming the data is stored in a redis db):

Its generally bad practice to include snapshot versions in releases. Any thoughts on removing the snapshot version and releasing a 0.1.0 version?

Also, I'd like to get your latest changes for reflection removal, any idea when it might be pushed to clojars?

As of the head of master at this time (ca1d7cb), sometimes encoding a double will decode as a float.
The simplest example of this is as such:

msgpack.core> (class (unpack (pack (double 1/3))))
;; => java.lang.Float

I would have expected this to come back as a double.