On Monday, 27 July 2015 at 20:30:23 UTC, Sönke Ludwig wrote:
Am 27.07.2015 um 22:00 schrieb Atila Neves:
On Sunday, 26 July 2015 at 09:09:51 UTC, Sönke Ludwig wrote:
Am 07.04.2015 um 18:37 schrieb Sönke Ludwig:
[...]
So, since Dicebot has stepped down from his review manager
role, is
there
Am 28.07.2015 um 10:38 schrieb extrawurst:
On Monday, 27 July 2015 at 20:30:23 UTC, Sönke Ludwig wrote:
(...)
That'd be great, thanks! I *think* that's all (maybe also updating the
wiki) and since there is no other review going on, it should be
possible to start a new one now. But I also don't
On Wednesday, 8 April 2015 at 10:02:30 UTC, Sönke Ludwig wrote:
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
On 2015-07-28 11:23, Sönke Ludwig wrote:
Just found something:
http://wiki.dlang.org/Review/Process#Review_Manager
I would add making sure the review queue is updated.
--
/Jacob Carlborg
On Sunday, 26 July 2015 at 09:09:51 UTC, Sönke Ludwig wrote:
Am 07.04.2015 um 18:37 schrieb Sönke Ludwig:
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:
Am 27.07.2015 um 22:00 schrieb Atila Neves:
On Sunday, 26 July 2015 at 09:09:51 UTC, Sönke Ludwig wrote:
Am 07.04.2015 um 18:37 schrieb Sönke Ludwig:
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
Am 07.04.2015 um 18:37 schrieb Sönke Ludwig:
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/
On 2015-04-07 18:37, 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.
Is it possible to use toJSON or a similar method to generate JSON from
a primitive type without
Am 16.04.2015 um 11:17 schrieb Jacob Carlborg:
On 2015-04-07 18:37, 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.
Is it possible to use toJSON or a similar method
Am 16.04.2015 um 13:03 schrieb Jacob Carlborg:
On 2015-04-16 11:29, Sönke Ludwig wrote:
I'd like to let that be part of a more general serialization framework
in top of this package instead of integrating a simplistic custom
solution that will then later be obsoleted.
I was thinking about
On Wednesday, 8 April 2015 at 18:56:00 UTC, Iain Buclaw wrote:
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.
I'll leave the speed aside, as more recent posts show
improvements and I think Sönke will be able
On Thursday, 16 April 2015 at 12:17:55 UTC, Sönke Ludwig wrote:
Am 16.04.2015 um 13:03 schrieb Jacob Carlborg:
On 2015-04-16 11:29, Sönke Ludwig wrote:
I'd like to let that be part of a more general serialization
framework
in top of this package instead of integrating a simplistic
custom
On 2015-04-16 14:17, Sönke Ludwig wrote:
The simplest target for a serialization library would be to generate a
stream of JSONParserNodes. That way the serializer doesn't have to keep
track of nesting levels and can reuse the pretty printing functionality
of stdx.data.generator.
However, this
On 2015-04-16 11:29, Sönke Ludwig wrote:
I'd like to let that be part of a more general serialization framework
in top of this package instead of integrating a simplistic custom
solution that will then later be obsoleted.
I was thinking about some low level primitives that a serialization
On 2015-04-16 14:28, w0rp wrote:
I think serialiastion for this JSON library should probably be
considered out of scope until we have a general serisalisation API. Then
once we have both, we can marry the two together. So as you say, the
support from your end seems to be there. There just needs
On Friday, 10 April 2015 at 07:35:13 UTC, John Colvin wrote:
On Thursday, 9 April 2015 at 20:01:10 UTC, weaselcat wrote:
Also, since an LDC dev might read this - is there a reason
-singleobj isn't on by default when creating an executable?
I argued it should be the default a while ago and I
On Thursday, 9 April 2015 at 12:16:43 UTC, Martin Nowak wrote:
On 04/09/2015 02:10 PM, John Colvin wrote:
Still getting trounced across the board by rapidjson.
Yep, anyone knows why? They don't even use a lazy parser.
simd optimized scanning and format-optimized inlined conversion
Am 09.04.2015 um 21:40 schrieb Sönke Ludwig:
Am 09.04.2015 um 21:37 schrieb weaselcat:
On Thursday, 9 April 2015 at 19:35:24 UTC, Sönke Ludwig wrote:
Am 09.04.2015 um 21:26 schrieb weaselcat:
On Thursday, 9 April 2015 at 19:17:48 UTC, Sönke Ludwig wrote:
Not sure, but that may also have
On Thursday, 9 April 2015 at 11:49:00 UTC, Martin Nowak wrote:
On 04/08/2015 08:32 PM, tcha wrote:
Now with release numbers.
D new - debug - 14.98s, 1782.0Mb
8.53s, 1786.8Mb
D new Gdc - debug - 29.08s, 1663.9Mb
GDC still misses @nogc support.
D new Ldc - 16.99s, 1663.0Mb
18.76s, 1664.1Mb
Am 09.04.2015 um 21:37 schrieb weaselcat:
On Thursday, 9 April 2015 at 19:35:24 UTC, Sönke Ludwig wrote:
Am 09.04.2015 um 21:26 schrieb weaselcat:
On Thursday, 9 April 2015 at 19:17:48 UTC, Sönke Ludwig wrote:
Not sure, but that may also have been my recent optimizations.
Just tried it
On 04/09/2015 10:59 AM, Sönke Ludwig wrote:
As far as the profiler results can be trusted, a good chunk of the time
gets spent for reading individual bytes from memory, but there must be
something else low-level going on that make things this bad. However,
there is nothing fundamental in the
On 4/9/15 5:10 AM, John Colvin wrote:
On Thursday, 9 April 2015 at 11:49:00 UTC, Martin Nowak wrote:
On 04/08/2015 08:32 PM, tcha wrote:
Now with release numbers.
D new - debug - 14.98s, 1782.0Mb
8.53s, 1786.8Mb
D new Gdc - debug - 29.08s, 1663.9Mb
GDC still misses @nogc support.
D new
Am 08.04.2015 um 20:55 schrieb Iain Buclaw via Digitalmars-d:
On 8 April 2015 at 20:32, tcha via Digitalmars-d
digitalmars-d@puremagic.com wrote:
(...)
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
On Thursday, 9 April 2015 at 20:00:28 UTC, John Colvin wrote:
I can't remember which -O level inlining is enabled, but
there's definitely no need to explicitly ask for it at -O5.
-enable-inlining(enabled at -O2) and -inline do different things
and -inline isn't automatically enabled.
On 04/08/2015 03:56 PM, 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...
The review hasn't yet started and I'm already against the stream
parser,
On Thursday, 9 April 2015 at 19:40:31 UTC, Sönke Ludwig wrote:
Am 09.04.2015 um 21:37 schrieb weaselcat:
On Thursday, 9 April 2015 at 19:35:24 UTC, Sönke Ludwig wrote:
Am 09.04.2015 um 21:26 schrieb weaselcat:
On Thursday, 9 April 2015 at 19:17:48 UTC, Sönke Ludwig
wrote:
Not sure, but that
On Thursday, 9 April 2015 at 11:49:00 UTC, Martin Nowak wrote:
On 04/08/2015 08:32 PM, tcha wrote:
Now with release numbers.
D new - debug - 14.98s, 1782.0Mb
8.53s, 1786.8Mb
D new Gdc - debug - 29.08s, 1663.9Mb
GDC still misses @nogc support.
D new Ldc - 16.99s, 1663.0Mb
18.76s, 1664.1Mb
On Thursday, 9 April 2015 at 19:44:57 UTC, weaselcat wrote:
I saw that commit to the benchmark and changed it locally.
They're about the same performance now comparing clang to LDC,
with -inline -boundscheck=off -singleobj flags
Nice.
Also, since an LDC dev might read this - is there a
On Thursday, 9 April 2015 at 19:17:48 UTC, Sönke Ludwig wrote:
Not sure, but that may also have been my recent optimizations.
Just tried it with your recent optimizations and it doesn't build
with LDC 0.15.1.
Am 08.04.2015 um 20:32 schrieb tcha:
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
On 9 April 2015 at 13:48, Martin Nowak via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 04/08/2015 08:32 PM, tcha wrote:
Now with release numbers.
D new - debug - 14.98s, 1782.0Mb
8.53s, 1786.8Mb
D new Gdc - debug - 29.08s, 1663.9Mb
GDC still misses @nogc support.
Wasn't @nogc
On Thursday, 9 April 2015 at 19:43:13 UTC, Sönke Ludwig wrote:
Am 09.04.2015 um 21:40 schrieb Sönke Ludwig:
Am 09.04.2015 um 21:37 schrieb weaselcat:
On Thursday, 9 April 2015 at 19:35:24 UTC, Sönke Ludwig wrote:
Am 09.04.2015 um 21:26 schrieb weaselcat:
On Thursday, 9 April 2015 at 19:17:48
Am 09.04.2015 um 21:35 schrieb Sönke Ludwig:
Am 09.04.2015 um 21:26 schrieb weaselcat:
On Thursday, 9 April 2015 at 19:17:48 UTC, Sönke Ludwig wrote:
Not sure, but that may also have been my recent optimizations.
Just tried it with your recent optimizations and it doesn't build with
LDC
Am 09.04.2015 um 21:26 schrieb weaselcat:
On Thursday, 9 April 2015 at 19:17:48 UTC, Sönke Ludwig wrote:
Not sure, but that may also have been my recent optimizations.
Just tried it with your recent optimizations and it doesn't build with
LDC 0.15.1.
Should work now. I just tested LDC with
On Thursday, 9 April 2015 at 19:35:24 UTC, Sönke Ludwig wrote:
Am 09.04.2015 um 21:26 schrieb weaselcat:
On Thursday, 9 April 2015 at 19:17:48 UTC, Sönke Ludwig wrote:
Not sure, but that may also have been my recent optimizations.
Just tried it with your recent optimizations and it doesn't
Am 09.04.2015 um 21:06 schrieb weaselcat:
On Thursday, 9 April 2015 at 11:49:00 UTC, Martin Nowak wrote:
On 04/08/2015 08:32 PM, tcha wrote:
Now with release numbers.
D new - debug - 14.98s, 1782.0Mb
8.53s, 1786.8Mb
D new Gdc - debug - 29.08s, 1663.9Mb
GDC still misses @nogc support.
D
Am 09.04.2015 um 15:20 schrieb Martin Nowak:
On 04/09/2015 10:59 AM, Sönke Ludwig wrote:
As far as the profiler results can be trusted, a good chunk of the time
gets spent for reading individual bytes from memory, but there must be
something else low-level going on that make things this bad.
Am 09.04.2015 um 10:59 schrieb Sönke Ludwig:
Am 08.04.2015 um 20:55 schrieb Iain Buclaw via Digitalmars-d:
On 8 April 2015 at 20:32, tcha via Digitalmars-d
digitalmars-d@puremagic.com wrote:
(...)
Also tried to dustmite the minimal failing version and here is a result:
On Thursday, 9 April 2015 at 20:11:07 UTC, weaselcat wrote:
On Thursday, 9 April 2015 at 20:00:28 UTC, John Colvin wrote:
I can't remember which -O level inlining is enabled, but
there's definitely no need to explicitly ask for it at -O5.
-enable-inlining(enabled at -O2) and -inline do
Am 09.04.2015 um 15:11 schrieb Sönke Ludwig:
Am 09.04.2015 um 14:25 schrieb Martin Nowak:
(...)
There are 2 very nice alternative approaches in the benchmark repo.
https://github.com/kostya/benchmarks/blob/master/json/test_pull.cr
Am 09.04.2015 um 14:25 schrieb Martin Nowak:
On 04/08/2015 03:56 PM, 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...
The review hasn't yet
On 04/09/2015 02:10 PM, John Colvin wrote:
Still getting trounced across the board by rapidjson.
Yep, anyone knows why? They don't even use a lazy parser.
On 04/08/2015 08:32 PM, tcha wrote:
Now with release numbers.
D new - debug - 14.98s, 1782.0Mb
8.53s, 1786.8Mb
D new Gdc - debug - 29.08s, 1663.9Mb
GDC still misses @nogc support.
D new Ldc - 16.99s, 1663.0Mb
18.76s, 1664.1Mb
D new lazy - debug - 11.50s, 213.2Mb
4.57s, 206Mb
D new lazy Gdc
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
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
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?
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
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:
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
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.
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
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
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?
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
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.
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,
Am 08.04.2015 um 12:52 schrieb Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@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.
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
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
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:
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]:
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:
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:
63 matches
Mail list logo
