Jump to page: 1 226  
Page
Thread overview
std.data.json formal review
Jul 28, 2015
Atila Neves
Jul 28, 2015
Rikki Cattermole
Jul 28, 2015
Etienne Cimon
Jul 28, 2015
Brad Anderson
Jul 28, 2015
Etienne Cimon
Jul 29, 2015
Rikki Cattermole
Jul 28, 2015
Mathias Lang
Jul 29, 2015
Rikki Cattermole
Jul 28, 2015
Sönke Ludwig
Jul 29, 2015
Rikki Cattermole
Jul 28, 2015
Sönke Ludwig
Jul 29, 2015
Rikki Cattermole
Jul 28, 2015
Etienne Cimon
Jul 28, 2015
Sönke Ludwig
Jul 28, 2015
Brad Anderson
Jul 29, 2015
Etienne Cimon
Jul 28, 2015
Sönke Ludwig
Jul 28, 2015
Walter Bright
Jul 28, 2015
H. S. Teoh
Jul 28, 2015
Walter Bright
Jul 29, 2015
H. S. Teoh
Jul 29, 2015
Walter Bright
Jul 29, 2015
Jacob Carlborg
Jul 29, 2015
Sönke Ludwig
Jul 29, 2015
Walter Bright
Jul 29, 2015
Jacob Carlborg
Jul 29, 2015
Walter Bright
Jul 30, 2015
Jacob Carlborg
Jul 29, 2015
Walter Bright
Jul 29, 2015
H. S. Teoh
Jul 29, 2015
Walter Bright
Jul 29, 2015
Sönke Ludwig
Jul 29, 2015
Walter Bright
Jul 29, 2015
Sönke Ludwig
Jul 30, 2015
Walter Bright
Jul 30, 2015
Sönke Ludwig
Jul 29, 2015
Sönke Ludwig
Jul 30, 2015
Piotr Szturmaj
Jul 29, 2015
Sönke Ludwig
Jul 30, 2015
Walter Bright
Jul 30, 2015
Suliman
Jul 30, 2015
Sönke Ludwig
Jul 30, 2015
Brad Anderson
Jul 30, 2015
Walter Bright
Jul 30, 2015
H. S. Teoh
Jul 30, 2015
Walter Bright
Jul 30, 2015
H. S. Teoh
Jul 31, 2015
Suliman
Jul 31, 2015
Sönke Ludwig
Jul 31, 2015
Suliman
Aug 01, 2015
Sönke Ludwig
Aug 01, 2015
Suliman
Aug 01, 2015
Suliman
Aug 01, 2015
Sönke Ludwig
Aug 01, 2015
Suliman
Aug 01, 2015
Suliman
Jul 30, 2015
Jacob Carlborg
Aug 21, 2015
Nick Sabalausky
Aug 21, 2015
David Nadlinger
Aug 22, 2015
Nick Sabalausky
Jul 29, 2015
Don
Jul 29, 2015
H. S. Teoh
Jul 29, 2015
Laeeth Isharc
Jul 29, 2015
sigod
Jul 29, 2015
Sönke Ludwig
Jul 29, 2015
matovitch
Jul 29, 2015
Sönke Ludwig
Jul 29, 2015
Sönke Ludwig
Aug 02, 2015
Dmitry Olshansky
Aug 03, 2015
Sönke Ludwig
Aug 03, 2015
Dmitry Olshansky
Sep 27, 2015
Marco Leise
Sep 27, 2015
Dmitry Olshansky
Jul 28, 2015
Walter Bright
Jul 28, 2015
Brad Anderson
Jul 28, 2015
Walter Bright
Jul 29, 2015
Andrea Fontana
Jul 29, 2015
Sönke Ludwig
Jul 29, 2015
Andrea Fontana
Jul 30, 2015
Sönke Ludwig
Aug 03, 2015
deadalnix
Aug 04, 2015
Sönke Ludwig
Aug 04, 2015
deadalnix
Aug 11, 2015
Sönke Ludwig
Aug 11, 2015
deadalnix
Aug 12, 2015
Sönke Ludwig
Aug 12, 2015
Meta
Aug 11, 2015
Atila Neves
Aug 11, 2015
deadalnix
Aug 11, 2015
Dmitry Olshansky
Aug 11, 2015
Sönke Ludwig
Aug 12, 2015
Dmitry Olshansky
Aug 12, 2015
Sönke Ludwig
Aug 14, 2015
Walter Bright
Aug 14, 2015
Sönke Ludwig
Aug 14, 2015
Walter Bright
Aug 14, 2015
Walter Bright
Aug 14, 2015
Matthias Bentrup
Aug 11, 2015
Sönke Ludwig
Aug 11, 2015
deadalnix
Aug 12, 2015
Sönke Ludwig
Aug 12, 2015
Sönke Ludwig
Aug 14, 2015
Timon Gehr
Aug 17, 2015
Dmitry Olshansky
Aug 18, 2015
Dmitry Olshansky
Aug 18, 2015
Dmitry Olshansky
Aug 18, 2015
Dmitry Olshansky
Aug 17, 2015
deadalnix
Aug 18, 2015
Marc Schütz
Aug 18, 2015
Johannes Pfau
Aug 18, 2015
Johannes Pfau
Aug 18, 2015
deadalnix
Aug 18, 2015
deadalnix
Aug 17, 2015
Sönke Ludwig
Aug 17, 2015
Johannes Pfau
Aug 17, 2015
Suliman
Aug 17, 2015
Sönke Ludwig
Aug 17, 2015
Suliman
Aug 17, 2015
Sönke Ludwig
Aug 17, 2015
Suliman
Aug 17, 2015
Sönke Ludwig
Aug 17, 2015
Suliman
Aug 17, 2015
Sönke Ludwig
Aug 17, 2015
Suliman
Aug 18, 2015
Sönke Ludwig
Aug 22, 2015
Sönke Ludwig
Aug 12, 2015
deadalnix
Aug 12, 2015
Sönke Ludwig
Aug 13, 2015
Walter Bright
Aug 13, 2015
CraigDillabaugh
Aug 14, 2015
Walter Bright
Aug 14, 2015
Craig Dillabaugh
Aug 14, 2015
deadalnix
Aug 14, 2015
rsw0x
Aug 14, 2015
Walter Bright
Aug 14, 2015
Walter Bright
Aug 14, 2015
Walter Bright
Aug 21, 2015
Nick Sabalausky
Aug 14, 2015
Adam D. Ruppe
Aug 14, 2015
Brad Anderson
Aug 14, 2015
Walter Bright
Aug 14, 2015
Dmitry Olshansky
Aug 14, 2015
Walter Bright
Aug 14, 2015
Jacob Carlborg
Aug 14, 2015
Rikki Cattermole
Aug 14, 2015
Walter Bright
Aug 15, 2015
suliman
Aug 15, 2015
Walter Bright
Aug 21, 2015
Nick Sabalausky
Aug 14, 2015
Dmitry Olshansky
Aug 13, 2015
Sönke Ludwig
Aug 14, 2015
Walter Bright
Aug 14, 2015
Sönke Ludwig
Aug 14, 2015
Walter Bright
Aug 15, 2015
Sönke Ludwig
Aug 15, 2015
Suliman
Aug 15, 2015
Laeeth Isharc
Aug 16, 2015
Walter Bright
Aug 16, 2015
Dmitry Olshansky
Aug 16, 2015
Walter Bright
Aug 16, 2015
Dmitry Olshansky
Aug 16, 2015
Walter Bright
Aug 16, 2015
Sönke Ludwig
Aug 16, 2015
Jacob Carlborg
Aug 16, 2015
Walter Bright
Aug 22, 2015
Sönke Ludwig
Aug 24, 2015
Walter Bright
Aug 25, 2015
Sönke Ludwig
Aug 25, 2015
Sebastiaan Koppe
Aug 25, 2015
Sönke Ludwig
Aug 16, 2015
Jay Norwood
Aug 17, 2015
Sönke Ludwig
Aug 18, 2015
Jacob Carlborg
Aug 18, 2015
Jacob Carlborg
Aug 18, 2015
Jacob Carlborg
Aug 19, 2015
Dmitry Olshansky
Aug 19, 2015
Sönke Ludwig
Aug 22, 2015
Sönke Ludwig
Aug 21, 2015
Nick Sabalausky
Aug 21, 2015
David Nadlinger
Aug 24, 2015
Jacob Carlborg
Aug 18, 2015
Marc Schütz
Sep 28, 2015
Marco Leise
Sep 29, 2015
Marc Schütz
Sep 29, 2015
Laeeth Isharc
Sep 30, 2015
Marco Leise
Aug 18, 2015
Sönke Ludwig
Aug 21, 2015
tired_eyes
Aug 21, 2015
H. S. Teoh
Aug 21, 2015
H. S. Teoh
Aug 22, 2015
Sönke Ludwig
Aug 25, 2015
Martin Nowak
Aug 25, 2015
Sönke Ludwig
Aug 25, 2015
Martin Nowak
Aug 19, 2015
Timon Gehr
Aug 19, 2015
Jacob Carlborg
Aug 25, 2015
Martin Nowak
Aug 25, 2015
Timon Gehr
Aug 25, 2015
Martin Nowak
Sep 24, 2015
tired_eyes
Sep 25, 2015
Atila Neves
Oct 02, 2015
Marco Leise
Oct 06, 2015
Alex
Oct 06, 2015
Sönke Ludwig
Oct 06, 2015
Sebastiaan Koppe
Oct 06, 2015
Atila Neves
Oct 10
Basile B.
July 28, 2015
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
July 28, 2015
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 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 (optionally) and have it use that for all memory usage?

After all, I really would rather be able to deallocate all memory allocated during a request then you know, rely on the GC.
July 28, 2015
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 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 (optionally) and have it use that for all memory usage?
>
> After all, I really would rather be able to deallocate all memory allocated during a request then you know, rely on the GC.

I totally agree with that, but shouldn't it be consistent in Phobos? I don't think it's possible to make an interface for custom allocators right now, because that question simply hasn't been ironed out along with std.allocator.

So, anything related to allocators belongs in another thread imo, and the review process here would be about the actual json interface
July 28, 2015
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:
https://github.com/s-ludwig/std_data_json/blob/aac6d846d596750623fd5c546343f4f9d19447fa/source/stdx/data/json/value.d#L183

I was getting tired of programmatically checking for null, then checking for object type, before moving along in the object and doing the same recursively. Not quite as intuitive as the optional chaining ?. operator in swift but it gets pretty close https://blog.sabintsev.com/optionals-in-swift-c94fd231e7a4#5622
July 28, 2015
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 reminder that this is the review thread, not the vote thread (in case anyone reading got confused).

> 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 (optionally) and have it use that for all memory usage?
>
> After all, I really would rather be able to deallocate all memory allocated during a request then you know, rely on the GC.

That's a good point. This is the perfect opportunity to hammer out how allocators are going to be integrated into other parts of Phobos.
July 28, 2015
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: http://s-ludwig.github.io/std_data_json/
>>>
>>> Atila
>>
>> Right now, my view is no.
>
> Just a reminder that this is the review thread, not the vote thread (in case anyone reading got confused).
>
>> 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 (optionally) and have it use that for all memory usage?
>>
>> After all, I really would rather be able to deallocate all memory allocated during a request then you know, rely on the GC.
>
> That's a good point. This is the perfect opportunity to hammer out how allocators are going to be integrated into other parts of Phobos.

From what I see from std.allocator, there's no Allocator interface? I think this would require changing the type to `struct JSONValue(Allocator)`, unless we see an actual interface implemented in phobos.
July 28, 2015
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 (optionally) and have it use that for all memory usage?
>>
>> After all, I really would rather be able to deallocate all memory allocated during a request then you know, rely on the GC.
>>
>
> That's a good point. This is the perfect opportunity to hammer out how allocators are going to be integrated into other parts of Phobos.
>

Allocator is definitely a separate issue. It's a moving target, it's not
yet part of a release, and consequently barely field-tested. We will find
bugs, we might find design mistakes, we might head in a direction which
will turn out to be an anti-pattern (just like `opDispatch` for JSONValue
;) )
It's not to say the quality of the module isn't good - that would mean our
release process is broken -, but making a module inclusion to experimental
dependent on another module in experimental will not improve the quality of
the reviewed module.


July 28, 2015
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 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 (optionally) and
> have it use that for all memory usage?
>
> After all, I really would rather be able to deallocate all memory
> allocated during a request then you know, rely on the GC.

If you pass a string or byte array as input, then there will be no allocations at all (the interface is @nogc).

For other cases it supports custom allocation through an appender factory [1][2], since there is no standard allocator interface, yet. But since that's the only place where memory is allocated (apart from lower level code, such as BigInt), as soon as Appender supports custom allocators, or you write your own appender, the JSON parser will, too.

Only if you use the DOM parser, there will be some inevitable GC allocations, because the DOM representation uses dynamic and associative arrays.

1: https://github.com/s-ludwig/std_data_json/blob/aac6d846d596750623fd5c546343f4f9d19447fa/source/stdx/data/json/lexer.d#L66
2: https://github.com/s-ludwig/std_data_json/blob/aac6d846d596750623fd5c546343f4f9d19447fa/source/stdx/data/json/parser.d#L286
July 28, 2015
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.
July 28, 2015
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?
« First   ‹ Prev
1 2 3 4 5 6 7 8 9 10 11