Re: Cerealed v0.6.1: even less boilerplate for binary serialization
On Monday, 3 August 2015 at 09:40:59 UTC, Atila Neves wrote:
In this case, yes. In the real-life case I was simplifying, it
wasn't a ubyte[] array, it was an array of structs with
non-trivial serialisation that also depended on a previous
deserialised variable. It was more like this:
struct Outer {
static struct Header { ... }
Header header;
@LengthInBytes(length - headerSize) Inner[] array;
}
struct Inner {
static struct Header { ... }
Header header;
@ArrayLength(length) Unit[] units; //actual length of the
array instead of in bytes
}
struct Unit { ... }
So maybe not as useless after all ;)
Atila
Thanks. Very nice indeed.
Re: Cerealed v0.6.1: even less boilerplate for binary serialization
On 03/08/15 14:21, Per =?UTF-8?B?Tm9yZGzDtnci?= per.nord...@gmail.com wrote: Are there any plans to add different backends (for instance msgpack) to Cereal? Then we could have one package to rule them all! That would be Orange [1]. Hopefully I'll get it into Phobos at some point. [1] https://github.com/jacob-carlborg/orange -- /Jacob Carlborg
Re: Seattle D meetup
On 8/3/2015 10:24 AM, Colden Cullen wrote: On Sunday, 2 August 2015 at 22:53:00 UTC, Walter Bright wrote: Seeing the threads on London, Silicon Valley and Berlin meetups, is there any interest for a Seattle one? Yes please! Myself and a good portion of the Dash[1] team are in Seattle now, and we'd love to get to know other D users. [1] http://dash.circularstudios.com/ I had no idea you guys were in town! Cool! Do you have an office in town, or are just visiting?
Re: Cerealed v0.6.1: even less boilerplate for binary serialization
On 8/3/2015 4:46 AM, Atila Neves wrote: On Monday, 3 August 2015 at 11:13:50 UTC, Walter Bright wrote: On 8/3/2015 2:21 AM, Atila Neves wrote: [...] Please put this as the first comment on the reddit post. Which one? The one you started the thread with. On a more meta note, when people look at a discussion on reddit and see zero comments, they move on. Having a comment there saying briefly what the link is about and why the reader might be interested in it is far more effective at getting readers to spend some time reading your article. It also gives you an opportunity to shape the discussion in a direction you'd like. If some troll makes the first post, it sets a trollish tone and can completely ruin all the effort you put into the article. Don't leave things to chance!
Re: Seattle D meetup
Colden Cullen coldencul...@gmail.com writes: On Sunday, 2 August 2015 at 22:53:00 UTC, Walter Bright wrote: Seeing the threads on London, Silicon Valley and Berlin meetups, is there any interest for a Seattle one? Yes please! Myself and a good portion of the Dash[1] team are in Seattle now, and we'd love to get to know other D users. [1] http://dash.circularstudios.com/ I too would be interested. BTW - for Seattle/PNW folks, Living Computer Museum is hosting a fun event on Aug 15. http://www.livingcomputermuseum.org/FreePlay -- Dan
Re: Cerealed v0.6.1: even less boilerplate for binary serialization
On Monday, 3 August 2015 at 09:21:50 UTC, Atila Neves wrote:
The summary is you can now write this:
struct UdpPacket {
static struct Header {
ushort srcPort;
ushort dstPort;
ushort length;
ushort checksum;
}
enum headerSize = unalignedSizeof!Header;
alias header this;
Header header;
@LengthInBytes(length - headerSize) ubyte[] data;
}
This deserialization will be identical to casting like this,
right? (Not trying to diminish your work, just making sure I get
semantics :))
align(1)
struct UdpPacket
{
align(1)
static struct Header {
ushort srcPort;
ushort dstPort;
ushort length;
ushort checksum;
}
Header header;
ubyte[0] data;
}
// ...
auto packet = cast(UdpPacket*) raw_data.ptr;
Re: Cerealed v0.6.1: even less boilerplate for binary serialization
On Monday, 3 August 2015 at 09:27:03 UTC, Dicebot wrote:
On Monday, 3 August 2015 at 09:21:50 UTC, Atila Neves wrote:
The summary is you can now write this:
struct UdpPacket {
static struct Header {
ushort srcPort;
ushort dstPort;
ushort length;
ushort checksum;
}
enum headerSize = unalignedSizeof!Header;
alias header this;
Header header;
@LengthInBytes(length - headerSize) ubyte[] data;
}
This deserialization will be identical to casting like this,
right? (Not trying to diminish your work, just making sure I
get semantics :))
align(1)
struct UdpPacket
{
align(1)
static struct Header {
ushort srcPort;
ushort dstPort;
ushort length;
ushort checksum;
}
Header header;
ubyte[0] data;
}
// ...
auto packet = cast(UdpPacket*) raw_data.ptr;
In this case, yes. In the real-life case I was simplifying, it
wasn't a ubyte[] array, it was an array of structs with
non-trivial serialisation that also depended on a previous
deserialised variable. It was more like this:
struct Outer {
static struct Header { ... }
Header header;
@LengthInBytes(length - headerSize) Inner[] array;
}
struct Inner {
static struct Header { ... }
Header header;
@ArrayLength(length) Unit[] units; //actual length of the
array instead of in bytes
}
struct Unit { ... }
So maybe not as useless after all ;)
Atila
Re: Beta D 2.068.0-b2
On 08/02/2015 11:20 AM, Rainer Schuetze wrote: Unfortunately, that does not help a lot because Microsoft changed their C runtime quite a bit to make it more compliant to C99. This causes unresolved symbols when linking phobos. You think we can work that out soon enough? https://issues.dlang.org/show_bug.cgi?id=14849#c7 It seems that we need to link to a certain flavor of the runtime.
Re: Beta D 2.068.0-b2
On Sunday, 2 August 2015 at 09:20:44 UTC, Rainer Schuetze wrote: On 31.07.2015 02:41, Joseph Cassman wrote: [...] I just updated my VS2015 installation and can confirm the error message regarding libucrt.lib. I found the library in the folder c:\Program Files (x86)\Windows Kits\10\Lib\10.0.10150.0\ucrt\x64. You can add it to the library search paths in Tools-Options-Projects and Solutions-Visual D-DMD Directories-x64. Unfortunately, that does not help a lot because Microsoft changed their C runtime quite a bit to make it more compliant to C99. This causes unresolved symbols when linking phobos. Very cool. That change to the C runtime also explains some of the errors I was getting. Thanks for the explanation. Joseph
Re: Russian-speaking community
On Sunday, 2 August 2015 at 17:20:57 UTC, Suliman wrote: On Sunday, 2 August 2015 at 12:11:03 UTC, Majestio wrote: On Tuesday, 30 June 2015 at 20:39:38 UTC, lomereiter wrote: (whose domain is much easier to remember, btw) We have already moved to http://dlanguage.ru Sorry for long reviving of http://dlang.ru but we almost end work at it's engine. Now you may see, that it's become very fast. I hope that it will will be open on next week. All *major* bugs are fixed. There is only minors, about most of them I know. Please do not start using it until I get approve from CMS developer. Also I have plan to revive dsource.org on our CMS. It's very powerful, and can be used as collective forum and blog. So When we will test it, I will try to contact with dsource admins and suggest them to move site to our CMS. Also if anybody want to help, you may help with site design. Two sites are better than none. Cure your site and we will work together. Once your site is all in working order, please write announce on our site. We need to think about cooperation.
Re: Cerealed v0.6.1: even less boilerplate for binary serialization
On Monday, 3 August 2015 at 12:21:05 UTC, Per Nordlöw wrote: On Monday, 3 August 2015 at 11:51:24 UTC, Atila Neves wrote: Yes. `cerealise` and `decerealise`. The former is slightly weird for performance reasons. It takes a lambda that tells it what to do with the resulting bytes. Close with LDC and DMD, faster with GDC: http://forum.dlang.org/post/nkcelouzpjsgmqtvn...@forum.dlang.org Nice! Are there any plans to add different backends (for instance msgpack) to Cereal? Then we could have one package to rule them all! I'll try Cereal in favor of msgpack next time! Thanks, Atila! As I tried the changes on the same test as in [0] It went on my PC like this: DMD debug: Cerealed: 2 secs, 854 ms, 687 μs, and 2 hnsecs MsgPack: 2 secs, 328 ms, 698 μs, and 3 hnsecs DMD release: Cerealed: 1 sec, 619 ms, 570 μs, and 9 hnsecs MsgPack: 1 sec, 554 ms, and 185 μs LDC2 release: Cerealed: 966 ms, 398 μs, and 4 hnsecs MsgPack: 926 ms, 792 μs, and 3 hnsecs GDC release: Cerealed: 1 sec, 97 ms, 892 μs, and 1 hnsec MsgPack: 1 sec, 138 ms, 359 μs, and 2 hnsecs So it's almost the same now. [0] http://forum.dlang.org/post/nkcelouzpjsgmqtvn...@forum.dlang.org
Re: Cerealed v0.6.1: even less boilerplate for binary serialization
On Monday, 3 August 2015 at 11:43:15 UTC, Per Nordlöw wrote:
On Monday, 3 August 2015 at 09:21:50 UTC, Atila Neves wrote:
http://code.dlang.org/packages/cerealed
What's new?
* Performance improvements
* New UDAs for networking packets for even less required
boilerplate
The first new thing is self-explanatory. The second one is
explained briefly in this blog post:
https://www.reddit.com/r/programming/comments/3flnlt/cerealed_a_d_library_for_declarative_binary/
(also on HN but you know how that goes)
The summary is you can now write this:
struct UdpPacket {
static struct Header {
ushort srcPort;
ushort dstPort;
ushort length;
ushort checksum;
}
enum headerSize = unalignedSizeof!Header;
alias header this;
Header header;
@LengthInBytes(length - headerSize) ubyte[] data;
}
Code? Who needs code when the compiler can write it for you?
Atila
1. Are there any convenience functions similar to msgpack's
pack() and unpack() providing compactness and elegance as
import msgpack;
auto x = [1,2];
assert(x.pack.unpack!typeof(x) == x);
Yes. `cerealise` and `decerealise`. The former is slightly weird
for performance reasons. It takes a lambda that tells it what to
do with the resulting bytes.
import cerealed;
auto x = MyStruct();
x.cerealise!(bytes = writeln(bytes));
ubyte[] bytes = [...];
auto x = bytes.decerealise!MyStruct;
2. How does the Cereal performance compare to Msgpack after the
recent optimizations?
Close with LDC and DMD, faster with GDC:
http://forum.dlang.org/post/nkcelouzpjsgmqtvn...@forum.dlang.org
I haven't even tried optimising it myself though, I just merged a
contribution from someone else.
Atila
Re: Cerealed v0.6.1: even less boilerplate for binary serialization
On Monday, 3 August 2015 at 10:37:05 UTC, Dmitry Olshansky wrote:
On 03-Aug-2015 12:27, Dicebot wrote:
On Monday, 3 August 2015 at 09:21:50 UTC, Atila Neves wrote:
[...]
This deserialization will be identical to casting like this,
right? (Not
trying to diminish your work, just making sure I get semantics
:))
align(1)
struct UdpPacket
{
align(1)
static struct Header {
ushort srcPort;
ushort dstPort;
ushort length;
ushort checksum;
}
Header header;
ubyte[0] data;
}
// ...
auto packet = cast(UdpPacket*) raw_data.ptr;
Plus/minus network byte order.
Oh yeah, and that. Cerealed always does network order.
Atila
Re: Cerealed v0.6.1: even less boilerplate for binary serialization
On Monday, 3 August 2015 at 11:13:50 UTC, Walter Bright wrote: On 8/3/2015 2:21 AM, Atila Neves wrote: [...] Please put this as the first comment on the reddit post. Which one? Atila
Re: Cerealed v0.6.1: even less boilerplate for binary serialization
On Monday, 3 August 2015 at 11:51:24 UTC, Atila Neves wrote: Yes. `cerealise` and `decerealise`. The former is slightly weird for performance reasons. It takes a lambda that tells it what to do with the resulting bytes. Close with LDC and DMD, faster with GDC: http://forum.dlang.org/post/nkcelouzpjsgmqtvn...@forum.dlang.org Nice! Are there any plans to add different backends (for instance msgpack) to Cereal? Then we could have one package to rule them all! I'll try Cereal in favor of msgpack next time! Thanks, Atila!
Re: Cerealed v0.6.1: even less boilerplate for binary serialization
On Monday, 3 August 2015 at 09:21:50 UTC, Atila Neves wrote:
http://code.dlang.org/packages/cerealed
What's new?
* Performance improvements
* New UDAs for networking packets for even less required
boilerplate
The first new thing is self-explanatory. The second one is
explained briefly in this blog post:
https://www.reddit.com/r/programming/comments/3flnlt/cerealed_a_d_library_for_declarative_binary/
(also on HN but you know how that goes)
The summary is you can now write this:
struct UdpPacket {
static struct Header {
ushort srcPort;
ushort dstPort;
ushort length;
ushort checksum;
}
enum headerSize = unalignedSizeof!Header;
alias header this;
Header header;
@LengthInBytes(length - headerSize) ubyte[] data;
}
Code? Who needs code when the compiler can write it for you?
Atila
1. Are there any convenience functions similar to msgpack's
pack() and unpack() providing compactness and elegance as
import msgpack;
auto x = [1,2];
assert(x.pack.unpack!typeof(x) == x);
2. How does the Cereal performance compare to Msgpack after the
recent optimizations?
Re: Cerealed v0.6.1: even less boilerplate for binary serialization
On Monday, 3 August 2015 at 12:21:05 UTC, Per Nordlöw wrote: On Monday, 3 August 2015 at 11:51:24 UTC, Atila Neves wrote: Yes. `cerealise` and `decerealise`. The former is slightly weird for performance reasons. It takes a lambda that tells it what to do with the resulting bytes. Close with LDC and DMD, faster with GDC: http://forum.dlang.org/post/nkcelouzpjsgmqtvn...@forum.dlang.org Nice! Are there any plans to add different backends (for instance msgpack) to Cereal? Then we could have one package to rule them all! I've thought about that (and even JSON or XML) but I'm not 100% convinced that it would work with the existing, and more importantly to me, not high on my list of priorities. I'm definitely not opposed to it. I'll try Cereal in favor of msgpack next time! Thanks, Atila! Glad to be useful. :) Atila
