If this implementation will be merged with phobos will vibed
migrate to it, or it would two similar libs?
On Wed, Jul 29, 2015 at 03:22:05PM +, Don via Digitalmars-d wrote:
On Tuesday, 28 July 2015 at 22:29:01 UTC, Walter Bright wrote:
[...]
The possible JSON values are:
string
number
object (associative arrays)
array
true
false
null
Since these are D
Here's a thought: what about always storing JSON numbers as
strings (albeit tagged with the number type, to differentiate
them from actual strings in the input), and the user specifies
what type to convert it to? The default type can be something
handy, like int, but the user has the option
On Wednesday, 29 July 2015 at 17:04:33 UTC, Laeeth Isharc wrote:
[...]
Some JSON files can be quite large...
For example, I have a compressed 175 Gig of Reddit comments
(one file per month) I would like to work with using D, and
time + memory demands = money.
Wouldn't it be a pain not to
Am 29.07.2015 um 17:22 schrieb Don:
Related to this: it should not be importing std.bigint. Note that if
std.bigint were fully implemented, it would be very heavyweight (optimal
multiplication of enormous integers involves fast fourier transforms and
all kinds of odd stuff, that's really
Am 29.07.2015 um 18:47 schrieb H. S. Teoh via Digitalmars-d:
On Wed, Jul 29, 2015 at 03:22:05PM +, Don via Digitalmars-d wrote:
On Tuesday, 28 July 2015 at 22:29:01 UTC, Walter Bright wrote:
[...]
The possible JSON values are:
string
number
object (associative arrays)
On Tuesday, 28 July 2015 at 22:29:01 UTC, Walter Bright wrote:
On 7/28/2015 7:07 AM, Atila Neves wrote:
Start of the two week process, folks.
Thank you very much, Sönke, for taking this on. Thank you,
Atila, for taking on the thankless job of being review manager.
Just looking at the
Am 29.07.2015 um 20:44 schrieb Walter Bright:
On 7/29/2015 1:37 AM, Sönke Ludwig wrote:
There are actually even four levels:
1. Range of characters
2. Range of tokens
3. Range of nodes
4. DOM value
What's the need for users to see a token stream? I don't know what the
DOM value is - is that
On 7/29/2015 1:37 AM, Sönke Ludwig wrote:
There are actually even four levels:
1. Range of characters
2. Range of tokens
3. Range of nodes
4. DOM value
What's the need for users to see a token stream? I don't know what the DOM value
is - is that just JSON as an ast?
Having a special case
Hi Sonke,
Great to see your module moving towards phobos inclusion (I have
not been following the latest progress of D sadly :() ! Just a
small remark from the documentation example.
Maybe it would be better to replace :
value.toJSONString!true()
by
value.toJSONString!prettify()
On 7/29/2015 3:10 AM, Jacob Carlborg wrote:
On 2015-07-29 06:57, Walter Bright wrote:
A JSON value is a tagged union of the various types.
But in most cases I think there will be one root node, of type object.
An object is a collection of other Values.
In that case it would be range
Am 29.07.2015 um 20:21 schrieb matovitch:
Hi Sonke,
Great to see your module moving towards phobos inclusion (I have not
been following the latest progress of D sadly :() ! Just a small remark
from the documentation example.
Maybe it would be better to replace :
value.toJSONString!true()
On 7/28/2015 10:49 PM, H. S. Teoh via Digitalmars-d wrote:
How does a linear range of nodes convey a nested structure?
You'd need to add a special node type, 'end'. So an array [1,true] would look
like:
array number true end
On 2015-07-29 20:33, Walter Bright wrote:
On 7/29/2015 3:10 AM, Jacob Carlborg wrote:
But in most cases I think there will be one root node, of type object.
An object is a collection of other Values.
In that case it would be range with only one element? How does that
help?
I don't
W dniu 2015-07-29 o 00:37, H. S. Teoh via Digitalmars-d pisze:
On Tue, Jul 28, 2015 at 03:29:02PM -0700, Walter Bright via Digitalmars-d wrote:
[...]
3. Stepping back a bit, when I think of parsing JSON data, I think:
auto ast = inputrange.toJSON();
where toJSON() accepts an input range
On 7/29/2015 11:51 AM, Jacob Carlborg wrote:
I guess I'm finding it difficult to picture a JSON structure as a range. How
would the following JSON be returned as a range?
{
a: 1,
b: [2, 3],
c: { d: 4 }
}
It if was returned as a range of nodes, it would be:
Object, string,
On 7/29/2015 1:41 PM, Sönke Ludwig wrote:
The token level is useful for reasoning about the text representation. It could
be used for example to implement syntax highlighting, or for using the location
information to mark errors in the source code.
Ok, I see your point. The question then
On 7/29/2015 1:18 AM, Sönke Ludwig wrote:
Am 29.07.2015 um 00:29 schrieb Walter Bright:
1. Not sure that 'JSON' needs to be embedded in the public names.
'parseJSONStream' should just be 'parseStream', etc. Name
disambiguation, if needed, should be ably taken care of by a number of D
features
Am 29.07.2015 um 07:43 schrieb Walter Bright:
On 7/28/2015 3:55 PM, Walter Bright wrote:
OTOH, some people might want the option of parser-driven data processing
instead (e.g. the JSON data is very large and we don't want to store the
whole thing in memory at once).
That is a good point.
So
Am 29.07.2015 um 09:46 schrieb Andrea Fontana:
On Tuesday, 28 July 2015 at 14:07:19 UTC, Atila Neves wrote:
Start of the two week process, folks.
Code: https://github.com/s-ludwig/std_data_json
Docs: http://s-ludwig.github.io/std_data_json/
Atila
Why don't do a shortcut like:
Am 29.07.2015 um 00:37 schrieb H. S. Teoh via Digitalmars-d:
On Tue, Jul 28, 2015 at 03:29:02PM -0700, Walter Bright via Digitalmars-d wrote:
[...]
3. Stepping back a bit, when I think of parsing JSON data, I think:
auto ast = inputrange.toJSON();
where toJSON() accepts an input range
On Tuesday, 28 July 2015 at 14:07:19 UTC, Atila Neves wrote:
Start of the two week process, folks.
Code: https://github.com/s-ludwig/std_data_json
Docs: http://s-ludwig.github.io/std_data_json/
Atila
Why don't do a shortcut like:
jv.opt(/this/is/a/path) ?
I use it in my json/bson binding.
Am 29.07.2015 um 00:29 schrieb Walter Bright:
On 7/28/2015 7:07 AM, Atila Neves wrote:
Start of the two week process, folks.
Thank you very much, Sönke, for taking this on. Thank you, Atila, for
taking on the thankless job of being review manager.
Just looking at the documentation only, some
On 2015-07-29 06:57, Walter Bright wrote:
A JSON value is a tagged union of the various types.
But in most cases I think there will be one root node, of type object.
In that case it would be range with only one element? How does that help?
--
/Jacob Carlborg
Am 29.07.2015 um 12:10 schrieb Jacob Carlborg:
On 2015-07-29 06:57, Walter Bright wrote:
A JSON value is a tagged union of the various types.
But in most cases I think there will be one root node, of type object.
In that case it would be range with only one element? How does that help?
I
On Wednesday, 29 July 2015 at 08:55:20 UTC, Sönke Ludwig wrote:
That would be another possibility. What do you think about the
opt(jv).foo.bar[12].baz alternative? One advantage is that it
could work without parsing a string and the implications
thereof (error handling?).
I implemented it
http://forum.dlang.org/thread/nbuhouhimowvcqssv...@forum.dlang.org
On 7/28/2015 7:07 AM, Atila Neves wrote:
Start of the two week process, folks.
Thank you very much, Sönke, for taking this on. Thank you, Atila, for taking on
the thankless job of being review manager.
Just looking at the documentation only, some general notes:
1. Not sure that 'JSON'
On Tue, Jul 28, 2015 at 03:55:22PM -0700, Walter Bright via Digitalmars-d wrote:
On 7/28/2015 3:37 PM, H. S. Teoh via Digitalmars-d wrote:
On Tue, Jul 28, 2015 at 03:29:02PM -0700, Walter Bright via Digitalmars-d
wrote:
Ideally, I'd say hook it up to std.conv.to for maximum flexibility.
Then
On 7/28/2015 3:37 PM, H. S. Teoh via Digitalmars-d wrote:
On Tue, Jul 28, 2015 at 03:29:02PM -0700, Walter Bright via Digitalmars-d wrote:
Ideally, I'd say hook it up to std.conv.to for maximum flexibility. Then
you can just use to() to convert between a JSON container and the value
that it
A speed optimization, since JSON parsing speed is critical:
If the parser is able to use slices of its input, store numbers as slices. Only
convert them to numbers lazily, as the numeric conversion can take significant time.
On Tuesday, 28 July 2015 at 23:16:34 UTC, Walter Bright wrote:
A speed optimization, since JSON parsing speed is critical:
If the parser is able to use slices of its input, store numbers
as slices. Only convert them to numbers lazily, as the numeric
conversion can take significant time.
On Tuesday, 28 July 2015 at 18:45:51 UTC, Sönke Ludwig wrote:
Am 28.07.2015 um 17:19 schrieb Etienne Cimon:
On Tuesday, 28 July 2015 at 14:07:19 UTC, Atila Neves wrote:
Start of the two week process, folks.
Code: https://github.com/s-ludwig/std_data_json
Docs:
Start of the two week process, folks.
Code: https://github.com/s-ludwig/std_data_json
Docs: http://s-ludwig.github.io/std_data_json/
Atila
On 29/07/2015 4:25 a.m., Mathias Lang via Digitalmars-d wrote:
2015-07-28 17:55 GMT+02:00 Brad Anderson via Digitalmars-d
digitalmars-d@puremagic.com mailto:digitalmars-d@puremagic.com:
Unless there is some sort of proof that it will work with
allocators.
I have used
On 29/07/2015 4:23 a.m., Etienne Cimon wrote:
On Tuesday, 28 July 2015 at 15:55:04 UTC, Brad Anderson wrote:
On Tuesday, 28 July 2015 at 15:07:46 UTC, Rikki Cattermole wrote:
On 29/07/2015 2:07 a.m., Atila Neves wrote:
Start of the two week process, folks.
Code:
On 29/07/2015 2:07 a.m., Atila Neves wrote:
Start of the two week process, folks.
Code: https://github.com/s-ludwig/std_data_json
Docs: http://s-ludwig.github.io/std_data_json/
Atila
Right now, my view is no.
Unless there is some sort of proof that it will work with allocators.
I have used
On Tuesday, 28 July 2015 at 15:07:46 UTC, Rikki Cattermole wrote:
On 29/07/2015 2:07 a.m., Atila Neves wrote:
Start of the two week process, folks.
Code: https://github.com/s-ludwig/std_data_json
Docs: http://s-ludwig.github.io/std_data_json/
Atila
Right now, my view is no.
Just a
On Tuesday, 28 July 2015 at 15:07:46 UTC, Rikki Cattermole wrote:
On 29/07/2015 2:07 a.m., Atila Neves wrote:
Start of the two week process, folks.
Code: https://github.com/s-ludwig/std_data_json
Docs: http://s-ludwig.github.io/std_data_json/
Atila
Right now, my view is no.
Unless there is
On Tuesday, 28 July 2015 at 14:07:19 UTC, Atila Neves wrote:
Start of the two week process, folks.
Code: https://github.com/s-ludwig/std_data_json
Docs: http://s-ludwig.github.io/std_data_json/
Atila
This is cool:
On 7/28/2015 3:55 PM, Walter Bright wrote:
OTOH, some people might want the option of parser-driven data processing
instead (e.g. the JSON data is very large and we don't want to store the
whole thing in memory at once).
That is a good point.
So it appears that JSON can be in one of 3 useful
On Tue, Jul 28, 2015 at 10:43:20PM -0700, Walter Bright via Digitalmars-d wrote:
On 7/28/2015 3:55 PM, Walter Bright wrote:
OTOH, some people might want the option of parser-driven data
processing instead (e.g. the JSON data is very large and we don't
want to store the whole thing in memory at
On 7/28/2015 5:15 PM, H. S. Teoh via Digitalmars-d wrote:
Probably simply returning an InputRange of JSON values.
But how would you capture the nesting substructures?
A JSON value is a tagged union of the various types.
??! Surely you have heard of the non-allocating overload of toString?
On 29/07/2015 4:43 a.m., Sönke Ludwig wrote:
Am 28.07.2015 um 17:07 schrieb Rikki Cattermole:
I have used the code from vibe.d days so its not an issue of how well it
works nor nit picky.
You should still have a closer look, as it isn't very similar to the
vibe.d code at all, but a rather
On 29/07/2015 4:41 a.m., Sönke Ludwig wrote:
Am 28.07.2015 um 17:07 schrieb Rikki Cattermole:
On 29/07/2015 2:07 a.m., Atila Neves wrote:
Start of the two week process, folks.
Code: https://github.com/s-ludwig/std_data_json
Docs: http://s-ludwig.github.io/std_data_json/
Atila
Right now, my
Am 28.07.2015 um 17:07 schrieb Rikki Cattermole:
On 29/07/2015 2:07 a.m., Atila Neves wrote:
Start of the two week process, folks.
Code: https://github.com/s-ludwig/std_data_json
Docs: http://s-ludwig.github.io/std_data_json/
Atila
Right now, my view is no.
Unless there is some sort of
2015-07-28 17:55 GMT+02:00 Brad Anderson via Digitalmars-d
digitalmars-d@puremagic.com:
Unless there is some sort of proof that it will work with allocators.
I have used the code from vibe.d days so its not an issue of how well it
works nor nit picky. Just can I pass it an allocator
Am 28.07.2015 um 17:07 schrieb Rikki Cattermole:
I have used the code from vibe.d days so its not an issue of how well it
works nor nit picky.
You should still have a closer look, as it isn't very similar to the
vibe.d code at all, but a rather radical evolution.
On Tuesday, 28 July 2015 at 15:55:04 UTC, Brad Anderson wrote:
On Tuesday, 28 July 2015 at 15:07:46 UTC, Rikki Cattermole
wrote:
On 29/07/2015 2:07 a.m., Atila Neves wrote:
Start of the two week process, folks.
Code: https://github.com/s-ludwig/std_data_json
Docs:
Am 28.07.2015 um 16:07 schrieb Atila Neves:
Start of the two week process, folks.
Code: https://github.com/s-ludwig/std_data_json
Docs: http://s-ludwig.github.io/std_data_json/
Atila
Thanks for making it happen! Can you also post a quick link to this
thread in D.announce?
Am 28.07.2015 um 17:19 schrieb Etienne Cimon:
On Tuesday, 28 July 2015 at 14:07:19 UTC, Atila Neves wrote:
Start of the two week process, folks.
Code: https://github.com/s-ludwig/std_data_json
Docs: http://s-ludwig.github.io/std_data_json/
Atila
This is cool:
On Tuesday, 28 July 2015 at 18:45:51 UTC, Sönke Ludwig wrote:
An idea might be to support something like this:
json_value.opt.foo.bar[2].baz
or
opt(json_value).foo.bar[2].baz
opt (name is debatable) would return a wrapper struct around
the JSONValue that supports opDispatch/opIndex and
On Tue, Jul 28, 2015 at 03:29:02PM -0700, Walter Bright via Digitalmars-d wrote:
[...]
3. Stepping back a bit, when I think of parsing JSON data, I think:
auto ast = inputrange.toJSON();
where toJSON() accepts an input range and produces a container, the
ast. The ast is just a JSON
On 7/28/2015 4:24 PM, Brad Anderson wrote:
On Tuesday, 28 July 2015 at 23:16:34 UTC, Walter Bright wrote:
A speed optimization, since JSON parsing speed is critical:
If the parser is able to use slices of its input, store numbers as slices.
Only convert them to numbers lazily, as the numeric
201 - 254 of 254 matches
Mail list logo
