On Wednesday, 8 April 2015 at 09:58:31 UTC, Sönke Ludwig wrote:
>
> 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).

from experience: Hardly anybody reads previous posts. comments on the source make it easier for you to get useful criticism and filter all the noise.

> 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.

I thought more performance was one of the major reason for the json replacement. We need graphs!

On Wednesday, 8 April 2015 at 09:58:31 UTC, Sönke Ludwig wrote:
> 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.

I made a note, will see if I time to help with that. Algebraic might be a problem as it's based on typeinfo not tags, just a wild guess though.

On Wednesday, 8 April 2015 at 07:14:32 UTC, Iain Buclaw wrote:
> I assume you cleared your dub cache and didn't try linking a dmd built
> library to a gdc/ldc application.  :)
>
> Iain.

I tried it with dub clean, dub --force, even removed std_data_json package to clone it again, but no success.

Here is a full dub build -v output: http://pastebin.com/yHV3gYcX

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

It seems the `in` operator (or an equivalent method) isn't supported...

On 8 April 2015 at 12:39, tcha via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Wednesday, 8 April 2015 at 07:14:32 UTC, Iain Buclaw wrote:
>>
>> I assume you cleared your dub cache and didn't try linking a dmd built library to a gdc/ldc application.  :)
>>
>> Iain.
>
>
> I tried it with dub clean, dub --force, even removed std_data_json package to clone it again, but no success.
>
> Here is a full dub build -v output: http://pastebin.com/yHV3gYcX

I find these undefined references frankly bizarre  (undefined reference to std.math.pow?) - can you reduce these with dustmite?

Iain.

Am 08.04.2015 um 12:34 schrieb Martin Nowak:
> On Wednesday, 8 April 2015 at 09:58:31 UTC, Sönke Ludwig wrote:
>> 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.
>
> I made a note, will see if I time to help with that. Algebraic might be
> a problem as it's based on typeinfo not tags, just a wild guess though.

The problem is that even the pull parser alone is relatively slow. Also, for some reason the linker reports unresolved symbols as soon as I build without the -debug flag...

Am 08.04.2015 um 12:52 schrieb "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>":
> 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
>>
>
> It seems the `in` operator (or an equivalent method) isn't supported...

I didn't try it, but the idea is that all operations on JSONValue are supported by std.variant.Algebraic, so anything that doesn't work, but should, should be fixed with a PR against Algebraic.

On 4/7/15 5:43 PM, Dicebot 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
>>
>
> If no one else steps up, I can do it after DConf.

Thanks. I think it would be great if we moved faster with this - any chance that you or someone else starts this before DConf such that we get to vote during DConf? That'd be pretty cool. -- Andrei

On Wednesday, 8 April 2015 at 13:56:55 UTC, Sönke Ludwig wrote:
> The problem is that even the pull parser alone is relatively slow. Also, for some reason the linker reports unresolved symbols as soon as I build without the -debug flag...

Unfortunatelly I overlooked that I tested it with std_data_json v 0.12.0 yesterday.
So tested it again today on master:
dmd and gdc failed to build in release
ldc2 works

I tried it also with ParseJSONStream and made fork from original benchmark with added tests (https://github.com/chalucha/benchmarks) so anyone can look (and PR)

Some results:
Ruby - 6.74s, 2106.2Mb
Go - 5.92s, 420.9Mb
D - 10.26s, 1322.5Mb
D Gdc - 24.76s, 926.1Mb
D Ldc - 26.31s, 925.0Mb
D new - debug - 14.98s, 1782.0Mb
D new Gdc - debug - 29.08s, 1663.9Mb
D new Ldc - 16.99s, 1663.0Mb
D new lazy - debug - 11.50s, 213.2Mb
D new lazy Gdc - debug - 13.66s, 206.1Mb
D new lazy Ldc - 3.59s, 205.4Mb
Python - 5.89s, 1063.4Mb
C++ Boost - 14.60s, 2884.8Mb
C++ Rapid - 0.80s, 678.9Mb


Also tried to dustmite the minimal failing version and here is a result: http://pastebin.com/YjdvT3G4

It's my first use of it so I hope it can help to solve this problem. It outputs less errors, but also compiles fine in debug and fails to link in release.

On 8 April 2015 at 20:32, tcha via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Wednesday, 8 April 2015 at 13:56:55 UTC, Sönke Ludwig wrote:
>>
>> The problem is that even the pull parser alone is relatively slow. Also, for some reason the linker reports unresolved symbols as soon as I build without the -debug flag...
>
>
> Unfortunatelly I overlooked that I tested it with std_data_json v 0.12.0
> yesterday.
> So tested it again today on master:
> dmd and gdc failed to build in release
> ldc2 works
>
> I tried it also with ParseJSONStream and made fork from original benchmark
> with added tests (https://github.com/chalucha/benchmarks) so anyone can look
> (and PR)
>
> Some results:
> Ruby - 6.74s, 2106.2Mb
> Go - 5.92s, 420.9Mb
> D - 10.26s, 1322.5Mb
> D Gdc - 24.76s, 926.1Mb
> D Ldc - 26.31s, 925.0Mb
> D new - debug - 14.98s, 1782.0Mb
> D new Gdc - debug - 29.08s, 1663.9Mb
> D new Ldc - 16.99s, 1663.0Mb
> D new lazy - debug - 11.50s, 213.2Mb
> D new lazy Gdc - debug - 13.66s, 206.1Mb
> D new lazy Ldc - 3.59s, 205.4Mb
> Python - 5.89s, 1063.4Mb
> C++ Boost - 14.60s, 2884.8Mb
> C++ Rapid - 0.80s, 678.9Mb
>
>
> Also tried to dustmite the minimal failing version and here is a result: http://pastebin.com/YjdvT3G4
>
> It's my first use of it so I hope it can help to solve this problem. It outputs less errors, but also compiles fine in debug and fails to link in release.

Frankly, if we are not as fast (or elegant) as Python's json library, it should be thrown out back to the drawing board.

Iain.