Re: Json in D: clean, simple API
On Thursday, 11 May 2017 at 20:56:09 UTC, aberba wrote: Something like this is exactly what I'm talking about. Vibe.data.json also has: // using piecewise construction Json j2 = Json.emptyObject; j2["field1"] = "foo"; j2["field2"] = 42.0; j2["field3"] = true; Yeah, mine can do that too, just change `Json` to `var`. I even coincidentally called it `emptyObject` too, cool. Mine also allows you do do math and concatenations and even assign functions, it is crazy what D can do.
Re: Json in D: clean, simple API
On Thursday, 11 May 2017 at 20:36:13 UTC, Adam D. Ruppe wrote:
On Thursday, 11 May 2017 at 20:22:22 UTC, aberba wrote:
With that i meant designing of a simple-clean api
my jsvar.d works kinda similarly to javascript... though i
wouldn't call it "clean" because it will not inform you of
missing stuff.
jsvar.d is here:
https://raw.githubusercontent.com/adamdruppe/arsd/master/jsvar.d
---
// dmd test.d jsvar.d
import arsd.jsvar;
import std.stdio;
void main() {
// reading json with `var.fromJson`
var obj = var.fromJson(`{"a":{"b":10},"c":"hi"}`);
// inspecting contents
writeln(obj.a);
writeln(obj.a.b);
writeln(obj.c);
// convert to basic static type with `.get!T`
string c = obj.c.get!string;
// change the contents with dot notation
obj.a = 15;
obj.d = "add new field too";
writeln(obj);
struct Test {
int a;
string c;
}
// can even get plain structs out
Test test = obj.get!Test;
writeln(test);
// and set structs
test.c = "from D";
obj = test;
writeln(obj);
// writeln on an object prints it in json
// or you can explicitly do
writeln(obj.toJson());
// big thing is referencing non-existent
// things is not an error, it just propagates null:
writeln(obj.no.such.property); // null
// but that can be convenient
}
---
Something like this is exactly what I'm talking about.
Vibe.data.json also has:
// using piecewise construction
Json j2 = Json.emptyObject;
j2["field1"] = "foo";
j2["field2"] = 42.0;
j2["field3"] = true;
D doesn't seem to be the blocker for these convenient
abstractions.
Re: Json in D: clean, simple API
On Thursday, 11 May 2017 at 19:49:54 UTC, cym13 wrote: On Thursday, 11 May 2017 at 19:33:09 UTC, aberba wrote: Json libs in D seem not straight foward. I've seen several wrappers and (De)serializers trying to abstract std.json. std_data_json proposed to replace std.json doesnt *seem* to tackle straigh-forward json process like I find vibe.data.json. Handy stuff I'm not finding but much simple in vibe.data.json include piecewise construction (constructing json objects like associative arrays) and vibe.data.json's value.get!T. API feel also *feels* not straight-forward. Are all the capabilities of std_data_json what I see in its docs? Why does json seem hard in D and why is std.json still there? Try https://github.com/tamediadigital/asdf ? Not much helpful for my use case though it can be really useful for json-heavy rest api. Interesting.
Re: Json in D: clean, simple API
On Thursday, 11 May 2017 at 20:22:22 UTC, aberba wrote:
With that i meant designing of a simple-clean api
my jsvar.d works kinda similarly to javascript... though i
wouldn't call it "clean" because it will not inform you of
missing stuff.
jsvar.d is here:
https://raw.githubusercontent.com/adamdruppe/arsd/master/jsvar.d
---
// dmd test.d jsvar.d
import arsd.jsvar;
import std.stdio;
void main() {
// reading json with `var.fromJson`
var obj = var.fromJson(`{"a":{"b":10},"c":"hi"}`);
// inspecting contents
writeln(obj.a);
writeln(obj.a.b);
writeln(obj.c);
// convert to basic static type with `.get!T`
string c = obj.c.get!string;
// change the contents with dot notation
obj.a = 15;
obj.d = "add new field too";
writeln(obj);
struct Test {
int a;
string c;
}
// can even get plain structs out
Test test = obj.get!Test;
writeln(test);
// and set structs
test.c = "from D";
obj = test;
writeln(obj);
// writeln on an object prints it in json
// or you can explicitly do
writeln(obj.toJson());
// big thing is referencing non-existent
// things is not an error, it just propagates null:
writeln(obj.no.such.property); // null
// but that can be convenient
}
---
Re: Json in D: clean, simple API
On Thursday, 11 May 2017 at 20:04:35 UTC, Adam D. Ruppe wrote: On Thursday, 11 May 2017 at 19:33:09 UTC, aberba wrote: Why does json seem hard in D What are you actually looking for? With that i meant designing of a simple-clean api
Re: Json in D: clean, simple API
On Thursday, 11 May 2017 at 20:04:35 UTC, Adam D. Ruppe wrote: On Thursday, 11 May 2017 at 19:33:09 UTC, aberba wrote: Why does json seem hard in D What are you actually looking for? I managed to do the task but api makes code not clean for such simple tasks (AA to json, json to AA, json["new key"] = newJson, ...). vibe.data.json does a good job with api design specially construction of new json objects from AA and D types to json types.
Re: Json in D: clean, simple API
On Thursday, 11 May 2017 at 19:33:09 UTC, aberba wrote: Why does json seem hard in D What are you actually looking for?
Re: Json in D: clean, simple API
On Thursday, 11 May 2017 at 19:33:09 UTC, aberba wrote: Json libs in D seem not straight foward. I've seen several wrappers and (De)serializers trying to abstract std.json. std_data_json proposed to replace std.json doesnt *seem* to tackle straigh-forward json process like I find vibe.data.json. Handy stuff I'm not finding but much simple in vibe.data.json include piecewise construction (constructing json objects like associative arrays) and vibe.data.json's value.get!T. API feel also *feels* not straight-forward. Are all the capabilities of std_data_json what I see in its docs? Why does json seem hard in D and why is std.json still there? Try https://github.com/tamediadigital/asdf ?
Re: json parsing performance
On 04/06/2015 11:09 PM, Brad Anderson wrote: > > We actually have a JSON parser meant to replace std.json that should be > very high performance. You can try it out now using dub: > > http://code.dlang.org/packages/std_data_json It also includes a stream parser for the highest performance requirements. http://s-ludwig.github.io/std_data_json/stdx/data/json/parser/parse_json_stream.html
Re: json parsing performance
On Tuesday, 7 April 2015 at 00:36:30 UTC, weaselcat wrote: On Monday, 6 April 2015 at 21:09:32 UTC, Brad Anderson wrote: On Monday, 6 April 2015 at 20:20:06 UTC, Kingsley wrote: I have read that std.json is pretty slow compared to other languages json parsers and I'm about to do a whole stack of json parsing and was wondering if anyone has got any benchmarks to indicate what "slow" means compared to other languages - particularly java, ruby, python? I want to know whether to roll up the sleeves and write my own json parser focused on performance or if slow just means a few ms slower - which I could live with. We actually have a JSON parser meant to replace std.json that should be very high performance. You can try it out now using dub: http://code.dlang.org/packages/std_data_json I used it recently though I didn't do any performance testing. The improvements to Algebraic would help make it more pleasant to use. Which improvements to algebraic? Sönke describes them here: http://forum.dlang.org/post/lt5s76$is$1...@digitalmars.com
Re: json parsing performance
On Monday, 6 April 2015 at 21:09:32 UTC, Brad Anderson wrote: On Monday, 6 April 2015 at 20:20:06 UTC, Kingsley wrote: I have read that std.json is pretty slow compared to other languages json parsers and I'm about to do a whole stack of json parsing and was wondering if anyone has got any benchmarks to indicate what "slow" means compared to other languages - particularly java, ruby, python? I want to know whether to roll up the sleeves and write my own json parser focused on performance or if slow just means a few ms slower - which I could live with. We actually have a JSON parser meant to replace std.json that should be very high performance. You can try it out now using dub: http://code.dlang.org/packages/std_data_json I used it recently though I didn't do any performance testing. The improvements to Algebraic would help make it more pleasant to use. Which improvements to algebraic?
Re: json parsing performance
On 4/6/15 2:09 PM, Brad Anderson wrote: On Monday, 6 April 2015 at 20:20:06 UTC, Kingsley wrote: I have read that std.json is pretty slow compared to other languages json parsers and I'm about to do a whole stack of json parsing and was wondering if anyone has got any benchmarks to indicate what "slow" means compared to other languages - particularly java, ruby, python? I want to know whether to roll up the sleeves and write my own json parser focused on performance or if slow just means a few ms slower - which I could live with. We actually have a JSON parser meant to replace std.json that should be very high performance. You can try it out now using dub: http://code.dlang.org/packages/std_data_json I used it recently though I didn't do any performance testing. The improvements to Algebraic would help make it more pleasant to use. Sönke, what's the status of this? -- Andrei
Re: json parsing performance
On Monday, 6 April 2015 at 20:20:06 UTC, Kingsley wrote: I have read that std.json is pretty slow compared to other languages json parsers and I'm about to do a whole stack of json parsing and was wondering if anyone has got any benchmarks to indicate what "slow" means compared to other languages - particularly java, ruby, python? I want to know whether to roll up the sleeves and write my own json parser focused on performance or if slow just means a few ms slower - which I could live with. We actually have a JSON parser meant to replace std.json that should be very high performance. You can try it out now using dub: http://code.dlang.org/packages/std_data_json I used it recently though I didn't do any performance testing. The improvements to Algebraic would help make it more pleasant to use.
Re: json parsing performance
On Monday, 6 April 2015 at 20:20:06 UTC, Kingsley wrote: I have read that std.json is pretty slow compared to other languages json parsers and I'm about to do a whole stack of json parsing and was wondering if anyone has got any benchmarks to indicate what "slow" means compared to other languages - particularly java, ruby, python? I want to know whether to roll up the sleeves and write my own json parser focused on performance or if slow just means a few ms slower - which I could live with. Have you looked at vibe.d? You don't need to pull in the whole thing. Docs are a bit obscure, so easiest thing is to read the unit tests. Laeeth
Re: json parsing performance
On Monday, 6 April 2015 at 20:26:15 UTC, cym13 wrote: On Monday, 6 April 2015 at 20:20:06 UTC, Kingsley wrote: I have read that std.json is pretty slow compared to other languages json parsers and I'm about to do a whole stack of json parsing and was wondering if anyone has got any benchmarks to indicate what "slow" means compared to other languages - particularly java, ruby, python? I want to know whether to roll up the sleeves and write my own json parser focused on performance or if slow just means a few ms slower - which I could live with. I don't know much about json parsers so I can't say if it is a good one but it was subject to many discussions lately: https://github.com/kostya/benchmarks/tree/master/json great thanks. Hmm when I ran the test json I got a 212MB json file which the tests used. So although the std.json takes around 10 seconds to parse this - I can probably live with that and spend my energy getting on with my project. Of course it would have been nice to see the performance of std.json closer to that of rust and go instead of closer to ruby.
Re: json parsing performance
On Monday, 6 April 2015 at 20:20:06 UTC, Kingsley wrote: I have read that std.json is pretty slow compared to other languages json parsers and I'm about to do a whole stack of json parsing and was wondering if anyone has got any benchmarks to indicate what "slow" means compared to other languages - particularly java, ruby, python? I want to know whether to roll up the sleeves and write my own json parser focused on performance or if slow just means a few ms slower - which I could live with. I don't know much about json parsers so I can't say if it is a good one but it was subject to many discussions lately: https://github.com/kostya/benchmarks/tree/master/json
Re: json generation from ddoc: painfully close
On Thu, Jan 08, 2015 at 12:32:10AM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
> I just experimented with a battery of macros (json.ddoc) for generating json
> via ddoc. Results for std.algorithm are in
> http://paste.ofcode.org/DFnxChvmRGJiXYpYYk2XWr.
>
> There are a couple of things that make the generated json invalid:
>
> 1. I couldn't get escaping to work. My ESCAPES is:
>
> ESCAPES=/\/\\/ /"/\"/ /&/&/ //>/
>
> So single backslashes will be doubled and quotes will be backslashed.
> Nice. The trouble is, escaping only does its job sometimes but not
> always. I haven't yet figured the circumstances.
About time somebody acknowledged that Ddoc's escaping mechanism leaves
much to be desired!
> 2. This was mentioned before - paragraph, whitespace and especially
> newline handling are handled rather poorly in ddoc. The generated json
> is full of newlines in the middle of strings, which are invalid in
> json (\n must be used). I think every paragraph should be enclosed in
> a $(DDOC_PARAGRAPH) macros that has single newlines replaced with
> spaces. Alternatively, a built-in macro could escape strings
> appropriately.
Yep, also known for a long time and only now ackowledged:
https://issues.dlang.org/show_bug.cgi?id=9731
> 3. Some descriptions feature multiple examples, leading to duplicate
> "DDOC_EXAMPLES" keys. Json strongly discourages (at least) duplicate
> keys in objects. There is no way to have some autoincrement thing that
> generates "DDOC_EXAMPLES_1", "DDOC_EXAMPLES_2" etc. It could be argued
> that that's an issue with the source, not the generator.
[...]
I disagree there's any issue with the source. The current system allows
the very nice idiom of:
/// ... some docs here
auto myFunc(...) { ... }
/// This example shows feature X of myFunc.
unittest { ... }
/// This example shows feature Y of myFunc.
unittest { ... }
The generated docs read like this:
auto myFunc(...);
... some docs here
This example shows feature X of myFunc.
... [first example here]
This example shows feature Y of myFunc.
... [second example here]
This is much more meaningful than a single gigantic example block that
the reader has to parse in his head in order to get through everything
being showcased.
Of course, the mechanics of it can be improved -- ddoc should know
better than to use the same heading "Examples:" over and over. Perhaps,
in terms of the underlying macros, it should have some kind of
autoincrementing label for each ddoc'd unittest block.
T
--
Stop staring at me like that! It's offens... no, you'll hurt your eyes!
Re: json generation from ddoc: painfully close
On 1/8/2015 12:32 AM, Andrei Alexandrescu wrote: I haven't yet figured the circumstances. We can't just let anybody know those things.
Re: json generation from ddoc: painfully close
On 8/01/2015 9:32 p.m., Andrei Alexandrescu wrote: I just experimented with a battery of macros (json.ddoc) for generating json via ddoc. Results for std.algorithm are in http://paste.ofcode.org/DFnxChvmRGJiXYpYYk2XWr. There are a couple of things that make the generated json invalid: 1. I couldn't get escaping to work. My ESCAPES is: ESCAPES=/\/\\/ /"/\"/ /&/&/ //>/ So single backslashes will be doubled and quotes will be backslashed. Nice. The trouble is, escaping only does its job sometimes but not always. I haven't yet figured the circumstances. 2. This was mentioned before - paragraph, whitespace and especially newline handling are handled rather poorly in ddoc. The generated json is full of newlines in the middle of strings, which are invalid in json (\n must be used). I think every paragraph should be enclosed in a $(DDOC_PARAGRAPH) macros that has single newlines replaced with spaces. Alternatively, a built-in macro could escape strings appropriately. 3. Some descriptions feature multiple examples, leading to duplicate "DDOC_EXAMPLES" keys. Json strongly discourages (at least) duplicate keys in objects. There is no way to have some autoincrement thing that generates "DDOC_EXAMPLES_1", "DDOC_EXAMPLES_2" etc. It could be argued that that's an issue with the source, not the generator. That said, this is pretty much it. No other major impediments seem to stop the show. Thoughts and ideas on how to get this to work? Andrei Well we could do the evil method of enabling calling of code from a macro. There should be enough information to do that? We have CTFE, might as well use it.
Re: json and ddoc
On Wednesday, 1 August 2012 at 17:40:13 UTC, Philippe Sigaud wrote: No no no, I wasn't talking about your app! dpldocs is cool! Thanks! I think the new version will be even better. Preview: http://dpldocs.info/search/search-2?searchTerm=post http://dpldocs.info/search/search-2?searchTerm=get I'm now extending the search to be able to look at the type names from the json and do more inter-linking. It also shows the brief description, if present, and will filter out private members for you. And, of course, it will be able to look at submitted libraries too. The little breadcrumbs I intend to make into nice indexes, giving some nice sorting that most ddoc sites don't currently do. Still a ways to go, but I think it will end up really nice. I was talking about the json generator in DMD, which, to my eyes, does not give enough information yet to be truly useful. Yea, but it's still better than nothing at least.
Re: json and ddoc
On Wednesday, 1 August 2012 at 17:52:02 UTC, Brad Anderson wrote: There is already a pull request to add (at least some) ddoc to json: http://forum.dlang.org/post/ycfyhcsbciguzaxwu...@forum.dlang.org Well, we already have some... but that request looks like it does a lot of good stuff.
Re: json and ddoc
On Wed, Aug 1, 2012 at 4:46 PM, Adam D. Ruppe wrote: > On Wednesday, 1 August 2012 at 14:36:26 UTC, Philippe Sigaud wrote: >> >> Well, the comments are discarded as soon as lexical analysis is done, I >> guess. > > > They are actually there if you do both -X and -D together. > (-X alone doesn't show it; it must be discarded then, but > -D keeps it). Ah, dammit. I was at work far from a D compiler. I never used -X *and* -D at the same time. > > The problem is though that it is the text from the comment > without any organization or macro expansion. OK. >> This generator does not give much information btw, but >> my impression is that people do not use it that much and, >> consequently, no feature request is emitted. > > > Yeah. It isn't bad though; more detailed than dpldocs.info > version 1.0 which did nothing more than grep ' the generated html! No no no, I wasn't talking about your app! dpldocs is cool! I was talking about the json generator in DMD, which, to my eyes, does not give enough information yet to be truly useful.
Re: json and ddoc
On 8/1/2012 8:20 AM, Adam D. Ruppe wrote: > On Wednesday, 1 August 2012 at 15:09:45 UTC, Sönke Ludwig wrote: >> It doesn't really have dependencies to vibe.d so ripping it out should also >> be easy. > > Thanks! It looks like that will do the job. I'd almost pay money for the ddoc support that's inside dmd to be pulled into a separate process that just uses the json output. I suspect it wouldn't be that hard to separate them, just never have had the time to try it.
Re: json and ddoc
On Wednesday, 1 August 2012 at 15:09:45 UTC, Sönke Ludwig wrote: It doesn't really have dependencies to vibe.d so ripping it out should also be easy. Thanks! It looks like that will do the job.
Re: json and ddoc
Am 01.08.2012 16:07, schrieb Adam D. Ruppe:
I'm (finally) updating my dpldocs.info website again, and
before I just pulled names from the generated Phobos html.
This time, I want to use dmd's json output to avoid dependency
on the specific html layout of std.ddoc.
Anyway I hit dmd -c -X -D *.d in the phobos dir. Boom, I got
one big .json file with all the info.
But, the comments aren't parsed at all.
So, my question is: do we have a ddoc parser that stands alone?
BTW: this is the complete listing from json so far:
http://dpldocs.info/search/awesome
I'm actually impressed with the speed, considering it is re-parsing
3 MB of generated json per load. std.variant and std.json might not
be speed demons, but they are plenty good enough for me.
The ultimate goal here is to revitalize my D search engine and to
make it as a nice index for all functions, with brief descriptions,
etc., hopefully for all D libs everywhere.
With the html, dealing with different people's macros to parse it
is a pain. But with the json, dmd always does it the same way, so
with some luck, I can just add a box "upload your project's json
file" and allow easy instant submissions for other libs.
I have a simple DDOC parser in vibe.d (*). No guarantees that the output
is always acting the same as DMD (e.g. there is no support for special
sections yet), but it was good enough for me so far.
Something like this should work:
import vibe.vibe;
void main(string[] args)
{
auto fin = openFile(args[1], FileMode.Read);
auto ddoc = cast(string)fin.readAll();
auto html = appender!string();
filterDdocComment(html, ddoc);
auto fout = openFile(args[2], FileMode.CreateTrunc);
fout.write(formatDdocComment(html.data));
}
It doesn't really have dependencies to vibe.d so ripping it out should
also be easy.
(*) http://vibed.org/api/vibe.textfilter.ddoc#filterDdocComment
...that module is not really documented atm
Re: json and ddoc
On Wednesday, 1 August 2012 at 14:36:26 UTC, Philippe Sigaud
wrote:
Well, the comments are discarded as soon as lexical analysis is
done, I guess.
They are actually there if you do both -X and -D together.
(-X alone doesn't show it; it must be discarded then, but
-D keeps it).
The problem is though that it is the text from the comment
without any organization or macro expansion.
For example:
{
"name" : "map(fun...) if (fun.length >= 1)",
"kind" : "template",
"protection" : "public",
"comment" : "\nImplements the homonym function (also known as $(D
transform)) present\nin many languages offunctional flavor.
The call $(D map!(fun)(range))\nreturns a range of which elements
are obtained by applying $(D fun(x))\nleft to right for all $(D
x) in $(D range). The original ranges are\nnot changed.
Evaluation is done lazily. The range returned by $(D
map)\ncaches the last value such that evaluating $(D front)
multipletimes\ndoes not result in multiple calls to $(D
fun).\n\nExample:\n\nint[] arr1 = [ 1, 2, 3, 4 ];\nint[]
arr2 = [ 5, 6 ];\nauto squares = map!(\"a * a\")(chain(arr1,
arr2));\nassert(equal(squares, [ 1, 4, 9, 16, 25, 36
]));\n\n\nMultiple functions can be passed to $(D map). In
that case, the\nelement type of $(D map) is a tuple containing
one element for each\nfunction.\n\nExample:\n\n\nauto arr1 =
[ 1, 2, 3, 4 ];\nforeach (e; map!(\"a + a\", \"a *
a\")(arr1))\n{\nwriteln(e[0], \" \", e[1]);\n}\n\n\nYou
may alias $(D map) with some function(s) to a symbol and
use\nit separately:\n\n\nalias map!(to!string) stringize;
\nassert(equal(stringize([ 1, 2, 3, 4 ]), [ \"1\", \"2\",
\"3\", \"4\" ]));\n\n",
"line" : 367,
I'd like to get the sections broken out and as many macros
expanded
as possible, so the summary text in search results can look
pretty.
One option is doing my own parsing, but Walter said the recursive
expansion in the macros was actually very tricky to get right.. so
I'd prefer to skip doing that again myself if I can.
This generator does not give much information btw, but
my impression is that people do not use it that much and,
consequently, no feature request is emitted.
Yeah. It isn't bad though; more detailed than dpldocs.info
version 1.0 which did nothing more than grep '
Re: json and ddoc
On Wed, Aug 1, 2012 at 4:07 PM, Adam D. Ruppe wrote: > I'm (finally) updating my dpldocs.info website again, and Yes! > Anyway I hit dmd -c -X -D *.d in the phobos dir. Boom, I got > one big .json file with all the info. > > But, the comments aren't parsed at all. Well, the comments are discarded as soon as lexical analysis is done, I guess. I suppose the DMD part that does the json output never ever sees any comment, just code tokens (see the discussion on lexing D)? I wonder how documentation generation is done with -D? Since with the -D flag, DMD correctly 'attach' doc comments on code part, (this is a modul-level doc, this is a field documentation, ...) I guess the problem is to somehow transport this information to the json generator. This generator does not give much information btw, but my impression is that people do not use it that much and, consequently, no feature request is emitted.
Re: JSON
On 12/15/10 2:05 PM, Robert Jacques wrote: On Wed, 15 Dec 2010 13:42:39 -0500, Andrei Alexandrescu wrote: On 12/15/10 11:49 AM, Robert Jacques wrote: [Algebraic] Are all bugfixes that your work depends on rolled into the upcoming dmd release? Andrei I don't think so, each bug seems to still be open and I haven't seen any posts to the phobos list mentioning them. The bug reports do all contain patches though. Issue 5155: http://d.puremagic.com/issues/show_bug.cgi?id=5155 Issue 5233: http://d.puremagic.com/issues/show_bug.cgi?id=5233 Issue 5236: http://d.puremagic.com/issues/show_bug.cgi?id=5236 Issue 5232: http://d.puremagic.com/issues/show_bug.cgi?id=5232 This month's release is already in beta, so this probably won't make it now. Would be great to boost the priority bugs for the next release then. Andrei
Re: JSON (was: emscripten )
Robert Jacques wrote: > I also used allMembers in my first iteration, but it gives what > I'd consider false positives, so you have to filter the results. Aye. What I did that was good enough for me was to skip any names that started with a _ (which hits _ctor and also a naming convention for "private" variables) and also added a check for a member function toJsonValue. If that member function is available, it is called instead of proceeding inside, letting the struct or class specialize its own output, thus getting around the naming problems. I never used it in practice though, since I just learned to avoid names that cause problems. Not a perfect solution but it worked for me.
Re: JSON
On Wed, 15 Dec 2010 13:42:39 -0500, Andrei Alexandrescu wrote: On 12/15/10 11:49 AM, Robert Jacques wrote: [Algebraic] Are all bugfixes that your work depends on rolled into the upcoming dmd release? Andrei I don't think so, each bug seems to still be open and I haven't seen any posts to the phobos list mentioning them. The bug reports do all contain patches though. Issue 5155: http://d.puremagic.com/issues/show_bug.cgi?id=5155 Issue 5233: http://d.puremagic.com/issues/show_bug.cgi?id=5233 Issue 5236: http://d.puremagic.com/issues/show_bug.cgi?id=5236 Issue 5232: http://d.puremagic.com/issues/show_bug.cgi?id=5232
Re: JSON (was: emscripten )
On Wed, 15 Dec 2010 13:31:37 -0500, Adam D. Ruppe wrote: Robert Jacques wrote: *snip code* I'm just quickly looking it over, with some brief comments. Your code looks good. You covered everything, and your use of tupleof seems to do a better job than my own use of allMembers! Very cool. I guess I'm actually very brief, but generally it looks nice. I'll try using it in a project sometime (hopefully soon) and may have some meaty comments then, but from the source, I think I'll like it. Thanks. I also used allMembers in my first iteration, but it gives what I'd consider false positives, so you have to filter the results.
Re: JSON
On 12/15/10 11:49 AM, Robert Jacques wrote: [Algebraic] Are all bugfixes that your work depends on rolled into the upcoming dmd release? Andrei
Re: JSON (was: emscripten )
Vladimir Panteleev wrote: > Umm, I just wrote my own, it's way simpler than what you described. Ah indeed, that is simple! Very nice.
Re: JSON (was: emscripten )
Robert Jacques wrote: > *snip code* I'm just quickly looking it over, with some brief comments. Your code looks good. You covered everything, and your use of tupleof seems to do a better job than my own use of allMembers! Very cool. I guess I'm actually very brief, but generally it looks nice. I'll try using it in a project sometime (hopefully soon) and may have some meaty comments then, but from the source, I think I'll like it.
Re: JSON (was: emscripten )
On Wed, 15 Dec 2010 16:38:16 +0200, Adam D. Ruppe wrote: I'm curious what you did in your code. Is it a custom module or did you build off the std.json too? Umm, I just wrote my own, it's way simpler than what you described. Also it's in D1. See attached :P -- Best regards, Vladimirmailto:vladi...@thecybershadow.net Json.d Description: Binary data
Re: JSON
On 12/15/10 11:49 AM, Robert Jacques wrote:
[JSON]
Apologies for not making the time to review this; I'm very interested in
the topic but I have 121 emails waiting for attention in my inbox, and
each requires a fair amount of work.
Notes:
* Does anyone have a suggestion of a good way to attach methods to an
Algebraic type? And if we can, should we?
This is a very good challenge. Ideally Algebraic would define a method
if and only if all of its possible types define a method with (a) same
name, (b) covariant return types (i.e. return types have a CommonType),
(c) contravariant parameter types (we don't have ContravariantCommonType
in std.traits, but it should be doable). Consider:
class Widget {
long foo(int);
}
class Gadget {
int foo(long);
}
auto a = Algebraic!(Widget, Gadget)(new Widget);
long x = a.foo(42); // should work
x = a.foo(x); // shouldn't compile
That would be awes, and is in fact implementing an optimization called
type casing.
Andrei
Re: JSON (was: emscripten )
On Wed, 15 Dec 2010 09:38:16 -0500, Adam D. Ruppe
wrote:
Vladimir Panteleev Wrote:
if (resource == "/getfoo")
{
struct FooResult { int n; string s; }
return toJSON(FooResult(42, "bar")); // {"n":42,"s":"bar"}
}
What kind of code did you use there? My app does something
similar using wrappers of std.json.
JSONValue toJsonValue(T)(T a) {
JSONValue val;
static if(is(T == JSONValue)) {
val = a;
} else static if(__traits(compiles, a.makeJsonValue())) {
val = a.makeJsonValue();
} else static if(isIntegral!(T)) {
val.type = JSON_TYPE.INTEGER;
val.integer = to!long(a);
[..]
And it goes right through a variety of types, including
structs where it does __traits(allMembers), and ultimately
settles for to!string if nothing else fits.
My program also reads json, but I had some trouble with std.json,
so I had to fork it there. It has a helper function jsonValueToVariant
(which just
became fully usable in dmd 2.050,
shortening my code a lot, thanks phobos/dmd devs!) which
pulls it into a std.variant for easy using later.
The trouble I had was std.json.parseJSON claims to be able
to handle arbitrary input ranges, but when I actually instantiated
it on plain old string, it refused to compile.
I made it work by switching it to just normal strings in my private
fork.
What's really cool about these templates is it enables automatic calling
of
functions from the outside. You write a function like:
struct User { ... }
User getUserInfo(int id) { }
And then this is accessible, through template magic, as:
/app/get-user-info?id=1
Returns a full HTML document with the info
/app/get-user-info?id=1&format=json
Returns the User struct converted to json
/app/get-user-info?id=1&format=xml
The struct as a kind of xml (I didn't spend much time on this so it
still sucks)
And more. Way cool.
Anyway, I thought about committing some of my json changes back to
std.json, but
removing the range capability goes against the grain there, and adding
the
templates seems pointless since everyone says std.json is going to be
trashed
anyway. I thought I might have actually been the only one using it!
I'm curious what you did in your code. Is it a custom module or did you
build off
the std.json too?
Hi Adam,
I've been working on a replacement for std.json. I posted a preview to the
phobos list, but I haven't gotten any feedback yet, as its not very high
priority.
Here is my original post:
I have been working on a re-write of std.json. The purpose was to fix
implementation bugs, better conform to the spec, provide a lightweight
tokenizer (Sean) and to use an Algebraic type (Andrei) for JSON values. In
the progress of doing this, I made my parser 2x faster and updated/fixed a
bunch of issues with VariantN in order to fully support Algebraic types.
Both of these libraries are at a solid beta level, so I'd like to get some
feedback, and provide a patch for those being held back by the problems
with Algebraic. The code and docs are available at:
https://jshare.johnshopkins.edu/rjacque2/public_html/. These files were
written against DMD 2.050 and both depend on some patches currently in
bugzilla (see the top of each file or below)
Summary of Variant changes:
* Depends on Issue 5155's patch
* VariantN now properly supports types defined using "This".
* Additional template constraints and acceptance of implicit converters in
opAssign and ctor. i.e. if an Algebraic type supports reals, you can now
assign an int to it.
* Updated to using opBinary/opBinaryRight/opOpAssign. This adds right
support to several functions and is now generated via compile time
reflection + mixins: i.e. Algebraic types of user defined types should
work, etc.
* Added opIn support, though it currently on works for AAs.
* Added opIndexOpAssign support.
* Added opDispatch as an alternative indexing method. This allows Variants
of type Variant[string] to behave like prototype structs: i.e. var.x = 5;
instead of var["x"] = 5;
Notes:
* There's an bugzilla issue requesting opCall support in Variant. While I
can see the usefulness, syntactically this clashes with the ctor. Should
this issue be closed or should a method be used as an opCall surrogate?
* Could someone explain to me the meaning/intension of "Future additions
to Algebraic will allow compile-time checking that all possible types are
handled by user code, eliminating a large class of errors." Is this
something akin to final switch support?
Summary of JSON changes:
* Depends on the Variant improvements.
* Depends on Issue 5233's patch
* Depends on Issue 5236's patch
* Issue 5232's patch is also recommended
* The integer type was removed: JSON doesn't differentiate between
floating and integral numbers. Internally, reals are used and on systems
with 80-bit support, this encompasses all integral types.
* UTF escape cha
Re: JSON improvement request
"cemiller" wrote in message news:op.vcj3n9pcycw...@mapddrule1.ffe.foxeg.com... >I would like attributes to be included in the JSON output, for example: > "attributes" : [ "static", "protected" ] > > This allows for more accurate autocomplete support: > TypeName. > super. > > Thanks, > Christopher E. Miller Enhancement requests go here: http://d.puremagic.com/issues/
Re: json output and Visual D
Rainer Schuetze wrote: More ideas welcome! The speller that comes with the dmd source should be useful.
Re: json output and Visual D
Currently, it allows jumping to the definition of the identifier at the cursor position. (it just jumps to the first definition found without allowing disambiguation by the user - but this is rather high on my todo list). It also does not look at the scope to filter the possible candidates yet. Another thing, that is even more useful when using it on the runtime library, is the "method-tooltip" (usually shown after the opening parenthesis), that allows you to scroll through available methods showing the prototype and highlighting the current argument. Also high on my todo list. Other things that can be implemented with the json output: - word-completion (not so easy without local variable type info, but I'd say it needs to be rather sloppy anyway) - find symbol definition by text pattern More ideas welcome! Walter Bright wrote: This is for Rainer Schuetze: Can you describe what dmd's json output does for Visual D? I'm very curious.
Re: JSON in D
On 2009-05-17 16:58:26 +0200, Christopher Wright said: Fawzi Mohamed wrote: As we are about JSON blip has also one. It does not aim at replacing tango's one, which is really fast, and is the way to go if you want to read JSON to an in memory representation of it. On the other hand if you want to use JSON for serialization, i.e. to read into your objects, or to write out them, then what is in blip could be interesting as it is a serialization frameworkd that support json (and also a binary protocol), and could be exteded to support other protocols like xml. Fawzi Do you have a link? http://dsource.org/projects/blip
Re: JSON in D
Fawzi Mohamed Wrote: > > As we are about JSON blip has also one. > It does not aim at replacing tango's one, which is really fast, and is > the way to go if you want to read JSON to an in memory representation > of it. > > On the other hand if you want to use JSON for serialization, i.e. to > read into your objects, or to write out them, then what is in blip > could be interesting as it is a serialization frameworkd that support > json (and also a binary protocol), and could be exteded to support > other protocols like xml. > > Fawzi > Fawzi, What I've done is actually going pretty well, I can parse all the examples from www.json.org (albeit with changes that I don't want to make - they have an example (the most complicated one) with variable names that would not compile in Javascript). My test program parses them, converts them to XML, then converts them back back to JSON, and compares the outputs. D/Phobos really does make this stuff easy - I love it! Steve
Re: JSON in D
Fawzi Mohamed wrote: As we are about JSON blip has also one. It does not aim at replacing tango's one, which is really fast, and is the way to go if you want to read JSON to an in memory representation of it. On the other hand if you want to use JSON for serialization, i.e. to read into your objects, or to write out them, then what is in blip could be interesting as it is a serialization frameworkd that support json (and also a binary protocol), and could be exteded to support other protocols like xml. Fawzi Do you have a link?
Re: JSON in D
On 2009-05-16 19:30:03 +0200, Steve Teale said: Moritz Warning Wrote: On Fri, 15 May 2009 18:27:05 -0400, Christopher Wright wrote: Sean Kelly wrote: == Quote from Steve Teale (steve.te...@britseyeview.com)'s article I'm trying to write a JSON parser/generator. If anyone else is doing the same, can we collaborate? I've got one, but I wrote it for work so I'm not sure if I can release it. I'd be happy to offer suggestions though :-/ Dude, tango.text.json? I also wrote one: http://web-gmui.svn.sourceforge.net/viewvc/web-gmui/trunk/utils/json/ it's fast, has many features and is BSD licensed. Thanks, I'll check it out, bur mine is also close to working now. Steve As we are about JSON blip has also one. It does not aim at replacing tango's one, which is really fast, and is the way to go if you want to read JSON to an in memory representation of it. On the other hand if you want to use JSON for serialization, i.e. to read into your objects, or to write out them, then what is in blip could be interesting as it is a serialization frameworkd that support json (and also a binary protocol), and could be exteded to support other protocols like xml. Fawzi
Re: JSON in D
Moritz Warning Wrote: > On Fri, 15 May 2009 18:27:05 -0400, Christopher Wright wrote: > > > Sean Kelly wrote: > >> == Quote from Steve Teale (steve.te...@britseyeview.com)'s article > >>> I'm trying to write a JSON parser/generator. If anyone else is doing > >>> the same, can we collaborate? > >> > >> I've got one, but I wrote it for work so I'm not sure if I can release > >> it. I'd be happy to offer suggestions though :-/ > > > > Dude, tango.text.json? > > I also wrote one: > > http://web-gmui.svn.sourceforge.net/viewvc/web-gmui/trunk/utils/json/ > > it's fast, has many features and is BSD licensed. Thanks, I'll check it out, bur mine is also close to working now. Steve
Re: JSON in D
On Fri, 15 May 2009 18:27:05 -0400, Christopher Wright wrote: > Sean Kelly wrote: >> == Quote from Steve Teale (steve.te...@britseyeview.com)'s article >>> I'm trying to write a JSON parser/generator. If anyone else is doing >>> the same, can we collaborate? >> >> I've got one, but I wrote it for work so I'm not sure if I can release >> it. I'd be happy to offer suggestions though :-/ > > Dude, tango.text.json? I also wrote one: http://web-gmui.svn.sourceforge.net/viewvc/web-gmui/trunk/utils/json/ it's fast, has many features and is BSD licensed.
Re: JSON in D
== Quote from Christopher Wright (dhase...@gmail.com)'s article > Sean Kelly wrote: > > == Quote from Steve Teale (steve.te...@britseyeview.com)'s article > >> I'm trying to write a JSON parser/generator. If anyone else is doing the > >> same, can we collaborate? > > > > I've got one, but I wrote it for work so I'm not sure if I can release > > it. I'd be happy to offer suggestions though :-/ > Dude, tango.text.json? That's a decent option if you aren't inclined to write one.
Re: JSON in D
Sean Kelly wrote: == Quote from Steve Teale (steve.te...@britseyeview.com)'s article I'm trying to write a JSON parser/generator. If anyone else is doing the same, can we collaborate? I've got one, but I wrote it for work so I'm not sure if I can release it. I'd be happy to offer suggestions though :-/ Dude, tango.text.json?
Re: JSON in D
== Quote from Steve Teale (steve.te...@britseyeview.com)'s article > I'm trying to write a JSON parser/generator. If anyone else is doing the > same, can we collaborate? I've got one, but I wrote it for work so I'm not sure if I can release it. I'd be happy to offer suggestions though :-/
