Am 05.02.2015 um 10:07 schrieb Jakob Ovrum:
On Thursday, 21 August 2014 at 22:35:18 UTC, Sönke Ludwig wrote:
...
Added to the review queue as a work in progress with relevant links:
http://wiki.dlang.org/Review_Queue
Thanks! I(t) should be ready for an official review in one or two wee
On 2/5/15 1:07 AM, Jakob Ovrum wrote:
On Thursday, 21 August 2014 at 22:35:18 UTC, Sönke Ludwig wrote:
...
Added to the review queue as a work in progress with relevant links:
http://wiki.dlang.org/Review_Queue
Yay! -- Andrei
On Thursday, 21 August 2014 at 22:35:18 UTC, Sönke Ludwig wrote:
...
Added to the review queue as a work in progress with relevant
links:
http://wiki.dlang.org/Review_Queue
On Saturday, 18 October 2014 at 19:53:23 UTC, Sean Kelly wrote:
Python
0.499547972114
0.499779920774
0.499811461578
12.01s, 1355.1Mb
I assume this is the standard json module? I am wondering how
ujson is performing, which is considered the fastest python
module.
On 10/18/14, 4:53 PM, Sean Kelly wrote:
On Friday, 17 October 2014 at 18:27:34 UTC, Ary Borenszweig wrote:
Once its done you can compare its performance against other languages
with this benchmark:
https://github.com/kostya/benchmarks/tree/master/json
Wow, the C++Rapid parser is really impre
On Saturday, 18 October 2014 at 19:53:23 UTC, Sean Kelly wrote:
On Friday, 17 October 2014 at 18:27:34 UTC, Ary Borenszweig
wrote:
Once its done you can compare its performance against other
languages with this benchmark:
https://github.com/kostya/benchmarks/tree/master/json
Wow, the C++Ra
On Friday, 17 October 2014 at 18:27:34 UTC, Ary Borenszweig wrote:
Once its done you can compare its performance against other
languages with this benchmark:
https://github.com/kostya/benchmarks/tree/master/json
Wow, the C++Rapid parser is really impressive. I threw together
a test with m
On 8/21/14, 7:35 PM, Sönke Ludwig wrote:
Following up on the recent "std.jgrandson" thread [1], I've picked up
the work (a lot earlier than anticipated) and finished a first version
of a loose blend of said std.jgrandson, vibe.data.json and some changes
that I had planned for vibe.data.json for a
On 10/13/14, 4:45 AM, Sönke Ludwig wrote:
Am 13.10.2014 13:33, schrieb Jacob Carlborg:
On 13/10/14 09:39, Sönke Ludwig wrote:
** At four words per token, Location seems pretty bulky. How about
reducing line and column to uint?
Single line JSON files >64k (or line counts >64k) are no exceptio
On 10/13/14, 4:48 AM, Sönke Ludwig wrote:
Am 13.10.2014 13:37, schrieb Jacob Carlborg:
On 22/08/14 00:35, Sönke Ludwig wrote:
Following up on the recent "std.jgrandson" thread [1], I've picked up
the work (a lot earlier than anticipated) and finished a first version
of a loose blend of said std
Am 13.10.2014 13:37, schrieb Jacob Carlborg:
On 22/08/14 00:35, Sönke Ludwig wrote:
Following up on the recent "std.jgrandson" thread [1], I've picked up
the work (a lot earlier than anticipated) and finished a first version
of a loose blend of said std.jgrandson, vibe.data.json and some changes
Am 13.10.2014 13:33, schrieb Jacob Carlborg:
On 13/10/14 09:39, Sönke Ludwig wrote:
** At four words per token, Location seems pretty bulky. How about
reducing line and column to uint?
Single line JSON files >64k (or line counts >64k) are no exception
64k?
Oh, I've read "both line and co
On 22/08/14 00:35, Sönke Ludwig wrote:
Following up on the recent "std.jgrandson" thread [1], I've picked up
the work (a lot earlier than anticipated) and finished a first version
of a loose blend of said std.jgrandson, vibe.data.json and some changes
that I had planned for vibe.data.json for a w
On 13/10/14 09:39, Sönke Ludwig wrote:
** At four words per token, Location seems pretty bulky. How about
reducing line and column to uint?
Single line JSON files >64k (or line counts >64k) are no exception
64k?
--
/Jacob Carlborg
Am 12.10.2014 23:52, schrieb Sean Kelly:
Oh, it looks like you aren't checking for 0x7F (DEL) as a control
character.
It doesn't get mentioned in the JSON spec, so I left it out. But I guess
nothing speaks against adding it anyway.
Am 12.10.2014 21:04, schrieb Sean Kelly:
I'd like to see unescapeStringLiteral() made public. Then I can
unescape multiple strings to the same preallocated destination, or even
unescape in place (guaranteed to work since the result will always be
smaller than the input).
Will do. Same for the
Am 12.10.2014 20:17, schrieb Andrei Alexandrescu:
Here's my destruction of std.data.json.
* lexer.d:
** Beautifully done. From what I understand, if the input is string or
immutable(ubyte)[] then the strings are carved out as slices of the
input, as opposed to newly allocated. Awesome.
** The
Oh, it looks like you aren't checking for 0x7F (DEL) as a control
character.
On Sunday, 12 October 2014 at 18:17:29 UTC, Andrei Alexandrescu
wrote:
** The string after lexing is correctly scanned and stored in
raw format (escapes are not rewritten) and decoded on demand.
Problem with decoding is that it may allocate memory, and it
would be great (and not difficult) to
Here's my destruction of std.data.json.
* lexer.d:
** Beautifully done. From what I understand, if the input is string or
immutable(ubyte)[] then the strings are carved out as slices of the
input, as opposed to newly allocated. Awesome.
** The string after lexing is correctly scanned and sto
Been using it for a bit now, I think the only thing I have to say
is having to insert all of those `JSONValue` everywhere is
tiresome and I never know when I have to do it.
Atila
On Thursday, 21 August 2014 at 22:35:18 UTC, Sönke Ludwig wrote:
Following up on the recent "std.jgrandson" thread
Kahan states this in a 1997 paper:
«[…]An SNaN may be moved ( copied ) without incident, but any
other arithmetic operation upon an SNaN is an INVALID operation (
and so is loading one onto the ix87's stack ) that must trap or
else produce a new nonsignaling NaN. ( Another way to turn an
SNaN
Let me try again:
SNAN => unfortunately absent
QNAN => deliberately absent
So you can have:
compute(SNAN) => handle(exception) {
if(can turn unfortunate situation into deliberate)
then compute(QNAN)
else throw
)
On Thursday, 28 August 2014 at 14:43:30 UTC, Don wrote:
No. Once you load an SNAN, it isn't an SNAN any more! It is a
QNAN.
By which definition? It is only if you consume the SNAN with an
fp-exception-free arithmetic op that it should be turned into a
QNAN. If you compute with an op that thr
On Thursday, 28 August 2014 at 12:10:58 UTC, Ola Fosheim Grøstad
wrote:
Or to be more explicit:
If have SNAN then there is no point in trying to recompute the
expression using a different algorithm.
If have QNAN then you might want to recompute the expression
using a different algorithm (e.g
Or to be more explicit:
If have SNAN then there is no point in trying to recompute the
expression using a different algorithm.
If have QNAN then you might want to recompute the expression
using a different algorithm (e.g. complex numbers or
analytically).
?
On Thursday, 28 August 2014 at 11:09:16 UTC, Don wrote:
I think the way to think of it is, to the programmer, there is
*no such thing* as an snan value. It's an implementation detail
that should be invisible.
Semantically, a signalling nan is a qnan value with a hardware
breakpoint on it.
I d
On Wednesday, 27 August 2014 at 23:51:54 UTC, Walter Bright wrote:
On 8/26/2014 12:24 AM, Don wrote:
On Monday, 25 August 2014 at 23:29:21 UTC, Walter Bright wrote:
On 8/25/2014 4:15 PM, "Ola Fosheim Grøstad"
" wrote:
On Monday, 25 August 2014 at 21:24:11 UTC, Walter Bright
wrote:
I didn't kno
On 8/26/2014 12:24 AM, Don wrote:
On Monday, 25 August 2014 at 23:29:21 UTC, Walter Bright wrote:
On 8/25/2014 4:15 PM, "Ola Fosheim Grøstad"
" wrote:
On Monday, 25 August 2014 at 21:24:11 UTC, Walter Bright wrote:
I didn't know that. But recall I did implement it in DMC++, and it turned out
t
Am 26.08.2014 16:51, schrieb Sönke Ludwig:
Am 26.08.2014 16:40, schrieb Don:
This is the difference: if you get NaN or Infinity, there's probably a
straightforward bug in the Javascript code, but your D code is fine. Any
other kind of JSON parsing error means you've got a garbage string that
isn
On Tuesday, 26 August 2014 at 14:40:02 UTC, Don wrote:
This is the difference: if you get NaN or Infinity, there's
probably a straightforward bug in the Javascript code, but your
D code is fine. Any other kind of JSON parsing error means
you've got a garbage string that isn't JSON at all. They
Am 26.08.2014 16:40, schrieb Don:
On Tuesday, 26 August 2014 at 14:06:42 UTC, Sönke Ludwig wrote:
Am 26.08.2014 15:43, schrieb Don:
On Monday, 25 August 2014 at 14:04:12 UTC, Sönke Ludwig wrote:
Am 25.08.2014 15:07, schrieb Don:
ie this should be parsable:
{"foo": NaN, "bar": Infinity, "baz"
On Tuesday, 26 August 2014 at 14:06:42 UTC, Sönke Ludwig wrote:
Am 26.08.2014 15:43, schrieb Don:
On Monday, 25 August 2014 at 14:04:12 UTC, Sönke Ludwig wrote:
Am 25.08.2014 15:07, schrieb Don:
ie this should be parsable:
{"foo": NaN, "bar": Infinity, "baz": -Infinity}
This would probably
On Tuesday, 26 August 2014 at 13:43:56 UTC, Ola Fosheim Grøstad
wrote:
Anyway, the x87 FP stack is history, even MOVSS is considered
legacy by Intel…
Sorry for being off-topic, but MOVSS and VMOVSS on AMD don't
throw FP exceptions either, but calculations does. So it seems
like AMD and Intel
Am 26.08.2014 15:43, schrieb Don:
On Monday, 25 August 2014 at 14:04:12 UTC, Sönke Ludwig wrote:
Am 25.08.2014 15:07, schrieb Don:
ie this should be parsable:
{"foo": NaN, "bar": Infinity, "baz": -Infinity}
This would probably best added as another (CT) optional feature. I
think the default
On Tuesday, 26 August 2014 at 13:24:11 UTC, Don wrote:
No, it's more subtle. On the original x87, signalling NaNs are
triggered for 64 bits loads, but not for 80 bit loads. You have
to read the fine print to discover this.
You are right, but it happens for loads from the FP-stack too:
«Source
On Monday, 25 August 2014 at 14:04:12 UTC, Sönke Ludwig wrote:
Am 25.08.2014 15:07, schrieb Don:
On Thursday, 21 August 2014 at 22:35:18 UTC, Sönke Ludwig
wrote:
Following up on the recent "std.jgrandson" thread [1], I've
picked up
the work (a lot earlier than anticipated) and finished a
first
On Tuesday, 26 August 2014 at 12:37:58 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 26 August 2014 at 10:55:20 UTC, Don wrote:
It was always in IEEE754. The decision in 754-2008 was simply
to not remove it from the spec (a lot of people wanted to
remove it). I don't think anything has changed.
With the danger of being noisy, these instructions are subject to
floating point exceptions according to my (perhaps sloppy)
reading of Intel Architecture Instruction Set Extensions
Programming Reference (2012):
(V)ADDPD, (V)ADDPS, (V)ADDSUBPD, (V)ADDSUBPS, (V)CMPPD, (V)CMPPS,
(V)CVTDQ2PS, (V
On Tuesday, 26 August 2014 at 12:37:58 UTC, Ola Fosheim Grøstad
wrote:
either. AVX is quite complicated, but searching for "signaling"
gives some hints about the semantics you can rely on.
…
https://software.intel.com/sites/default/files/managed/c6/a9/319433-020.pdf
(Actually, searching for
On Tuesday, 26 August 2014 at 10:55:20 UTC, Don wrote:
It was always in IEEE754. The decision in 754-2008 was simply
to not remove it from the spec (a lot of people wanted to
remove it). I don't think anything has changed.
It was implementation defined before. I think they specified the
bit i
On Thursday, 21 August 2014 at 22:35:18 UTC, Sönke Ludwig wrote:
Following up on the recent "std.jgrandson" thread [1], I've
picked up the work (a lot earlier than anticipated) and
finished a first version of a loose blend of said
std.jgrandson, vibe.data.json and some changes that I had
plann
On Tuesday, 26 August 2014 at 07:34:05 UTC, Ola Fosheim Gr wrote:
On Tuesday, 26 August 2014 at 07:24:19 UTC, Don wrote:
Processors from AMD have signalling NaN behaviour which is
different from processors from Intel.
And the situation is worst on most other architectures. It's a
lost cause,
Am 26.08.2014 11:11, schrieb "Ola Fosheim Grøstad"
":
On Tuesday, 26 August 2014 at 09:05:05 UTC, Sönke Ludwig wrote:
When on the other hand a ubyte/ushort/uint range is used, the lexer
should validate all string literals.
Yes, so this will be supported? Because this is what is most useful.
I tried using "-disable-linker-strip-dead", but it had no effect.
From the error messages it seems the problem is compile-time and
not link-time...
On Tuesday, 26 August 2014 at 07:01:09 UTC, Jacob Carlborg wrote:
On 25/08/14 21:49, simendsjo wrote:
So ldc can remove quite a substantial amo
On Tuesday, 26 August 2014 at 09:05:05 UTC, Sönke Ludwig wrote:
When on the other hand a ubyte/ushort/uint range is used, the
lexer should validate all string literals.
Yes, so this will be supported? Because this is what is most
useful.
Am 26.08.2014 10:24, schrieb "Ola Fosheim Grøstad"
":
On Tuesday, 26 August 2014 at 07:51:04 UTC, Sönke Ludwig wrote:
That's true. So the ideal solution would be to *assume* UTF-8 when the
input is char based and to *validate* if the input is "numeric".
I think you should validate JSON-strings
Am 26.08.2014 03:31, schrieb Entusiastic user:
Hi!
Thanks for the effort you've put in this.
I am having problems with building with LDC 0.14.0. DMD 2.066.0
seems to work fine (all unit tests pass). Do you have any ideas
why?
I've fixed all errors on DMD 2.065 now. Hopefully that should also
On Tuesday, 26 August 2014 at 07:51:04 UTC, Sönke Ludwig wrote:
That's true. So the ideal solution would be to *assume* UTF-8
when the input is char based and to *validate* if the input is
"numeric".
I think you should validate JSON-strings to be UTF-8 encoded even
if you allow illegal unicod
Am 25.08.2014 23:53, schrieb "Ola Fosheim Grøstad"
":
On Monday, 25 August 2014 at 21:27:42 UTC, Sönke Ludwig wrote:
But why should UTF validation be the job of the lexer in the first place?
Because you want to save time, it is faster to integrate validation? The
most likely use scenario is to
On Tuesday, 26 August 2014 at 07:24:19 UTC, Don wrote:
Processors from AMD have signalling NaN behaviour which is
different from processors from Intel.
And the situation is worst on most other architectures. It's a
lost cause, I think.
I disagree. AFAIK signaling NaN was standardized in IEEE
On Monday, 25 August 2014 at 23:29:21 UTC, Walter Bright wrote:
On 8/25/2014 4:15 PM, "Ola Fosheim Grøstad"
" wrote:
On Monday, 25 August 2014 at 21:24:11 UTC, Walter Bright wrote:
I didn't know that. But recall I did implement it in DMC++,
and it turned out
to simply not be useful. I'd be surp
On 25/08/14 21:49, simendsjo wrote:
So ldc can remove quite a substantial amount of code in some cases.
It's because the latest release of LDC has the --gc-sections falg
enabled by default.
--
/Jacob Carlborg
...
I am using Ubuntu 3.10 (Linux 3.11.0-15-generic x86_64).
...
I meant Ubuntu 13.10 :D
Hi!
Thanks for the effort you've put in this.
I am having problems with building with LDC 0.14.0. DMD 2.066.0
seems to work fine (all unit tests pass). Do you have any ideas
why?
I am using Ubuntu 3.10 (Linux 3.11.0-15-generic x86_64).
Master was at 6a9f8e62e456c3601fe8ff2e1fbb640f38793d08.
$
On Monday, 25 August 2014 at 23:24:43 UTC, Kiith-Sa wrote:
D:YAML uses a similar approach, but with 8 bytes (plain ulong -
portable) to detect how many ASCII chars are there before the
first non-ASCII UTF-8 sequence, and it significantly improves
performance (didn't keep any numbers unfortunat
Btw, maybe it would be a good idea to take a look on the JSON
that various browsers generates to see if there are any
differences?
Then one could tune optimizations to what is the most common
coding, like this:
1. start parsing assuming "browser style restricted JSON" grammar.
2. on failure
On 8/25/2014 4:15 PM, "Ola Fosheim Grøstad"
" wrote:
On Monday, 25 August 2014 at 21:24:11 UTC, Walter Bright wrote:
I didn't know that. But recall I did implement it in DMC++, and it turned out
to simply not be useful. I'd be surprised if the new C++ support for it does
anything worthwhile.
W
On Monday, 25 August 2014 at 22:40:00 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 25 August 2014 at 21:53:50 UTC, Ola Fosheim Grøstad
wrote:
I presume you can load 16 bytes and do BITWISE-AND on the MSB,
then match against string-end and carefully use this to boost
performance of simultanous UTF
On Monday, 25 August 2014 at 21:24:11 UTC, Walter Bright wrote:
I didn't know that. But recall I did implement it in DMC++, and
it turned out to simply not be useful. I'd be surprised if the
new C++ support for it does anything worthwhile.
Well, one should initialize with signaling NaN. Then y
On Monday, 25 August 2014 at 21:53:50 UTC, Ola Fosheim Grøstad
wrote:
I presume you can load 16 bytes and do BITWISE-AND on the MSB,
then match against string-end and carefully use this to boost
performance of simultanous UTF validation, escape-scanning, and
string-end scan. A bit tricky, of co
On Monday, 25 August 2014 at 21:27:42 UTC, Sönke Ludwig wrote:
But why should UTF validation be the job of the lexer in the
first place?
Because you want to save time, it is faster to integrate
validation? The most likely use scenario is to receive REST data
over HTTP that needs validation.
On 8/25/2014 12:49 PM, simendsjo wrote:
I just happened to write a very small script yesterday and tested with
the compilers (with dub --build=release).
dmd: 2.8 mb
gdc: 3.3 mb
ldc 0.5 mb
So ldc can remove quite a substantial amount of code in some cases.
Speed optimizations are different.
On 8/25/2014 1:35 PM, Sönke Ludwig wrote:
BTW, JSON is *required* to be UTF encoded anyway as per RFC-7159, which is
another argument for just letting the lexer assume valid UTF.
I think that settles it.
Am 25.08.2014 22:51, schrieb "Ola Fosheim Grøstad"
":
On Monday, 25 August 2014 at 20:35:32 UTC, Sönke Ludwig wrote:
BTW, JSON is *required* to be UTF encoded anyway as per RFC-7159,
which is another argument for just letting the lexer assume valid UTF.
The lexer cannot assume valid UTF since
On 8/25/2014 1:21 PM, "Ola Fosheim Grøstad"
" wrote:
On Monday, 25 August 2014 at 20:04:10 UTC, Ola Fosheim Grøstad wrote:
I think supporting signaling NaN is important for correctness.
It is defined in C++11:
http://en.cppreference.com/w/cpp/types/numeric_limits/signaling_NaN
I didn't kno
On Monday, 25 August 2014 at 20:35:32 UTC, Sönke Ludwig wrote:
BTW, JSON is *required* to be UTF encoded anyway as per
RFC-7159, which is another argument for just letting the lexer
assume valid UTF.
The lexer cannot assume valid UTF since the client might be a
rogue, but it can just bail out
Am 25.08.2014 22:21, schrieb Sönke Ludwig:
that standard has no mention of infinity or
NaN
Sorry, to be precise, it has no suggestion of how to *handle* infinity
or NaN.
On Monday, 25 August 2014 at 20:21:01 UTC, Sönke Ludwig wrote:
Well, of course it's based on that RFC, did you seriously think
something else?
I made no assumptions, just responded to what you wrote :-). It
would be reasonable in the context of vibe.d to assume the
ECMAScript spec.
But I ge
Am 25.08.2014 21:50, schrieb "Ola Fosheim Grøstad"
":
On Monday, 25 August 2014 at 19:38:05 UTC, Walter Bright wrote:
The adaptation is to take arbitrary byte input in an unknown encoding
and produce valid UTF.
I agree.
For a restful http service the encoding should be specified in the http
h
- It makes more sense for ECMAScript to turn illegal values into null
since it runs on the client.
Like... node.js?
Sorry, just kidding.
I don't think it makes sense for clients to be less strict about such
things, but I do agree with your assessment about being as strict as
possible on the
On Monday, 25 August 2014 at 20:04:10 UTC, Ola Fosheim Grøstad
wrote:
I think supporting signaling NaN is important for correctness.
It is defined in C++11:
http://en.cppreference.com/w/cpp/types/numeric_limits/signaling_NaN
Am 25.08.2014 17:46, schrieb "Ola Fosheim Grøstad"
":
On Monday, 25 August 2014 at 15:34:29 UTC, Sönke Ludwig wrote:
By default, floating-point special values are now output as 'null',
according to the ECMA-script standard. Optionally, they will be
emitted as 'NaN' and 'Infinity':
ECMAScript p
On Monday, 25 August 2014 at 19:42:03 UTC, Walter Bright wrote:
Infinity. Mapping to max value would be a horrible bug.
Yes… but then you are reading an illegal value that JSON does not
support…
For some reason D does not seem to support this aspect of
IEEE754? I cannot find
".nans" listed
On Monday, 25 August 2014 at 19:38:05 UTC, Walter Bright wrote:
The adaptation is to take arbitrary byte input in an unknown
encoding and produce valid UTF.
I agree.
For a restful http service the encoding should be specified in
the http header and the input rejected if it isn't UTF
compatib
On 08/25/2014 09:35 PM, Walter Bright wrote:
> On 8/23/2014 6:32 PM, Brad Roberts via Digitalmars-d wrote:
>>> I'm not convinced that using an adapter algorithm won't be just as fast.
>> Consider your own talks on optimizing the existing dmd lexer. In
>> those talks
>> you've talked about the evil
On 8/25/2014 6:23 AM, "Ola Fosheim Grøstad"
" wrote:
On Monday, 25 August 2014 at 13:07:08 UTC, Don wrote:
practice. So a JSON parser should at least be able to lex them.
ie this should be parsable:
{"foo": NaN, "bar": Infinity, "baz": -Infinity}
You should also put tests in for what happens
On 8/23/2014 3:51 PM, Andrei Alexandrescu wrote:
An adapter would solve the wrong problem here. There's nothing to adapt from and
to.
An adapter would be good if e.g. the stream uses UTF-16 or some Windows
encoding. Bytes are the natural input for a json parser.
The adaptation is to take arbit
On 8/23/2014 6:32 PM, Brad Roberts via Digitalmars-d wrote:
I'm not convinced that using an adapter algorithm won't be just as fast.
Consider your own talks on optimizing the existing dmd lexer. In those talks
you've talked about the evils of additional processing on every byte. That's
what yo
On Monday, 25 August 2014 at 15:46:12 UTC, Ola Fosheim Grøstad
wrote:
For a web server it would be most useful to get an exception
since you risk ending up with web-clients not working with no
logging. It is better to have an exception and log an error so
the problem can be fixed.
Let me expa
On Monday, 25 August 2014 at 15:34:29 UTC, Sönke Ludwig wrote:
By default, floating-point special values are now output as
'null', according to the ECMA-script standard. Optionally, they
will be emitted as 'NaN' and 'Infinity':
ECMAScript presumes double. I think one should base Phobos on
lan
Am 25.08.2014 16:04, schrieb Sönke Ludwig:
Am 25.08.2014 15:07, schrieb Don:
On Thursday, 21 August 2014 at 22:35:18 UTC, Sönke Ludwig wrote:
Following up on the recent "std.jgrandson" thread [1], I've picked up
the work (a lot earlier than anticipated) and finished a first version
of a loose b
Am 25.08.2014 15:07, schrieb Don:
On Thursday, 21 August 2014 at 22:35:18 UTC, Sönke Ludwig wrote:
Following up on the recent "std.jgrandson" thread [1], I've picked up
the work (a lot earlier than anticipated) and finished a first version
of a loose blend of said std.jgrandson, vibe.data.json a
Am 25.08.2014 14:12, schrieb "Ola Fosheim Grøstad"
":
On Monday, 25 August 2014 at 11:30:15 UTC, Sönke Ludwig wrote:
I've added support (compile time option [1]) for long and BigInt in
the lexer (and parser), see [2]. JSONValue currently still only stores
double for numbers.
It can be very use
On Monday, 25 August 2014 at 13:07:08 UTC, Don wrote:
practice. So a JSON parser should at least be able to lex them.
ie this should be parsable:
{"foo": NaN, "bar": Infinity, "baz": -Infinity}
You should also put tests in for what happens when you pass NaN
or infinity to toJSON. It shouldn't
On Thursday, 21 August 2014 at 22:35:18 UTC, Sönke Ludwig wrote:
Following up on the recent "std.jgrandson" thread [1], I've
picked up the work (a lot earlier than anticipated) and
finished a first version of a loose blend of said
std.jgrandson, vibe.data.json and some changes that I had
plann
On Monday, 25 August 2014 at 11:30:15 UTC, Sönke Ludwig wrote:
I've added support (compile time option [1]) for long and
BigInt in the lexer (and parser), see [2]. JSONValue currently
still only stores double for numbers.
It can be very useful to have a base 10 exponent representation
in cert
I've added support (compile time option [1]) for long and BigInt in the
lexer (and parser), see [2]. JSONValue currently still only stores
double for numbers. There are two options for extending JSONValue:
1. Add long and BigInt to the set of supported types for JSONValue. This
preserves all f
On 8/23/2014 3:20 PM, Walter Bright via Digitalmars-d wrote:
On 8/23/2014 12:00 PM, Brad Roberts via Digitalmars-d wrote:
On 8/23/2014 10:46 AM, Walter Bright via Digitalmars-d wrote:
I feel that non-UTF encodings should be handled by adapter algorithms,
not embedded into the JSON lexer, so yes
On 8/23/14, 3:24 PM, Walter Bright wrote:
On 8/23/2014 2:36 PM, Andrei Alexandrescu wrote:
I think accepting ubyte it's a good idea. It means "got this stream of
bytes off
of the wire and it hasn't been validated as a UTF string". It also
means (which
is true) that the lexer does enough validati
On 8/23/2014 2:36 PM, Andrei Alexandrescu wrote:
I think accepting ubyte it's a good idea. It means "got this stream of bytes off
of the wire and it hasn't been validated as a UTF string". It also means (which
is true) that the lexer does enough validation to constrain arbitrary bytes into
text,
On 8/23/2014 12:00 PM, Brad Roberts via Digitalmars-d wrote:
On 8/23/2014 10:46 AM, Walter Bright via Digitalmars-d wrote:
I feel that non-UTF encodings should be handled by adapter algorithms,
not embedded into the JSON lexer, so yes, I'd drop that.
For performance purposes, determining encod
On 8/23/14, 10:46 AM, Walter Bright wrote:
On 8/23/2014 10:42 AM, Sönke Ludwig wrote:
Am 23.08.2014 19:38, schrieb Walter Bright:
On 8/23/2014 9:36 AM, Sönke Ludwig wrote:
input types "string" and "immutable(ubyte)[]"
Why the immutable(ubyte)[] ?
I've adopted that basically from Andrei's m
On Saturday, 23 August 2014 at 09:22:01 UTC, Sönke Ludwig wrote:
Main issues of using opDispatch:
- Prone to bugs where a normal field/method of the JSONValue
struct is accessed instead of a JSON field
- On top of that the var.field syntax gives the wrong
impression that you are working with
Some baselines for performance:
https://github.com/mloskot/json_benchmark
http://chadaustin.me/2013/01/json-parser-benchmarking/
On Saturday, 23 August 2014 at 19:01:13 UTC, Brad Roberts via
Digitalmars-d wrote:
original string is ascii or utf-8 or other. The cost during
lexing is essentially zero.
I am not so sure when it comes to SIMD lexing. I think the
specified behaviour should be done in a way which encourage lat
On 8/23/2014 10:46 AM, Walter Bright via Digitalmars-d wrote:
On 8/23/2014 10:42 AM, Sönke Ludwig wrote:
Am 23.08.2014 19:38, schrieb Walter Bright:
On 8/23/2014 9:36 AM, Sönke Ludwig wrote:
input types "string" and "immutable(ubyte)[]"
Why the immutable(ubyte)[] ?
I've adopted that basica
Am 23.08.2014 20:31, schrieb "Marc Schütz" ":
On Saturday, 23 August 2014 at 17:32:01 UTC, Sönke Ludwig wrote:
Am 23.08.2014 19:25, schrieb "Marc Schütz" ":
On Saturday, 23 August 2014 at 16:49:23 UTC, Sönke Ludwig wrote:
Am 22.08.2014 21:00, schrieb "Marc Schütz" ":
On Friday, 22 August 2014
On Saturday, 23 August 2014 at 17:32:01 UTC, Sönke Ludwig wrote:
Am 23.08.2014 19:25, schrieb "Marc Schütz" ":
On Saturday, 23 August 2014 at 16:49:23 UTC, Sönke Ludwig
wrote:
Am 22.08.2014 21:00, schrieb "Marc Schütz"
":
On Friday, 22 August 2014 at 18:08:34 UTC, Sönke Ludwig
wrote:
Am 22.08.
On 8/23/2014 10:42 AM, Sönke Ludwig wrote:
Am 23.08.2014 19:38, schrieb Walter Bright:
On 8/23/2014 9:36 AM, Sönke Ludwig wrote:
input types "string" and "immutable(ubyte)[]"
Why the immutable(ubyte)[] ?
I've adopted that basically from Andrei's module. The idea is to allow
processing data
1 - 100 of 166 matches
Mail list logo
