Git Product home page Git Product logo

msgpack.jl's Introduction

MsgPack.jl

MsgPack.jl is a MessagePack implementation in pure Julia, inspired by JSON3.jl. This package supports:

  • (de)serialization of Julia values to/from MessagePack (see pack and unpack)
  • overloadable pre-(de)serialization transformations (see from_msgpack and to_msgpack)
  • automatic type construction/destruction (see msgpack_type, construct, and StructType)
  • some basic immutable "views" over MsgPack-formatted byte buffers (see ArrayView and MapView).
  • native Serialization.serialize support via MessagePack Extensions (see Extension, extserialize, and extdeserialize)

pack/unpack

Use pack to serialize Julia values to MessagePack bytes, and unpack to deserialize MessagePack bytes to Julia values:

julia> bytes = pack(["hello", Dict(:this => 1, ['i', 's'] => 3.14, "messagepack!" => nothing)])
42-element Array{UInt8,1}:
 0x92
 0xa5
 0x68
 

julia> unpack(bytes)
 2-element Array{Any,1}:
  "hello"
  Dict{Any,Any}("messagepack!" => nothing,"this" => 0x01,Any["i", "s"] => 3.14)

pack and unpack also accept IO streams as arguments:

julia> io = IOBuffer();

julia> pack(io, "see it really does take an IO stream");

julia> unpack(seekstart(io))
"see it really does take an IO stream"

Translating between Julia and MessagePack types

By default, MsgPack defines (de)serialization between the following Julia and MessagePack types:

MessagePack Type AbstractMsgPackType Subtype Julia Types
Integer IntegerType UInt8, UInt16, UInt32, UInt64, Int8, Int16, Int32, Int64
Nil NilType Nothing, Missing
Boolean BooleanType Bool
Float FloatType Float32, Float64
String StringType AbstractString, Char, Symbol
Array ArrayType AbstractArray, AbstractSet, Tuple
Map MapType AbstractDict, NamedTuple
Binary BinaryType (no defaults)
Extension ExtensionType (no defaults)

To support additional Julia types, we can define that type's "translation" to its corresponding AbstractMsgPackType via the following methods:

julia> using MsgPack, UUIDs

# declare `UUID`'s correspondence to the MessagePack String type
julia> MsgPack.msgpack_type(::Type{UUID}) = MsgPack.StringType()

# convert UUIDs to a MessagePack String-compatible representation for serialization
julia> MsgPack.to_msgpack(::MsgPack.StringType, uuid::UUID) = string(uuid)

# convert values deserialized as MessagePack Strings to UUIDs
julia> MsgPack.from_msgpack(::Type{UUID}, uuid::AbstractString) = UUID(uuid)

julia> unpack(pack(uuid4()))
"df416048-e513-41c5-aa49-32623d5d7e1f"

julia> unpack(pack(uuid4()), UUID)
UUID("4812d96f-bc7b-434b-ac54-1985a1263882")

Note that each subtype of AbstractMsgPackType makes its own assumptions about the return values of to_msgpack and from_msgpack; these assumptions are documented in the subtype's docstring. For additional details, see the docstrings for AbstractMsgPackType, msgpack_type, to_msgpack, and from_msgpack.

Automatic struct (de)serialization

MsgPack provides an interface that facilitates automatic, performant (de)serialization of MessagePack Maps to/from Julia structs. Like JSON3.jl, MsgPack's interface supports two different possibilities: a slower approach that doesn't depend on field ordering during deserialization, and a faster approach that does:

julia> using MsgPack

julia> struct MyMessage
           a::Int
           b::String
           c::Bool
       end

julia> MsgPack.msgpack_type(::Type{MyMessage}) = MsgPack.StructType()

julia> messages = [MyMessage(rand(Int), join(rand('a':'z', 10)), rand(Bool)) for _ in 1:3]
3-element Array{MyMessage,1}:
 MyMessage(4625239811981161650, "whosayfsvb", true)
 MyMessage(4988660392033153177, "mazsmrsawu", false)
 MyMessage(7955638288702558596, "gueytzhjvy", true)

julia> bytes = pack(messages);

# slower, but does not assume struct field ordering
julia> unpack(bytes, Vector{MyMessage})
3-element Array{MyMessage,1}:
 MyMessage(4625239811981161650, "whosayfsvb", true)
 MyMessage(4988660392033153177, "mazsmrsawu", false)
 MyMessage(7955638288702558596, "gueytzhjvy", true)

# faster, but assumes incoming struct fields are ordered
julia> unpack(bytes, Vector{MyMessage}; strict=(MyMessage,))
 3-element Array{MyMessage,1}:
  MyMessage(4625239811981161650, "whosayfsvb", true)
  MyMessage(4988660392033153177, "mazsmrsawu", false)
  MyMessage(7955638288702558596, "gueytzhjvy", true)

Do not use strict=(T,) unless you can ensure that all MessagePack Maps corresponding to T maintain the exact key-value pairs corresponding to T's fields in the exact same order as specified by T's Julia definition. This property generally cannot be assumed unless you, yourself, were the original serializer of the message.

For additional details, see the docstrings for StructType, unpack, and construct.

Immutable, lazy Julia views over MessagePack bytes

Often, one will want to delay full deserialization of a MessagePack collection, and instead only deserialize elements upon access. To facilitate this approach, MsgPack provides the ArrayView and MapView types. Reusing the toy MyMessage from the earlier example:

julia> using BenchmarkTools

julia> bytes = pack([MyMessage(rand(Int), join(rand('a':'z', 10)), rand(Bool)) for _ in 1:10_000_000]);

# deserialize the whole thing in one go
julia> @time x = unpack(bytes, Vector{MyMessage});
  3.547294 seconds (20.00 M allocations: 686.646 MiB, 13.42% gc time)

# scan bytes to tag object positions, but don't fully deserialize
julia> @time v = unpack(bytes, MsgPack.ArrayView{MyMessage});
  0.462374 seconds (14 allocations: 76.295 MiB)

# has normal `Vector` access performance, since it's a normal `Vector`
julia> @btime $x[1]
  1.824 ns (0 allocations: 0 bytes)
MyMessage(-5988715016767300083, "anrcvpbqge", true)

# access time is much slower, since element is deserialized upon access
julia> @btime $v[1]
  274.990 ns (4 allocations: 176 bytes)
MyMessage(-5988715016767300083, "anrcvpbqge", true)

For additional details, see the docstrings for ArrayView and MapView.

Should I use JSON or MessagePack?

Use JSON by default (with the lovely JSON3 package!), and only switch to MessagePack if you actually measure a significant performance benefit from doing so. In my experience, the main potential advantage of MessagePack is improved (de)serialization performance for certain kinds of structures. If you merely seek to reduce message size, MessagePack has little advantage over JSON, as general-purpose compression seems to achieve similar sizes when applied to either format.

msgpack.jl's People

Contributors

ararslan avatar bclrk avatar binarybana avatar dependabot[bot] avatar dstahlke avatar femtocleaner[bot] avatar jameswrigley avatar jrevels avatar juliatagbot avatar kmsquire avatar nhynes avatar ranocha avatar rdeits avatar sbillig avatar sean1708 avatar simondanisch avatar sjkelly avatar staticfloat avatar tkelman avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

msgpack.jl's Issues

Move to JuliaIO organization

Cc: @IainNZ, @WestleyArgentum

Julia Web seems like a more appropriate place for this. Iain and Westley seem to be the only members, currently--would you be okay with that?

Assuming so, it would be good if @sbillig, @binarybana, and myself still had commit access to the repo, if not the organization.

(As an aside, have you considered inviting others to the organization? If they're interested, @astrieanna, @zachallaun, and @danielmendel come to mind--I believe they were the originators of the webstack.)

very slow to pack/unpack integer array

Julia 0.4.1
CentOS 6

Compared to a float array, integer array is brutally slow. Note the 72 million allocations...

julia> bigun = rand(1000000);

julia> @time MsgPack.pack(bigun);
WARNING: uint32(x) is deprecated, use UInt32(x) instead.
in depwarn at deprecated.jl:73
in uint32 at deprecated.jl:50
in pack at /dd/home/mewert/.julia/v0.4/MsgPack/src/MsgPack.jl:287
in pack at /dd/home/mewert/.julia/v0.4/MsgPack/src/MsgPack.jl:173
while loading no file, in expression starting on line 155
0.262886 seconds (316 allocations: 17.622 MB, 1.16% gc time)

julia> @time MsgPack.pack(bigun);
0.257133 seconds (102 allocations: 17.614 MB)

julia> bigun = collect(1:1000000);

julia> @time MsgPack.pack(bigun);
WARNING: uint32(x) is deprecated, use UInt32(x) instead.
in depwarn at deprecated.jl:73
in uint32 at deprecated.jl:50
in pack at /dd/home/mewert/.julia/v0.4/MsgPack/src/MsgPack.jl:287
in pack at /dd/home/mewert/.julia/v0.4/MsgPack/src/MsgPack.jl:173
while loading no file, in expression starting on line 155
WARNING: uint32(x) is deprecated, use UInt32(x) instead.
in depwarn at deprecated.jl:73
in uint32 at deprecated.jl:50
in pack at /dd/home/mewert/.julia/v0.4/MsgPack/src/MsgPack.jl:204
in pack at /dd/home/mewert/.julia/v0.4/MsgPack/src/MsgPack.jl:293
in pack at /dd/home/mewert/.julia/v0.4/MsgPack/src/MsgPack.jl:173
while loading no file, in expression starting on line 155
107.134147 seconds (72.01 M allocations: 598.657 GB, 14.76% gc time)

Register as an official package?

I'm wondering if you are planning to, or are interested in, submitting this as an official Julia package? I haven't used it yet, but need it for an upcoming project.

Unable to add in support for Complex values as expanded into arrays

I'm trying to serialize and deserialize complex values in a similar fashion to how it is done with Rust's num-complex + rmp-serde packages

  • expanding ComplexF32 to an array of Float32
  • expanding ComplexF64 to an array of Float64

As an example, num-complex in Rust will generate the following bytes for 1.1 + 0.1im:
[0x92, 0xcb, 0x3f, 0xf1, 0x99, 0x99, 0x99, 0x99, 0x99, 0x9a, 0xcb, 0x3f, 0xb9, 0x99, 0x99, 0x99, 0x99, 0x99, 0x9a]

I'm trying to do the same with Julia with the following piece of code

MsgPack.msgpack_type(::Type{Complex{Float32}}) = MsgPack.ArrayType()
MsgPack.msgpack_type(::Type{Complex{Float64}}) = MsgPack.ArrayType()
MsgPack.to_msgpack(::MsgPack.ArrayType, arr::Complex{Float32}) = [real(arr), imag(arr)]
MsgPack.to_msgpack(::MsgPack.ArrayType, arr::Complex{Float64}) = [real(arr), imag(arr)]
MsgPack.from_msgpack(::Type{Complex{Float32}}, arr::Vector{Float32}) = Complex{Float32}(arr[1], arr[2])
MsgPack.from_msgpack(::Type{Complex{Float64}}, arr::Vector{Float64}) = Complex{Float64}(arr[1], arr[2])

I can successfully generate the same bytes with this

julia> val
1.1 + 0.1im
julia> pack(val)
19-element Vector{UInt8}:
 0x92
 0xcb
.... (more stuff here)
julia> unpack(pack(val))
2-element Vector{Any}:
 1.1
 0.1

but unpack(pack(val), ComplexF64) fails with this

julia> unpack(pack(val), ComplexF64)
ERROR: invalid byte 0xcb encountered in IOBuffer(data=UInt8[...], readable=true, writable=false, seekable=true, append=false, size=19, maxsize=Inf, ptr=3, mark=-1) attempting to read a MsgPack MsgPack.ArrayType() into a Julia ComplexF64 at position 2
Stacktrace:
  [1] error(s::String)
    @ Base ./error.jl:33
  [2] invalid_unpack(io::IOBuffer, byte::UInt8, m::MsgPack.ArrayType, T::Type)
    @ MsgPack ~/.julia/packages/MsgPack/pN9xd/src/unpack.jl:543
  [3] unpack_type(io::IOBuffer, byte::UInt8, t::MsgPack.ArrayType, ::Type{ComplexF64}; strict::Tuple{})
    @ MsgPack ~/.julia/packages/MsgPack/pN9xd/src/unpack.jl:396
  [4] _unpack_array(io::IOBuffer, n::UInt8, #unused#::Type{ComplexF64}, strict::Tuple{})
    @ MsgPack ~/.julia/packages/MsgPack/pN9xd/src/unpack.jl:411
  [5] unpack_format(io::IOBuffer, f::MsgPack.ArrayFixFormat, #unused#::Type{ComplexF64}, strict::Tuple{})
    @ MsgPack ~/.julia/packages/MsgPack/pN9xd/src/unpack.jl:402
  [6] unpack_type(io::IOBuffer, byte::UInt8, t::MsgPack.ArrayType, ::Type{ComplexF64}; strict::Tuple{})
    @ MsgPack ~/.julia/packages/MsgPack/pN9xd/src/unpack.jl:390
  [7] unpack(io::IOBuffer, ::Type{ComplexF64}; strict::Tuple{})
    @ MsgPack ~/.julia/packages/MsgPack/pN9xd/src/unpack.jl:32
  [8] unpack(bytes::Vector{UInt8}, ::Type{ComplexF64}; strict::Tuple{})
    @ MsgPack ~/.julia/packages/MsgPack/pN9xd/src/unpack.jl:8
  [9] unpack(bytes::Vector{UInt8}, ::Type{ComplexF64})
    @ MsgPack ~/.julia/packages/MsgPack/pN9xd/src/unpack.jl:8
 [10] top-level scope
    @ REPL[46]:1

What am I doing wrong here?

implement a `StructView{T}` type

Similar to MapView, there should be a StructView{T} type that allows lazy, well-typed field access via getproperty. Then, users can really nicely stage the laziness of MsgPack's decoding/copying for their use case. For example, a Vector{StructView{T}} would eagerly "tape" all structs in the buffer, whereas ArrayView{StructView{T}} would only "tape" the array containing the structs, and let the structs themselves be "taped" only upon access, etc.

Unsafe string unpacking causes segmentation fault

MsgPack v1.2.0

julia> using MsgPack

julia> unpack(UInt8[0xdb, 0x05, 'a', 'b', 'c', 'd', 'e'])

[754821] signal (11.2): Segmentation fault
in expression starting at REPL[2]:1
__memcpy_sse2_unaligned_erms at /lib64/libc.so.6 (unknown line)
ijl_pchar_to_string at /cache/build/default-amdci5-2/julialang/julia-release-1-dot-9/src/array.c:523
unsafe_string at ./strings/string.jl:81 [inlined]
from_msgpack at /home/kirill/.julia/packages/MsgPack/AnkMB/src/types.jl:437 [inlined]
_unpack_string at /home/kirill/.julia/packages/MsgPack/AnkMB/src/unpack.jl:353
unpack_format at /home/kirill/.julia/packages/MsgPack/AnkMB/src/unpack.jl:341 [inlined]
#_unpack_any#10 at /home/kirill/.julia/packages/MsgPack/AnkMB/src/unpack.jl:83
_unpack_any at /home/kirill/.julia/packages/MsgPack/AnkMB/src/unpack.jl:49
unknown function (ip: 0x7f8ce8165f8a)
_jl_invoke at /cache/build/default-amdci5-2/julialang/julia-release-1-dot-9/src/gf.c:2758 [inlined]
ijl_apply_generic at /cache/build/default-amdci5-2/julialang/julia-release-1-dot-9/src/gf.c:2940
#unpack_type#9 at /home/kirill/.julia/packages/MsgPack/AnkMB/src/unpack.jl:47
unknown function (ip: 0x7f8ce8163060)
unpack_type at /home/kirill/.julia/packages/MsgPack/AnkMB/src/unpack.jl:47 [inlined]
#unpack#7 at /home/kirill/.julia/packages/MsgPack/AnkMB/src/unpack.jl:32 [inlined]
unpack at /home/kirill/.julia/packages/MsgPack/AnkMB/src/unpack.jl:32 [inlined]
#unpack#6 at /home/kirill/.julia/packages/MsgPack/AnkMB/src/unpack.jl:8 [inlined]
unpack at /home/kirill/.julia/packages/MsgPack/AnkMB/src/unpack.jl:8 [inlined]
#unpack#5 at /home/kirill/.julia/packages/MsgPack/AnkMB/src/unpack.jl:1 [inlined]
unpack at /home/kirill/.julia/packages/MsgPack/AnkMB/src/unpack.jl:1
unknown function (ip: 0x7f8ce8162fc2)
_jl_invoke at /cache/build/default-amdci5-2/julialang/julia-release-1-dot-9/src/gf.c:2758 [inlined]
ijl_apply_generic at /cache/build/default-amdci5-2/julialang/julia-release-1-dot-9/src/gf.c:2940
jl_apply at /cache/build/default-amdci5-2/julialang/julia-release-1-dot-9/src/julia.h:1879 [inlined]
do_call at /cache/build/default-amdci5-2/julialang/julia-release-1-dot-9/src/interpreter.c:126
eval_value at /cache/build/default-amdci5-2/julialang/julia-release-1-dot-9/src/interpreter.c:226
eval_stmt_value at /cache/build/default-amdci5-2/julialang/julia-release-1-dot-9/src/interpreter.c:177 [inlined]
eval_body at /cache/build/default-amdci5-2/julialang/julia-release-1-dot-9/src/interpreter.c:624
julia> versioninfo()
Julia Version 1.9.2
Commit e4ee485e909 (2023-07-05 09:39 UTC)
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: 16 × AMD Ryzen 7 3700X 8-Core Processor
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-14.0.6 (ORCJIT, znver2)
  Threads: 16 on 16 virtual cores
Environment:
  JULIA_NUM_THREADS = auto

Packing Dict{Symbol,Any} corrupts data

Reproducer:

julia> bad = Dict{Symbol,Any}(:wake_after_sleep_onset => 0, :wake_after_sleep_onset_percentage => 1)
Dict{Symbol,Any} with 2 entries:
  :wake_after_sleep_onset            => 0
  :wake_after_sleep_onset_percentage => 1

julia> io = IOBuffer();

julia> pack(io, bad)

julia> seekstart(io);

julia> unpack(io, Dict{Symbol,Any})
Dict{Symbol,Any} with 2 entries:
  :wake_after_sleep_onset => 0x00
  :wake_after_sleep       => 0x5f

The keys are truncated and the values are wrong. Also note that the value assigned to the key :wake_after_sleep is the code point for an underscore, which would be the continuation of the key name were it completely consumed.

The problem seems to be specific to packing Symbols, as packing as String and unpacking as Symbol works fine:

julia> ok = Dict{String,Any}("wake_after_sleep_onset" => 0, "wake_after_sleep_onset_percentage" => 1)
Dict{String,Any} with 2 entries:
  "wake_after_sleep_onset"            => 0
  "wake_after_sleep_onset_percentage" => 1

julia> io = IOBuffer();

julia> pack(io, ok)

julia> seekstart(io);

julia> unpack(io, Dict{Symbol,Any})
Dict{Symbol,Any} with 2 entries:
  :wake_after_sleep_onset            => 0x00
  :wake_after_sleep_onset_percentage => 0x01

allow field ordering assumptions to be specified at `unpack` callsite

After exercising the current interface on downstream code, I've realized it's often annoying that field ordering assumptions are specified globally (via overloading MsgPack.msgpack_type on a given type) rather than at the time unpack is called. It's led to me adopting a somewhat ugly anti-pattern of defining both Foo and MutableFoo types for every Julia struct I'd like to (de)serialize so that I can switch between both as needed (e.g. internal messages that my code authors vs. unordered messages received from the outside world).

I've thought about writing a @define_serializable macro that auto-generates both "versions" of a type given a single struct definition, but that seems like it'd have lots of edge cases and would just be a band-aid over the real issue.

Ideally, we'd able to just call e.g. unpack(io, Vector{Ordered{T}}) (or something similar) where Ordered is more of a tag that informs unpack to dispatch to order-optimized methods, and otherwise we'd wouldn't assume ordering guarantees.

Of course, constructor assumptions would still need to hold, but maybe the (currently implemented, but unused/undocumented) MsgPack.construct wrapper could help there.

cc @quinnj who may have interesting thoughts about this

collaboration with MsgPack2

Hello!

I've been working on https://github.com/beacon-biosignals/MsgPack2.jl, which is basically MsgPack.jl re-implemented with JSON3-like features. I'm still writing tests, need to add a manual to the README, etc., but was wondering if there'd be any interest in simply replacing this package's implementation with the new one (getting rid of the separate MsgPack2 repo altogether)?

The main benefit would be to avoid duplicating maintainer efforts and avoid the slightly confusing situation for users that's arose with e.g. having multiple JSON packages. However, it is a drastically different implementation compared to the current one (it'd definitely require a major version bump), so I'd understand if folding it into here would be undesirable 🙂

If the maintainer here (@kmsquire, it seems?) is amenable to this idea and gives me access to this repo, I can open up a PR to fold MsgPack2 into here in a week or so (I still need to finish docs + tests + beacon-biosignals/MsgPack2.jl#8) and take on a maintainer role. Let me know what you think!

Irrational{S} support missing

Serialization of the type Irrational{S} is missing. For example:

julia> pack(pi)
ERROR: no non-`AnyType` MsgPack mapping found for Irrational{}; please overload `msgpack_type` for this type.

I think most users are not aware that pi is not simply the floating point representation of pi, therefore expecting that if you can pack a float, you can also pack pi.

I would propose to add the following to the package:

MsgPack.msgpack_type(::Type{Irrational{S}}) where S = MsgPack.FloatType()
MsgPack.to_msgpack(::MsgPack.FloatType, x::Irrational{S}) where S = float(x)

I could prepare a PR, if you find this useful.

ExtensionType API incomplete

Is the API for supporting MsgPack extensions complete?

(So as not to waste anyone's time, note that this is an adaptation of a question on Discourse.)

I am trying to write the Julia end of an RPC-over-RabbitMQ relationship. The other side (written in Ruby) uses a MsgPack extension for dates. I receive this:

MsgPack.Extension(1, UInt8[0x07, 0xe6, 0x02, 0x1c])

I can make my end send this with pack, but I can’t make my end convert this to a Date with unpack. This is what I have so far, based on the documentation for MsgPack.ExtensionType:

module test_msg_pack_ext

using Dates
using MsgPack
using Test

function pack_date(date::Date)::MsgPack.Extension
        year_u16 = convert(UInt16, year(date))
        year_hi = UInt8(year_u16 >> 8)
        year_lo = UInt8(year_u16 << 8 >> 8)
        return MsgPack.Extension(0x01, UInt8[year_hi, year_lo, month(date), day(date)])
end

function unpack_date(ext::MsgPack.Extension)::Date
        year = ext.data[1] << 8 | ext.data[2]
        return Date(year, ext.data[3], ext.data[4])
end

MsgPack.msgpack_type(::Type{Dates.Date}) = MsgPack.ExtensionType()
MsgPack.to_msgpack(::MsgPack.ExtensionType, date::Dates.Date) = pack_date(date)
MsgPack.from_msgpack(::Type{Dates.Date}, ext::MsgPack.Extension) = unpack_date(ext)

@test pack(MsgPack.Extension(1, UInt8[0x07, 0xe6, 0x02, 0x1c])) == pack(Date(2022, 2, 28))
@test Date(2022, 2, 28) == unpack(UInt8[0xd6, 0x01, 0x07, 0xe6, 0x02, 0x1c])
    
end

# =>
engine/msg_pack_ext.jl: Test Failed at .../msg_pack_ext.jl:25
  Expression: Date(2022, 2, 28) == unpack(UInt8[0xd6, 0x01, 0x07, 0xe6, 0x02, 0x1c])
   Evaluated: Dates.Date("2022-02-28") == MsgPack.Extension(1, UInt8[0x07, 0xe6, 0x02, 0x1c])

That makes sense to me. I haven’t done anything to map extension type 1 to my code. But I can't see anything in the MsgPack code or test suite that lets me do this. The discussion in #7 makes it look like the contributor was satisfied with receiving a MsgPack.Extension and handling it themselves?

Support packing / unpacking of complex numbers

I just started using MsgPack for some IPC with C# program. It works quite well, and simplified my life a lot. Thanks a lot for this implementation.

I am now facing an issue with MsgPack, which is of course not restricted to julia, but by default MsgPAck it does not support complex numbers (de)serialization. As julia is very much science oriented, don't you think it would be great to support such types using a specific extension type ?

It seems some python implementation supports this https://github.com/lekma/mood.msgpack.

I would gladly help implement this, though I would need some pointers as to what should be the strategy here.

TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Mistake in README

The warning in the README about the typesafety of integers is still correct in general, but the note about this being important for dictionaries is not. Since Julia now hashes integer values (no matter the type) as being the same, this is not a big concern for dictionaries:

julia> isequal(5,uint64(5))
true

julia> hash(5)
0x0583d46ff02a00ec

julia> hash(uint8(5))
0x0583d46ff02a00ec

[PkgEval] MsgPack may have a testing issue on Julia 0.4 (2014-09-29)

PackageEvaluator.jl is a script that runs nightly. It attempts to load all Julia packages and run their tests (if available) on both the stable version of Julia (0.3) and the nightly build of the unstable version (0.4). The results of this script are used to generate a package listing enhanced with testing results.

On Julia 0.4

  • On 2014-09-28 the testing status was Tests pass.
  • On 2014-09-29 the testing status changed to Tests fail, but package loads.

Tests pass. means that PackageEvaluator found the tests for your package, executed them, and they all passed.

Tests fail, but package loads. means that PackageEvaluator found the tests for your package, executed them, and they didn't pass. However, trying to load your package with using worked.

This error on Julia 0.4 is possibly due to recently merged pull request JuliaLang/julia#8420.
This issue was filed because your testing status became worse. No additional issues will be filed if your package remains in this state, and no issue will be filed if it improves. If you'd like to opt-out of these status-change messages, reply to this message saying you'd like to and @IainNZ will add an exception. If you'd like to discuss PackageEvaluator.jl please file an issue at the repository. For example, your package may be untestable on the test machine due to a dependency - an exception can be added.

Test log:

>>> 'Pkg.add("MsgPack")' log
INFO: Installing MsgPack v0.0.1
INFO: Package database updated

>>> 'using MsgPack' log
Julia Version 0.4.0-dev+842
Commit e5d8c1a (2014-09-29 06:50 UTC)
Platform Info:
  System: Linux (x86_64-unknown-linux-gnu)
  CPU: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

>>> test log

ERROR: test error in expression: ck_pack(2^32,[0xcf,0x00,0x00,0x00,0x01,0x00,0x00,0x00,0x00])
InexactError()
 in pack at /home/idunning/pkgtest/.julia/v0.4/MsgPack/src/MsgPack.jl:172
 in ck_pack at /home/idunning/pkgtest/.julia/v0.4/MsgPack/test/runtests.jl:4
 in anonymous at test.jl:85
 in do_test at test.jl:47
 in include at ./boot.jl:245
 in include_from_node1 at loading.jl:128
 in process_options at ./client.jl:285
 in _start at ./client.jl:354
 in _start_3B_3625 at /home/idunning/julia04/usr/bin/../lib/julia/sys.so
while loading /home/idunning/pkgtest/.julia/v0.4/MsgPack/test/runtests.jl, in expression starting on line 10
INFO: Testing MsgPack
===============================[ ERROR: MsgPack ]===============================

failed process: Process(`/home/idunning/julia04/usr/bin/julia /home/idunning/pkgtest/.julia/v0.4/MsgPack/test/runtests.jl`, ProcessExited(1)) [1]

================================================================================
INFO: No packages to install, update or remove
ERROR: MsgPack had test errors
 in error at error.jl:21
 in test at pkg/entry.jl:719
 in anonymous at pkg/dir.jl:28
 in cd at ./file.jl:20
 in cd at pkg/dir.jl:28
 in test at pkg.jl:68
 in process_options at ./client.jl:213
 in _start at ./client.jl:354
 in _start_3B_3625 at /home/idunning/julia04/usr/bin/../lib/julia/sys.so


>>> end of log

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.