Wanted: Review manager for std.data.json

On Tuesday, 7 April 2015 at 16:37:15 UTC, Sönke Ludwig wrote:
> Anyone up to this? The issues of the previous discussion [1] have all been addressed now more or less, so the package is ready for a more thorough review.
>
> Code: https://github.com/s-ludwig/std_data_json
> Docs: http://s-ludwig.github.io/std_data_json/
>
> [1]: http://forum.dlang.org/thread/lt5s76$is$1@digitalmars.com#post-lt5s76:24is:241:40digitalmars.com

Out of curiosity I tried to use this lib in lately discussed benchmark [1]

Original values on my machine (dmd 2.067, gdc 4.8.4, ldc2 0.15.1 llvm 3.5.1):
D - 10.22s, 1322.7Mb
D Gdc - 24.30s, 926.8Mb
D Ldc - 25.93s, 925.8Mb

With this lib it gets to [2]:
D - 7.48s, 1794.0Mb
Gdc and Ldc cannot build it with release (debug works) [3] and [4]

I also tried it with vibe.d's json [5]:
D - 44.77s, 2752.5Mb
D Gdc - 163.79s, 936.5Mb
D Ldc - 165.52s, 935.0Mb

So it seems that the new lib is a way to go.

As a newb to D I would like to know if there is a more elegant way to write:
auto coordinates = jval.get!(JSONValue[string])["coordinates"].get!(JSONValue[]);

and

x += val.opt("x").coerce!double;

I tried to fiddle with used JSONValue, Algebraic and VariantN things, but without success.
It's also weird (and undocumented in examples how to use the JSONValue other than in asserts) that this works:
JSONValue a = 12;
assert(a == 12.0);

and this is not:
long b = a;

I'd like if something like this can be possible:
auto coords = parseJson(text)["coordinates"];
foreach (val; coordinates) {
    x += val["x"].get!double;
    y += cast(double)val["y"];
    z += to!double(val["z"]);
  }

Also is there some way to use this lib for serialization and deserialization of normal objects? To use it like:
auto coords = parseJson(text)["coordinates"].map!(a=>cast(SomeStruct)a);


[1] https://github.com/kostya/benchmarks/tree/master/json
[2] http://pastebin.com/22xX6V0J
[3] http://pastebin.com/WshDpnQD
[4] http://pastebin.com/zj13Z7yG
[5] http://pastebin.com/FLLXBCe1

On Tuesday, 7 April 2015 at 16:37:15 UTC, Sönke Ludwig wrote: > Anyone up to this? The issues of the previous discussion [1] have all been addressed now more or less, so the package is ready for a more thorough review. > > Code: https://github.com/s-ludwig/std_data_json > Docs: http://s-ludwig.github.io/std_data_json/ > > [1]: http://forum.dlang.org/thread/lt5s76$is$1@digitalmars.com#post-lt5s76:24is:241:40digitalmars.com If no one else steps up, I can do it after DConf.

On 8 Apr 2015 00:05, "tcha via Digitalmars-d" <digitalmars-d@puremagic.com> wrote: > > On Tuesday, 7 April 2015 at 16:37:15 UTC, Sönke Ludwig wrote: >> >> Anyone up to this? The issues of the previous discussion [1] have all been addressed now more or less, so the package is ready for a more thorough review. >> >> Code: https://github.com/s-ludwig/std_data_json >> Docs: http://s-ludwig.github.io/std_data_json/ >> >> [1]: http://forum.dlang.org/thread/lt5s76$is$1@digitalmars.com#post-lt5s76:24is:241:40digitalmars.com > > > Out of curiosity I tried to use this lib in lately discussed benchmark [1] > > Original values on my machine (dmd 2.067, gdc 4.8.4, ldc2 0.15.1 llvm 3.5.1): > D - 10.22s, 1322.7Mb > D Gdc - 24.30s, 926.8Mb > D Ldc - 25.93s, 925.8Mb > > With this lib it gets to [2]: > D - 7.48s, 1794.0Mb > Gdc and Ldc cannot build it with release (debug works) [3] and [4] > I assume you cleared your dub cache and didn't try linking a dmd built library to a gdc/ldc application. :) Iain.

Any plan to support functions like these? http://forum.dlang.org/thread/lrknjl$co7$1@digitalmars.com?page=4#post-bcszdbasnjzmbwzdgeqy:40forum.dlang.org On Tuesday, 7 April 2015 at 16:37:15 UTC, Sönke Ludwig wrote: > Anyone up to this? The issues of the previous discussion [1] have all been addressed now more or less, so the package is ready for a more thorough review. > > Code: https://github.com/s-ludwig/std_data_json > Docs: http://s-ludwig.github.io/std_data_json/ > > [1]: http://forum.dlang.org/thread/lt5s76$is$1@digitalmars.com#post-lt5s76:24is:241:40digitalmars.com

On Wednesday, 8 April 2015 at 07:14:32 UTC, Iain Buclaw wrote: >> With this lib it gets to [2]: >> D - 7.48s, 1794.0Mb >> Gdc and Ldc cannot build it with release (debug works) [3] and [4] Have you tried to use the pull/stream parser?

Am 08.04.2015 um 11:05 schrieb Robert burner Schadek: > IMO this should be a PR for phobos so all comments to the code can be > collected in one location. > > Where is the benchmark against std.json and rapidjson? > That's what we have the review thread for. The library is now in a state that everyone can easily try out. If it were a Phobos PR, that would be much more difficult (or I'd have to maintain two versions in parallel). I still have to look into running a proper benchmark. Initial numbers that I just collected have not been as good as expected - I'll have to take a closer look at the compiler output.

Am 08.04.2015 um 10:24 schrieb Andrea Fontana: > Any plan to support functions like these? > > http://forum.dlang.org/thread/lrknjl$co7$1@digitalmars.com?page=4#post-bcszdbasnjzmbwzdgeqy:40forum.dlang.org There is opt() [1], which takes a path and returns a `Nullable!JSONValue`. "get" is unfortunately already taken by std.typecons.Algebraic, so we can't use it for its AA meaning. Maybe another overload of opt? JSONValue opt(JSONValue default_value, string[] path...); [1]: http://s-ludwig.github.io/std_data_json/stdx/data/json/value/json_value.opt.html

Am 08.04.2015 um 09:14 schrieb Iain Buclaw via Digitalmars-d: > > On 8 Apr 2015 00:05, "tcha via Digitalmars-d" > <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote: > > > > Out of curiosity I tried to use this lib in lately discussed > benchmark [1] > > > > Original values on my machine (dmd 2.067, gdc 4.8.4, ldc2 0.15.1 llvm > 3.5.1): > > D - 10.22s, 1322.7Mb > > D Gdc - 24.30s, 926.8Mb > > D Ldc - 25.93s, 925.8Mb > > > > With this lib it gets to [2]: > > D - 7.48s, 1794.0Mb > > Gdc and Ldc cannot build it with release (debug works) [3] and [4] > > > > I assume you cleared your dub cache and didn't try linking a dmd built > library to a gdc/ldc application. :) > > Iain. > DUB uses the path of the compiler binary, as well as the reported frontend version to distinguish builds of different compilers, so that clearing the cache shouldn't be necessary. But there are definitely performance issues. My own tests are far from what I would have expected, including for the pull parser...

Forums