Re: Fastest JSON parser in the world is a D project
On 2015-10-16 00:14, Jonathan M Davis via Digitalmars-d-announce wrote: I thought that http://code.dlang.org/packages/std_data_json was the json implementation we were looking at adding to Phobos. Or did that fall through? I haven't paid much attention to the discussion on that, though I have used it in one of my own projects. Yes, that was the plan. But if a better alternative shows up, should we look at that as well? -- /Jacob Carlborg
Re: Fastest JSON parser in the world is a D project
On 2015-10-16 00:12, Jonathan M Davis via Digitalmars-d-announce wrote: I think that you might be able to link code with various other compatible, open source licenses against it, but you definitely can't link any proprietary code aganist it. GPL really makes more sense for programs than for libraries for precisely that reason. And most D libraries are likely to be Boost licensed, since that's the license used by Phobos and generally favored by the D community. There's nothing wrong with releasing a library under the GPL if you really want to, but it seriously limits its usefulness. Yes, that's correct. It would be fine if everything used GPL, but that's not the world we live in. Which makes the license not very practical. -- /Jacob Carlborg
Re: Walter and I talk about D in Romania
On 2015-10-15 23:27, Jack Stouffer wrote: Xcode supports D? And I thought that LDC was the only compiler that outputs info for LLDB? No, but it works as good as the underlying debugger that is used. Which in this case is lacking. I interpreted the statement as the actual UI, not the debugger itself. -- /Jacob Carlborg
Re: Fastest JSON parser in the world is a D project
On Thursday, October 15, 2015 09:40:05 Per Nordlöw via Digitalmars-d-announce wrote: > On Wednesday, 14 October 2015 at 07:01:49 UTC, Marco Leise wrote: > > fast: 0.34s, 226.7Mb (GDC) > > RapidJSON: 0.79s, 687.1Mb (GCC) > > Why not add this to std.experimental? I thought that http://code.dlang.org/packages/std_data_json was the json implementation we were looking at adding to Phobos. Or did that fall through? I haven't paid much attention to the discussion on that, though I have used it in one of my own projects. - Jonathan M Davis
Re: Fastest JSON parser in the world is a D project
On Thursday, October 15, 2015 14:51:58 Johannes Pfau via Digitalmars-d-announce wrote: > BTW: Is there a reason why the code is GPL licensed? I understand that > people might want to use more restrictive licenses, but isn't LGPL a > better replacement for GPL when writing library code? Doesn't the GPL > force everybody _using_ fast.json to also use the GPL license? > > See: http://stackoverflow.com/a/10179181/471401 I think that you might be able to link code with various other compatible, open source licenses against it, but you definitely can't link any proprietary code aganist it. GPL really makes more sense for programs than for libraries for precisely that reason. And most D libraries are likely to be Boost licensed, since that's the license used by Phobos and generally favored by the D community. There's nothing wrong with releasing a library under the GPL if you really want to, but it seriously limits its usefulness. - Jonathan M Davis
Re: Walter and I talk about D in Romania
On Thursday, 15 October 2015 at 17:34:25 UTC, Jacob Carlborg wrote: On 2015-10-15 00:54, Vladimir Panteleev wrote: whether we have good debugging GUIs for all platforms, which we don't for OS X. There's Xcode. Xcode supports D? And I thought that LDC was the only compiler that outputs info for LLDB?
Re: Fastest JSON parser in the world is a D project
On Thursday, 15 October 2015 at 19:40:16 UTC, Jacob Carlborg wrote: On 2015-10-15 14:51, Johannes Pfau wrote: Doesn't the GPL force everybody _using_ fast.json to also use the GPL license? Yes, it does have that enforcement. Then this is practically useless for the vast majority of programmers.
Re: Fastest JSON parser in the world is a D project
On 2015-10-15 14:51, Johannes Pfau wrote: Doesn't the GPL force everybody _using_ fast.json to also use the GPL license? Yes, it does have that enforcement. -- /Jacob Carlborg
Re: Fastest JSON parser in the world is a D project
On Thursday, 15 October 2015 at 10:34:16 UTC, Andrei Alexandrescu wrote: On 10/15/15 12:40 PM, Per Nordlöw wrote: On Wednesday, 14 October 2015 at 07:01:49 UTC, Marco Leise wrote: fast: 0.34s, 226.7Mb (GDC) RapidJSON: 0.79s, 687.1Mb (GCC) Why not add this to std.experimental? Sure seems like a good question! At the least a more generic generalization (more character and range types etc) should start from Marco's core implementation. -- Andrei Would it not be a better use of effort to attempt to merge the efforts here over to Sonkes new stdx.json? I didn't look at either codebase, so I dont know how difficult that'll be.
Re: Walter and I talk about D in Romania
On 2015-10-15 00:54, Vladimir Panteleev wrote: whether we have good debugging GUIs for all platforms, which we don't for OS X. There's Xcode. -- /Jacob Carlborg
Re: Fastest JSON parser in the world is a D project
Am 14.10.2015 um 09:01 schrieb Marco Leise: JSON parsing in D has come a long way, especially when you look at it from the efficiency angle as a popular benchmark does that has been forked by well known D contributers like Martin Nowak or Sönke Ludwig. The test is pretty simple: Parse a JSON object, containing an array of 1_000_000 3D coordinates in the range [0..1) and average them. The performance of std.json in parsing those was horrible still in the DMD 2.066 days*: DMD : 41.44s, 934.9Mb Gdc : 29.64s, 929.7Mb Python : 12.30s, 1410.2Mb Ruby: 13.80s, 2101.2Mb Then with 2.067 std.json got a major 3x speed improvement and rivaled the popular dynamic languages Ruby and Python: DMD : 13.02s, 1324.2Mb In the mean time several other D JSON libraries appeared with varying focus on performance or API: Medea : 56.75s, 1753.6Mb (GDC) libdjson : 24.47s, 1060.7Mb (GDC) stdx.data.json: 2.76s, 207.1Mb (LDC) Yep, that's right. stdx.data.json's pull parser finally beats the dynamic languages with native efficiency. (I used the default options here that provide you with an Exception and line number on errors.) From when are the numbers for stdx.data.json? The latest results for the pull parser that I know of were faster than RapidJson: http://forum.dlang.org/post/wlczkjcawyteowjbb...@forum.dlang.org Judging by the relative numbers, your "fast" result is still a bit faster, but if that doesn't validate, it's hard to make an objective comparison.
Re: Fastest JSON parser in the world is a D project
Am 15.10.2015 um 13:06 schrieb Rory McGuire via Digitalmars-d-announce: In browser JSON.serialize is the usual way to serialize JSON values. The problem is that on D side if one does deserialization of an object or struct. If the types inside the JSON don't match exactly then vibe freaks out. For float and double fields, the serialization code should actually accept both, floating point and integer numbers: https://github.com/rejectedsoftware/vibe.d/blob/2fffd94d8516cd6f81c75d45a54c655626d36c6b/source/vibe/data/json.d#L1603 https://github.com/rejectedsoftware/vibe.d/blob/2fffd94d8516cd6f81c75d45a54c655626d36c6b/source/vibe/data/json.d#L1804 Do you have a test case for your error?
Re: Beta D 2.069.0-b1
On 10/9/15 10:37 PM, Adam D. Ruppe wrote: On Saturday, 10 October 2015 at 02:31:51 UTC, Martin Nowak wrote: nothing to warrant the invasive language feature @property is. There's no reason for @property to be invasive. ALL it needs to do is handle that one case, it shouldn't even be used anywhere else. Everything else is trivial or irrelevant. And the beauty of this is it won't even break any code. I honestly couldn't care less about this. What I don't like is arbitrary setter property abuse. e.g. somerange.find = needle; My opinion: Empty parens can always be omitted on functions, but need to be present in order to call delegates/function pointers. @property function on struct/class method enables the instance.method = value; syntax. Otherwise, it's rejected (you must use instance.method(value); syntax). If I were defining it from scratch, I'd say you HAVE to use first syntax if it's marked @property, but I'm OK with allowing the normal syntax on @property methods. Since we have @property, slapping it on a getter that returns a delegate/function pointer enables the behavior you want (why not?). &instance.prop I'm unsure what it should mean. I'm leaning towards that it means get a delegate to the property method itself, not the result of calling the property. This makes it behave differently than a field, but it already does this today. @property on module level functions operate like methods, but allow UFCS calls. So: 0 params -> Obviously, like a getter (see above). 1 params -> Allow func = val syntax. Other syntaxes still allowed. Calling val.func syntax, if returning a delegate, I think should require the double parens, since IMO @property is for the setter syntax, not a description of a UFCS call. 2 params -> Allow firstParam.func = secondParam syntax. Other syntaxes still allowed. -Steve
Re: Fastest JSON parser in the world is a D project
On Thursday, 15 October 2015 at 12:51:58 UTC, Johannes Pfau wrote: BTW: Is there a reason why the code is GPL licensed? I understand that people might want to use more restrictive licenses, but isn't LGPL a better replacement for GPL when writing library code? Doesn't the GPL force everybody _using_ fast.json to also use the GPL license? See: http://stackoverflow.com/a/10179181/471401 It also precludes any of this code being used in Phobos :/
Re: Fastest JSON parser in the world is a D project
Am Thu, 15 Oct 2015 11:09:01 +0200 schrieb Daniel Kozak : > Daniel Kozak via Digitalmars-d-announce píše v Čt 15. 10. 2015 v 11:07 > +0200: > > > > > > Gary Willoughby via Digitalmars-d-announce > > napsal Čt, říj 15, 2015 v > > 10∶08 : > > > On Wednesday, 14 October 2015 at 07:01:49 UTC, Marco Leise wrote: > > > fast: 0.34s, 226.7Mb (GDC) > > > RapidJSON: 0.79s, 687.1Mb (GCC) > > > > > > (* Timings from my computer, Haswell CPU, Linux amd64.) > > > > > > Where's the code? > > code.dlang.org > > https://github.com/mleise/fast BTW: Is there a reason why the code is GPL licensed? I understand that people might want to use more restrictive licenses, but isn't LGPL a better replacement for GPL when writing library code? Doesn't the GPL force everybody _using_ fast.json to also use the GPL license? See: http://stackoverflow.com/a/10179181/471401
Re: Beta D 2.069.0-b2
On 2015-10-14 20:32, John Colvin wrote: got through to homebrew a faster this time. brew reinstall dmd --devel It's always available through DVM 1 second after announcement :) -- /Jacob Carlborg
Re: Beta D 2.069.0-b2
On Thursday, 15 October 2015 at 10:33:11 UTC, Andrei Alexandrescu wrote: On 10/15/15 10:51 AM, Robert burner Schadek wrote: On Thursday, 15 October 2015 at 05:47:16 UTC, Andrei Alexandrescu wrote: Brian, should we add you? LMK. -- Andrei indeed! Dunn. -- Andrei nice
Re: Fastest JSON parser in the world is a D project
In browser JSON.serialize is the usual way to serialize JSON values. The problem is that on D side if one does deserialization of an object or struct. If the types inside the JSON don't match exactly then vibe freaks out. Another problem with most D JSON implementations is that they don't support proper JSON, e.g. outputting nan as though it was a valid value etc... browsers don't like that stuff. For me the best D JSON implementation at the moment is actually jsvar by Adam and its not even a JSON parser, it just has that as a needed feature. It feels slow though I haven't benchmarked, but if I run it over a couple of Gigs of data(Paged by 1000) it takes a long while. On Thu, Oct 15, 2015 at 3:42 AM, Marco Leise via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > Am Wed, 14 Oct 2015 10:22:37 +0200 > schrieb Rory McGuire via Digitalmars-d-announce > : > > > Does this version handle real world JSON? > > > > I've keep getting problems with vibe and JSON because web browsers will > > automatically make a "1" into a 1 which then causes exceptions in vibe. > > > > Does yours do lossless conversions automatically? > > No I don't read numbers as strings. Could the client > JavaScript be fixed? I fail to see why the conversion would > happen automatically when the code could explicitly check for > strings before doing math with the value "1". What do I miss? > > -- > Marco > >
Re: Beta D 2.069.0-b2
On 10/15/15 10:51 AM, Robert burner Schadek wrote: On Thursday, 15 October 2015 at 05:47:16 UTC, Andrei Alexandrescu wrote: Brian, should we add you? LMK. -- Andrei indeed! Dunn. -- Andrei
Re: Fastest JSON parser in the world is a D project
On 10/15/15 12:40 PM, Per Nordlöw wrote: On Wednesday, 14 October 2015 at 07:01:49 UTC, Marco Leise wrote: fast: 0.34s, 226.7Mb (GDC) RapidJSON: 0.79s, 687.1Mb (GCC) Why not add this to std.experimental? Sure seems like a good question! At the least a more generic generalization (more character and range types etc) should start from Marco's core implementation. -- Andrei
Re: Fastest JSON parser in the world is a D project
On Wednesday, 14 October 2015 at 07:01:49 UTC, Marco Leise wrote: fast: 0.34s, 226.7Mb (GDC) RapidJSON: 0.79s, 687.1Mb (GCC) Why not add this to std.experimental?
Re: Fastest JSON parser in the world is a D project
Daniel Kozak via Digitalmars-d-announce píše v Čt 15. 10. 2015 v 11:07 +0200: > > > Gary Willoughby via Digitalmars-d-announce remagic.com> napsal Čt, říj 15, 2015 v 10∶08 : > > On Wednesday, 14 October 2015 at 07:01:49 UTC, Marco Leise wrote: > > fast: 0.34s, 226.7Mb (GDC) > > RapidJSON: 0.79s, 687.1Mb (GCC) > > > > (* Timings from my computer, Haswell CPU, Linux amd64.) > > > > Where's the code? > code.dlang.org https://github.com/mleise/fast
Re: Fastest JSON parser in the world is a D project
Gary Willoughby via Digitalmars-d-announce napsal Čt, říj 15, 2015 v 10∶08 : On Wednesday, 14 October 2015 at 07:01:49 UTC, Marco Leise wrote: fast: 0.34s, 226.7Mb (GDC) RapidJSON: 0.79s, 687.1Mb (GCC) (* Timings from my computer, Haswell CPU, Linux amd64.) Where's the code? code.dlang.org
Re: Fastest JSON parser in the world is a D project
On Wednesday, 14 October 2015 at 07:01:49 UTC, Marco Leise wrote: fast: 0.34s, 226.7Mb (GDC) RapidJSON: 0.79s, 687.1Mb (GCC) (* Timings from my computer, Haswell CPU, Linux amd64.) Where's the code?
Re: Beta D 2.069.0-b2
On Thursday, 15 October 2015 at 05:47:16 UTC, Andrei Alexandrescu wrote: Brian, should we add you? LMK. -- Andrei indeed!
