October 16, 2015
Am Thu, 15 Oct 2015 18:17:07 +0200
schrieb Sönke Ludwig <sludwig@rejectedsoftware.com>:

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

Well it is not an error. Rory originally wrote about
conversions between "1" and 1 happening on the browser side.
That would mean adding a quirks mode to any well-behaving JSON
parser. In this case: "read numbers as strings". Hence I was
asking if the data on the client could be fixed, e.g. the json
number be turned into a string first before serialization.

-- 
Marco

October 16, 2015
Am Thu, 15 Oct 2015 18:46:12 +0200
schrieb Sönke Ludwig <sludwig@rejectedsoftware.com>:

> Am 14.10.2015 um 09:01 schrieb Marco Leise:
> > […]
> > 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/wlczkjcawyteowjbbcpo@forum.dlang.org

You know, I'm not surprised at the "D new lazy Ldc" result, which is in the ball park figure of what I measured without exceptions & line-numbers, but the Rapid C++ result seems way off compared to kostya's listing. Or maybe that Core i7 doesn't work well with RapidJSON.

I used your fork of the benchmark, made some modifications like adding taggedalgebraic and what else was needed to make it compile with vanilla ldc2 0.16.0. Then I removed the flags that disable exceptions and line numbers. Compilation options are the same as for the existing gdc and ldc2 entries. I did not add " -partial-inliner -boundscheck=off -singleobj ".

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

Every value that is read (as opposed to skipped) is validated
according to RFC 7159. That includes UTF-8 validation. Full
validation (i.e. readJSONFile!validateAll(…);) may add up to
14% overhead here.

-- 
Marco

October 16, 2015
On Friday, 16 October 2015 at 12:53:09 UTC, Steven Schveighoffer wrote:

>> Yes, you can. GPL only affects distribution of executables to third
>> party, it doesn't affect services. Maybe you are thinking of AGPL, which
>> also affects services. But even AGPL allows internal usage.
>>
>
> No, you cannot link against GPL library without making your code also GPL. "Services" I don't think have anything to do with this, we are talking about binary linking.
>

There was something called the "server loophole." The language of GPLv2 only requires source to be distributed if the binaries are distributed. The Affero GPL was created to close the loophole, requiring source to be made available even if the binaries aren't distributed. IIRC, GPLv3 requires the same.

October 16, 2015
On Friday, 16 October 2015 at 14:05:50 UTC, Mike Parker wrote:
> On Friday, 16 October 2015 at 12:53:09 UTC, Steven Schveighoffer wrote:
>
>>> Yes, you can. GPL only affects distribution of executables to third
>>> party, it doesn't affect services. Maybe you are thinking of AGPL, which
>>> also affects services. But even AGPL allows internal usage.
>>>
>>
>> No, you cannot link against GPL library without making your code also GPL. "Services" I don't think have anything to do with this, we are talking about binary linking.
>>
>
> There was something called the "server loophole." The language of GPLv2 only requires source to be distributed if the binaries are distributed. The Affero GPL was created to close the loophole, requiring source to be made available even if the binaries aren't distributed. IIRC, GPLv3 requires the same.

Looks like I got my versions wrong. AGPL is a modified GPLv3.

http://www.gnu.org/licenses/why-affero-gpl.en.html
October 16, 2015
On 10/16/2015 08:53 AM, Steven Schveighoffer wrote:
> On 10/16/15 6:20 AM, Ola Fosheim Grøstad wrote:
>> On Thursday, 15 October 2015 at 22:13:07 UTC, Jonathan M Davis wrote:
>>> 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.
>>
>> Yes, you can. GPL only affects distribution of executables to third
>> party, it doesn't affect services. Maybe you are thinking of AGPL, which
>> also affects services. But even AGPL allows internal usage.
>>
>
> No, you cannot link against GPL library without making your code also
> GPL. "Services" I don't think have anything to do with this, we are
> talking about binary linking.
>

This is the real reason I'm not a huge fan of *GPL. Nobody can understand it!

October 16, 2015
Am Fri, 16 Oct 2015 11:09:37 +0000
schrieb Per Nordlöw <per.nordlow@gmail.com>:

> On Wednesday, 14 October 2015 at 07:01:49 UTC, Marco Leise wrote:
> > https://github.com/kostya/benchmarks#json
> 
> Does fast.json use any non-standard memory allocation patterns or plain simple GC-usage?

Plain GC.  I found no way in D to express something as "borrowed", but the GC removes the ownership question from the picture. That said the only thing that I allocate in this benchmark is the dynamic array of coordinates (1_000_000 * 3 * double.sizeof), which can be replaced by lazily iterating over the array to remove all allocations.

Using these lazy techniques for objects too and
calling .borrow() instead of .read!string() (which .idups)
should allow GC free usage. (Well, except for the one in
parseJSON, where I append 16 zero bytes to the JSON string to
make it SSE safe.)

-- 
Marco

October 16, 2015
On Friday, 16 October 2015 at 12:53:09 UTC, Steven Schveighoffer wrote:
> No, you cannot link against GPL library without making your code also GPL. "Services" I don't think have anything to do with this, we are talking about binary linking.

Yes, you can. GPL is a copyright license which says that if you legally obtain a copy of an executable then you also have the right to the source code and the right to make copies. If you don't hand out an executable then there are no obligations at all, for obvious reasons.

GPL, on the other hand, gives the same right to users of a service.

https://en.wikipedia.org/wiki/Affero_General_Public_License


October 16, 2015
On Friday, 16 October 2015 at 15:07:17 UTC, Ola Fosheim Grøstad wrote:
> GPL, on the other hand, gives the same right to users of a service.

Typo, "AGPL", not "GPL"...

October 16, 2015
On Friday, 16 October 2015 at 14:09:13 UTC, Nick Sabalausky wrote:
> This is the real reason I'm not a huge fan of *GPL. Nobody can understand it!

It is really simple!! The basic idea is that people shouldn't have to reverse engineer software they use in order to fix it/modify it, so when you receive software you should get the right to the means to modify it (the source code).

In addition GPL also gives you the right to distribute copies (if you want to) so that you can let others enjoy your improved version of the program.

It doesn't give the public the right to demand source code to be made available, only owners of legally obtained copies get the right to demand the full source to be available for them.

It also does not forbid linking against anything, it requires the copyright holder to grant rights to the receiver of the copy (access to source code and making copies to distribute under the same terms).

As long as you keep your modifications/derived works for yourself, the only party that has been granted GPL for the derived work is yourself. One dilemma here is that a company with a million employees is treated like a single entity legally. So big companies can embrace the GPL freely for internal use and services without the redistribution GPL clauses coming into effect, whereas smaller companies that exchange software between them cannot restrict redistribution...

October 16, 2015
On 10/16/15 11:07 AM, Ola Fosheim Grøstad wrote:
> On Friday, 16 October 2015 at 12:53:09 UTC, Steven Schveighoffer wrote:
>> No, you cannot link against GPL library without making your code also
>> GPL. "Services" I don't think have anything to do with this, we are
>> talking about binary linking.
>
> Yes, you can. GPL is a copyright license which says that if you legally
> obtain a copy of an executable then you also have the right to the
> source code and the right to make copies. If you don't hand out an
> executable then there are no obligations at all, for obvious reasons.

You certainly can link with it, and then your code becomes GPL. you don't have to distribute the binary, but it's still now GPL. The question is, can you link a proprietary licensed piece of software against GPL, while having the proprietary software retain its license, and the answer is no.

If you want to say GPL is fine if you only want to provide your software as a service, then that is not an answer to the question. Your software is effectively GPL, but you don't have to distribute the source because you didn't distribute the binary. However, you would have no recourse if you mistakenly provided the binary to someone. Ever. This is a poison pill risk that most companies will not swallow. Please give me a json library that's 10% slower and won't ruin my entire business, thanks.

-Steve