Congrats, it's a really well done package!
The new release is available!
**NESM v0.4.0**
* * *
**Additions:**
* Added the size option for the custom periodic structures deserialization.
(allows to read the dynamic periodic structure length from other field instead
of default behavior)
* Added the sizeof options for the custom peri
@cdunn2001, looks like you already know the difference between msgpack and
NESM. But I will give add some information.
msgpack is a well defined protocol, the spec dictates you how to serialize
number, the endianess, how many bytes should be used, etc, etc. An msgpack
library author need to mak
Oh, I think I get it now. You can provide `proc serialize(MyType)` whenever you
want to control exactly how an object is serialized. That's the trick, to make
it as flexible as possible. Nice!
**@cdunn2001**, well, it looks like I haven't made my point clear. Let me show
you another example. One day I needed to repack the Unity3d assets file of a
third-party game. So, I've written [the Unity3d asserts
packer](https://gist.github.com/xomachine/8e0218477c81c55c70d7defa89a80633#file-layo
**@janko**, msgpack4nim is your work, right? Could you explain the difference
between that and NESM?
> [https://github.com/jangko/msgpack4nim](https://github.com/jangko/msgpack4nim)
**@xomachine**, I have to say, even if your architecture is better in some way,
I still wish that the NESM binary
**@cdunn2001** msgpack just can not cover all the fields that NESM does. For
example deserialization of third-party file format or make a model of IP packet.
[Here](https://github.com/FedericoCeratto/NESM/blob/6b08b33ff82a5d5b7eec166c6d7427446ceab75a/demos/ntp.nim)
is a little demo of NTP packet
Honest question: Why not just use _msgpack_? E.g.
*
[https://github.com/jangko/msgpack4nim](https://github.com/jangko/msgpack4nim)
You could argue that a serializer retains object types, but since Nim is not a
dynamic language, I don't see the value of that. And I see tremendous value in
u
**@Araq** thanks! Your feedback is highly appreciated!
**@jangko** well, as far as I can understand you want something like this:
from mycode import MyType
from nesm import serialize
... # there is no code generation of the serialize procedure for MyType
let obj = MyType
> (for example, doesn't have a field of type Socket/File/stream/callbacks)
in this case, user intervention is needed, but using non-intrusive serializer,
the intervention is minimal.
And the code to manage this special case can be put among the other serializer
routines, no need to modify the s
> But if the serializer also support non-intrusive mode, I don't need to modify
> my huge library. I just need to serialize it and done.
But you need to ensure it's actually serializable anyway (for example, doesn't
have a field of type Socket/File/stream/callbacks) so you gain very little. In
Awesome work, I hope I can try it soon.
looks like this is a kind of intrusive serializer. I usually avoid using
intrusive serializer and prefer non-intrusive one. But I believe your library
can be modified to support non-intrusive mode too, because you already using
macros, and Nim macros can easily handle non-intrusive serializer.
Hello, Nim community!
I'd like to introduce you my little serialization library that allows to
perform [de]serialization of objects in two steps:
Step 1: annotate your object as **serializable** or convert it to
**serializable** via **toSerializable** macro
serializable:
typ
14 matches
Mail list logo
