Open emk opened 7 years ago
i guess this is the blog post you're talking about.
i just tried cargo run --example images
and hit the error.
it seems that the Size
field of struct Image
should be an i64
instead of a u64
.
docker daemon (1.13.0-rc4 on macos sierra) returns -1
for the size and the image's size in contained in VirtualSize
.
well, i've just upgraded docker and with 1.13.0-rc7 Size
and VirtualSize
are now equal.
go figure...
I'm very happy to accept PRs fixing any of the parts of boondock we're not currently using, and I'll try to answer any questions. Unfortunately I'm dealing with some other Docker-related tools this week and next, but I can try to find time.
do you plan on using serde when macro 1.1 lands in stable? (should be soon)
Because instead of using an i64
, maybe having an Option
or a Result
for handling the -1
case would be better, but doing so with rustc_serialize just before a Serde port isn't a good idea.
Yeah, I'm generally in favor of serde, and very enthusiastic about Macros 1.1. Good stuff.
Serde has some weaknesses if you need to do tricky custom serialization; the APIs at that level are fairly baroque.
Right now, the boondock data structures very closely mirror the underlying Docker types. The underlying Docker types are terrible and poorly documented. But I'm not sure it will be easy to convert them to nice, well-behaved Rust types.
First time I see someone complain about serde... it's normally treated as a godsend.
Anyways, the tricky custom serialization stuff, is it done better in rustc_serialize?
The following example programs currently fail with JSON parse errors:
See the forthcoming blog post about how to debug these.