Re: D 2.066 is out. Enjoy!
Jonathan M Davis wrote in message news:fxdqpmfcbskvtcafz...@forum.dlang.org... LOL. Yeah, well, it would be ni going to support C+ce if we could get an actual list of the C++ features that D currently supports somewhere (and how to use them if it's not obvious). You've been doing so much great work on that that I have no clue what the current state of things is. For instance, this is the first I've heard of anything about template support; I'd thought that we were never going to support templates. Is it just for name mangling or for actually compiling them? Templates are sort-of supported. The main motivation was to allow dmd's ArrayT type to be used in function signatures. This is nice, because it only requires correct name mangling, you don't need to worry about instantiation. Being able to call templated free functions and call methods on templated types will require each referenced template to be explicitly instantiated on the C++ side. I don't think it's realistic for D to do this automatically, although it is possible to do things like generate a non-templated forwarding wrapper function for each instantiation. In DDMD, this is worked around by array.d containing a functionally-equivalent translation of array.h. The D code all ends up calling the D version, and the two must be kept exactly in sync. This approach is probably feasible for accessing stl types and other common, rarely changing C++ templates. There are two reason it's not better documented: 1. I hate writing documentation. I really really hate it. 2. These features are rather difficult to use, and I don't want people to think they can just plug-and-play. I've spent a lot of time fighting compiler alignment bugs, which are their own special kind of hell. Many of those issues have been resolved now, but only in the areas that ddmd actually exercises.
Re: D 2.066 is out. Enjoy!
Walter Bright wrote in message news:lt5l3k$2s5t$1...@digitalmars.com... The thing is, while the code was there, there wasn't a single test case for it in the test suite. Furthermore, at least for Elf, there was no support for the special mangling done for ::std:: stuff. Yeah, I don't know what happened to the test cases for template mangling. They were certainly tested when the new manger was being introduced, but somehow disappeared. There was no special std mangling because at the time C++ mangling was updated, there were no C++ namespaces in D. The thing is, modern C++ practice makes heavy use of std types. Having an interface to C++ code is fairly unusable unless D can also interface to std::string, std::vector, and a few others. The first step is to support the mangling of them. Then, try to construct a workalike on the D side that follows D rules, and yet is able to seamlessly interact with the corresponding C++ code. We'll see how far we can get with that, and then evaluate what to do next. It works for ddmd's array.d/array.h at least, although it's not very maintenance friendly. I assume you're aiming for something like a 'core.stdcpp.vector' with an implementation to match each stl implementation?
Re: D 2.066 is out. Enjoy!
On Thursday, 21 August 2014 at 20:49:48 UTC, bachmeier wrote: It would be nice to have a page to link to when questions come up on Reddit about compatibility with C++. We have this: http://dlang.org/cpp_interface.html From what I understand, it's not complete. For example it says that non-virtual and static member functions cannot be accesses, but that's not the case anymore, AFAIR. And the section about templates also says that there's no support. That page should also have information about avoiding the garbage collector and the status of GC removal from the standard library. This information is currently spread over several articles with a different focus each, and not up to date either: http://dlang.org/garbage.html http://wiki.dlang.org/Instantiating_Class_Objects_Elsewhere_Than_the_GC_Heap http://wiki.dlang.org/Memory_Management http://wiki.dlang.org/Versus_the_garbage_collector I don't think we should treat both topics on the same page, they're mostly unrelated (though people coming from C++ might be interested in both, of course).
Re: D 2.066 is out. Enjoy!
On Monday, 18 August 2014 at 19:00:23 UTC, Andrei Alexandrescu wrote: Congratulations to everyone involved! http://www.reddit.com/r/programming/comments/2dwqvy/d_2066_nogc_c_namespaces_multidimensional_slices/ https://www.facebook.com/dlang.org/posts/905593426121006 https://twitter.com/D_Programming/status/501443132115140609 Andrei Main dlang.org page still shows that 2.066 is in beta phase. Merge the https://github.com/D-Programming-Language/dlang.org/pull/638 to fix.
Re: D 2.066 is out. Enjoy!
On Friday, 22 August 2014 at 08:23:16 UTC, Marc Schütz wrote: On Thursday, 21 August 2014 at 20:49:48 UTC, bachmeier wrote: It would be nice to have a page to link to when questions come up on Reddit about compatibility with C++. We have this: http://dlang.org/cpp_interface.html From what I understand, it's not complete. For example it says that non-virtual and static member functions cannot be accesses, but that's not the case anymore, AFAIR. And the section about templates also says that there's no support. That's the problem. We don't want to link to a page that's not accurate when replying to comments on Reddit. That page should also have information about avoiding the garbage collector and the status of GC removal from the standard library. This information is currently spread over several articles with a different focus each, and not up to date either: http://dlang.org/garbage.html http://wiki.dlang.org/Instantiating_Class_Objects_Elsewhere_Than_the_GC_Heap http://wiki.dlang.org/Memory_Management http://wiki.dlang.org/Versus_the_garbage_collector I don't think we should treat both topics on the same page, they're mostly unrelated (though people coming from C++ might be interested in both, of course). Maybe it wouldn't have to go on the same page, but at least links to all the information should appear on the same page. The current system with everything scattered here and there makes for a bad first impression.
Re: D 2.066 is out. Enjoy!
On 8/22/14, 2:06 AM, Dejan Lekic wrote: On Monday, 18 August 2014 at 19:00:23 UTC, Andrei Alexandrescu wrote: Congratulations to everyone involved! http://www.reddit.com/r/programming/comments/2dwqvy/d_2066_nogc_c_namespaces_multidimensional_slices/ https://www.facebook.com/dlang.org/posts/905593426121006 https://twitter.com/D_Programming/status/501443132115140609 Andrei Main dlang.org page still shows that 2.066 is in beta phase. Merge the https://github.com/D-Programming-Language/dlang.org/pull/638 to fix. Pushed, thanks Dejan. -- Andrei
Re: Fix #2529: explicit protection package #3651
On Tuesday, 19 August 2014 at 17:08:25 UTC, Walter Bright wrote: On 8/19/2014 7:01 AM, Dicebot wrote: Walter, now that release is out can you please state your opinion about https://github.com/D-Programming-Language/dmd/pull/3651 ? It is blocking Phobos module split and decoupling. I keep thinking there's gotta be a way to do this without language changes. For what it's worth I don't care how things turn out w.r.t. syntax, language extension or convention but the problem must be solved. The way I see the problem: There must be nice and clean way to have internal stuff that is invisible for user. Preferably this stuff must not be monolithic and have form of package. Example structure: mod/package.d mod/internal/bar.d mod/... I actually face it in Phobos right now, my blocked pull: https://github.com/D-Programming-Language/phobos/pull/2412 Options: 1. Use current package attribute. Disadvantages: a) Must retain internals in the same package, user may still import them no problem at all. At least it does not do much harm as nothing is accessible. b) Can't use std.mod.internal.bar 'package' stuff in std.mod (upper one). That makes it next to unusable. Basically it means we have to push internals up, instead of pushing them down. 2. Use separate public internal package. Main disadvantage: a) Now user may import and actually USE internal stuff. b) Not only that but also internal methods of equally internal structs and classes leak out. In other words: a struct defined in internal module may never be exposed without some kind of wrapping. Ugly and unnecessary complication. I'd rather have a language feature, but whatever you guys invent as 3rd option that doesn't suck will have my vote. --- Dmitry Olshansky
Re: D 2.066 is out. Enjoy!
On 8/22/2014 1:23 AM, Daniel Murphy wrote: Walter Bright wrote in message news:lt5l3k$2s5t$1...@digitalmars.com... The thing is, while the code was there, there wasn't a single test case for it in the test suite. Furthermore, at least for Elf, there was no support for the special mangling done for ::std:: stuff. Yeah, I don't know what happened to the test cases for template mangling. They were certainly tested when the new manger was being introduced, but somehow disappeared. Yeah, that can happen. There was no special std mangling because at the time C++ mangling was updated, there were no C++ namespaces in D. Makes sense. I assume you're aiming for something like a 'core.stdcpp.vector' with an implementation to match each stl implementation? Yes. While it'll be a significant effort to do this, it could be a big win for us.
Re: D 2.066 is out. Enjoy!
On Friday, 22 August 2014 at 14:36:13 UTC, Andrei Alexandrescu wrote: On 8/22/14, 2:06 AM, Dejan Lekic wrote: On Monday, 18 August 2014 at 19:00:23 UTC, Andrei Alexandrescu wrote: Congratulations to everyone involved! http://www.reddit.com/r/programming/comments/2dwqvy/d_2066_nogc_c_namespaces_multidimensional_slices/ https://www.facebook.com/dlang.org/posts/905593426121006 https://twitter.com/D_Programming/status/501443132115140609 Andrei Main dlang.org page still shows that 2.066 is in beta phase. Merge the https://github.com/D-Programming-Language/dlang.org/pull/638 to fix. Pushed, thanks Dejan. -- Andrei As I'm sure has been mentioned elsewhere, the website changes should be part of the release process, not an afterthought.
Re: D 2.066 is out. Enjoy!
On 8/22/2014 1:18 AM, Daniel Murphy wrote: There are two reason it's not better documented: 1. I hate writing documentation. I really really hate it. Join the club :-) 2. These features are rather difficult to use, and I don't want people to think they can just plug-and-play. I've spent a lot of time fighting compiler alignment bugs, which are their own special kind of hell. Many of those issues have been resolved now, but only in the areas that ddmd actually exercises. Sorry you got to be the pioneer with the arrows in your back, but you've paved the way for the rest of us.
Re: D 2.066 is out. Enjoy!
On 8/22/14, 10:04 AM, Walter Bright wrote: On 8/22/2014 1:23 AM, Daniel Murphy wrote: I assume you're aiming for something like a 'core.stdcpp.vector' with an implementation to match each stl implementation? Yes. While it'll be a significant effort to do this, it could be a big win for us. This is top priority for D. Above top if possible. -- Andrei
Re: D 2.066 is out. Enjoy!
On 8/22/14, 10:05 AM, John Colvin wrote: As I'm sure has been mentioned elsewhere, the website changes should be part of the release process, not an afterthought. Agreed. Who would like to volunteer being our webmaster? We'll discuss with our admin to give push rights. -- Andrei
Re: D 2.066 is out. Enjoy!
On Friday, 22 August 2014 at 17:06:31 UTC, Walter Bright wrote: On 8/22/2014 1:18 AM, Daniel Murphy wrote: There are two reason it's not better documented: 1. I hate writing documentation. I really really hate it. Join the club :-) 2. These features are rather difficult to use, and I don't want people to think they can just plug-and-play. I've spent a lot of time fighting compiler alignment bugs, which are their own special kind of hell. Many of those issues have been resolved now, but only in the areas that ddmd actually exercises. Sorry you got to be the pioneer with the arrows in your back, but you've paved the way for the rest of us. LOL! That's a hilarious comment! :)
Re: D 2.066 is out. Enjoy!
On 8/22/2014 11:33 AM, Andrei Alexandrescu via Digitalmars-d-announce wrote: On 8/22/14, 10:05 AM, John Colvin wrote: As I'm sure has been mentioned elsewhere, the website changes should be part of the release process, not an afterthought. Agreed. Who would like to volunteer being our webmaster? We'll discuss with our admin to give push rights. -- Andrei cronjob that does a git pull, and then everyone with pull permissions can keep the website updated.
Re: Classes to build a Windows service.
On Friday, 26 October 2007 at 18:47:43 UTC, Steve Teale wrote: Christoph Singewald Wrote: Hi! Did you put your classes somewhere, I'm interested how you build the service. At the moment I had no luck. tnx christoph Steve Teale Wrote: BCS Wrote: Reply to Steve, I've built a set of classes: EventLogger TinyXML PropertyFile ServiceBase ServiceImplementation BeepService (example) Any suggestions (preferably positive) as to what I should do with them? If you are looking for some place to host them and can't find a better place you can put them in scrapple. http://www.dsource.org/projects/scrapple/ just send me a dsource user name and I'll let you in That seems sensible to start with. What should I actually do? The stuff is at www.britseyeview.com/D/. It may be a little out of date with respect to Walter's current versions, since I have just moved to Tanzania, and it's taken me some time to get an Internet connection that is useful. Steve, I believe an early version of your code made it's way to me and this is what I ended up with after a fix to the Win32 bindings for x64. https://github.com/duovia/WindowsServiceInD I'm using the Windows API library (source actually) on dsource.org. See link on the github page. I found it difficult to find a complete solution to the problem, so I'm going to cross post in a few places to make it easier to find for others seeking an answer to the same question.
Re: Fix #2529: explicit protection package #3651
All I want is that whatever decision Walter makes to happen sooner than in few years from now.
Re: D 2.066 is out. Enjoy!
On Friday, 22 August 2014 at 08:18:18 UTC, Daniel Murphy wrote: 2. These features are rather difficult to use, and I don't want people to think they can just plug-and-play. I've spent a lot of time fighting compiler alignment bugs, which are their own special kind of hell. Many of those issues have been resolved now, but only in the areas that ddmd actually exercises. Do you suggest that C++ interfaces should be written by the compiler team?
Re: Fix #2529: explicit protection package #3651
Dicebot: All I want is that whatever decision Walter makes to happen sooner than in few years from now. There are other pending patches, like the support for the nice [$] syntax by Kenji. I keep thinking there's gotta be a way to do this without language changes. or I keep thinking there must be a better way than [$]. are the kind of standard answers Walter gives when he doesn't have time to think about some design (because he has time he usually needs only hours or very few days to implement features, like when he made UDAs or C++ namespeces). So I guess Walter is currently busy with something (like finishing the 2.066 release and its regressions, or developing Warp for Facebook, or something else), so you have to wait some time for him to come back to the language development side, to receive a good answer and a good solution. Bye, bearophile
Re: D 2.066 is out. Enjoy!
On 8/23/14, 3:33 AM, Andrei Alexandrescu wrote: On 8/22/14, 10:05 AM, John Colvin wrote: As I'm sure has been mentioned elsewhere, the website changes should be part of the release process, not an afterthought. Agreed. Who would like to volunteer being our webmaster? We'll discuss with our admin to give push rights. -- Andrei As I mentioned in an earlier post in this thread, I need access. I did the update for every beta/RC. This one was not an oversight, I intentionally did not update the page. Given the right to push the update, I will, But I'm not going to sit around creating pull requests for one a line delete or one character edit and the wait 24hour+ for it to be published before I can proceed with what I'm doing. Then again, if that's required is a cronjob as Brad has suggested, then I guess the problem is solved.
Re: D 2.066 new behavior
On Friday, 22 August 2014 at 02:26:38 UTC, safety0ff wrote: On Friday, 22 August 2014 at 01:54:55 UTC, Paul D Anderson wrote: Is this expected behavior that has never been enforced before, or is it something new? And is anyone else having the same problem? Paul Looks like a regression, I've filed it here: https://issues.dlang.org/show_bug.cgi?id=13351 Seems to be a duplicate of bug 13294: https://issues.dlang.org/show_bug.cgi?id=13294
Re: Fix #2529: explicit protection package #3651
On Fri, 22 Aug 2014 20:48:22 + bearophile via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: or (smart plan!) just apply the necessary PRs, build dmd from sources and start using the features. if authors of popular libraries will do this, there will be no choice and maintainers will be forced to apply this patches. this is called 'driven by the community'. ;-) ok-ok-ok, you got me, this was a silly joke! or maybe not?.. signature.asc Description: PGP signature
Re: Fix #2529: explicit protection package #3651
On Sat, 23 Aug 2014 04:50:36 +0300 ketmar via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: to be honest, i myself is a happy user of Kenji's $ patch and package(...) patch. yes, it costs some efforts to keep 'em up-to-date, but hey, i have no life anyway. signature.asc Description: PGP signature
Cheap Kitchens
Cheap Kitchens. Thirty Ex Display Kitchens To Clear. http://www.exdisplaykitchens1.co.uk £ 595 Each with appliances. Tel 01616-694785 _ [url=http://www.kitchensuber.co.uk]Cheap Kitchens[/url]
Cheap Kitchens
Cheap Kitchens. Thirty Ex Display Kitchens To Clear. http://www.exdisplaykitchens1.co.uk £ 595 Each with appliances. Tel 01616-694785 _ http://www.kitchensuber.co.uk
Re: RFC: std.json sucessor
Am 22.08.2014 02:42, schrieb Ary Borenszweig:
Say I have a class Person with name (string) and age (int) with a
constructor that receives both. How would I create an instance of a
Person from a json with the json stream?
Suppose the json is this:
{age: 10, name: John}
And the class is this:
class Person {
this(string name, int age) {
// ...
}
}
Without a serialization framework it would in theory work like this:
JSONValue v = parseJSON(`{age: 10, name: John}`);
auto p = new Person(v[name].get!string, v[age].get!int);
unfortunately the operator overloading doesn't work like this currently,
so this is needed:
JSONValue v = parseJSON(`{age: 10, name: John}`);
auto p = new Person(
v.get!(Json[string])[name].get!string,
v.get!(Json[string])[age].get!int);
That should be solved together with the new module (it could of course
also easily be added to JSONValue itself instead of Algebraic, but the
value of having it in Algebraic would be much higher).
Re: RFC: std.json sucessor
Am 22.08.2014 04:35, schrieb Colden Cullen: I notice in the docs there are several references to a `parseJSON` and `parseJson`, but I can't seem to find where either of these are defined. Is this just a typo? Hope this helps: https://github.com/s-ludwig/std_data_json/search?q=parseJsontype=Code Seems like I forgot to replace a few mentions. They are called parseJSONValue and toJSONValue now for clarity.
Re: RFC: std.json sucessor
Am 22.08.2014 00:48, schrieb Brian Schott: On Thursday, 21 August 2014 at 22:35:18 UTC, Sönke Ludwig wrote: Destroy away! ;) source/stdx/data/json/lexer.d(263:8)[warn]: 'JSONToken' has method 'opEquals', but not 'toHash'. source/stdx/data/json/lexer.d(499:65)[warn]: Use parenthesis to clarify this expression. source/stdx/data/json/parser.d(516:8)[warn]: 'JSONParserNode' has method 'opEquals', but not 'toHash'. source/stdx/data/json/value.d(95:10)[warn]: Variable c is never used. source/stdx/data/json/value.d(99:10)[warn]: Variable d is never used. source/stdx/data/json/package.d(942:14)[warn]: Variable val is never used. It's likely that you can ignore these, but I thought I'd post them anyways. (The last three are in unittest blocks, for example.) Fixed all of them (neither was causing harm, but it's still nicer that way). Also added @safe and nothrow where possible. BTW, anyone knows what's holding back formattedWrite() from being @safe for simple types?
Re: Automated source translation of C++ to D
Joakim wrote in message news:ynfwlptfuzfutksbn...@forum.dlang.org... Yes, I'm aware of ddmd. You've mentioned many times that it only works because dmd is written using a very unC++-like style, to the point where github's source analyzer claims that dmd is written in 66.7% C, 28.4% D (presumably the tests right now), 4.4% C++, and 0.5% other. :) The style dmd is written in makes it a lot easier, but it would still be possible with other styles. As others have said the github numbers have nothing to do with the style of the code, only the naming of the files. Given tools like libclang, how hard do you think it'd be to translate most of actual C++ to D? If writing such a tool would mean that C++-D translation is the path of least effort for D users who want to integrate with C++, maybe that's the approach that should be taken instead. A tool that can translate an arbitrary C++ program to D is not going to happen. A tool that can translate a specific C++ program to D is not particularly difficult to produce, as I've done with dmd. eg multiple inheritance cannot be generally mapped to D code. But in many applications, the use of multiple inheritance _can_ be mapped because it corresponds to classes + interfaces. This type of application-specific knowledge can significantly reduce the complexity. DDMD actually has a major additional complication that most translations would not have - it is only a partial translation (glue layer stays in C++) and therefore needs abi stability across the boundary. I initially did a non-abi-stable translation of only the frontend, and it was rather easy in comparison. So no, you can't magically upgrade a project from C++ to D. But it can be done, and is not prohibitively difficult someone experienced with C++ and D.
Re: scope classes mentioned in tutorials, but deprecated
On 21/08/14 20:07, Brad Anderson wrote: On Thursday, 21 August 2014 at 17:55:19 UTC, Timothee Cour via Digitalmars-d wrote: http://dlang.org/cpptod.html#raii mentions scope class and scope variables, which seem deprecated (http://dlang.org/deprecate.html) https://github.com/D-Programming-Language/dlang.org/pull/637 How about we undeprecate it instead. If I recall correctly then DDMD depends on it. -- /Jacob Carlborg
Re: scope classes mentioned in tutorials, but deprecated
Jacob Carlborg: How about we undeprecate it instead. If I recall correctly then DDMD depends on it. I think the idea is to discourage their usage as much as possible in user code, until (someday, perhaps) some memory area tracking system is implemented. Bye, bearophile
Re: Automated source translation of C++ to D
On Friday, 22 August 2014 at 07:48:30 UTC, Daniel Murphy wrote: So no, you can't magically upgrade a project from C++ to D. Hence the name magicport? Sorry, could not resist. David
Re: scope classes mentioned in tutorials, but deprecated
Jacob Carlborg wrote in message news:lt6u0n$18mj$1...@digitalmars.com... How about we undeprecate it instead. If I recall correctly then DDMD depends on it. It's listed as 'future', so it's not actually deprecated. While DDMD does currently use it extensively, it can be replaced if necessary. I'd much rather see it reinstated along with proper escape checking.
Re: Automated source translation of C++ to D
David Nadlinger wrote in message news:jumhdppapovcvfnwn...@forum.dlang.org... On Friday, 22 August 2014 at 07:48:30 UTC, Daniel Murphy wrote: So no, you can't magically upgrade a project from C++ to D. Hence the name magicport? Sorry, could not resist. David It's only the illusion of magic.
Re: Automated source translation of C++ to D
On Fri, 22 Aug 2014 08:29:52 + David Nadlinger via Digitalmars-d digitalmars-d@puremagic.com wrote: Hence the name magicport? magic is not easy, contrary to widespread beliefs. ;-) signature.asc Description: PGP signature
Some template code that worked in 2.065 is not working in 2.066
In my project I have sort of complicated logic to implement data
structure that is somehow similar to std.typecons.Tuple. I can't
reproduce it, because I can't locate the source of bug. My code
is like this but have more nested template calls.
import std.stdio, std.typetuple;
struct MyLib(Args...)
{
alias Symbols = _parseArgs!Args;
template GetNames()
{
alias GetNames = Symbols;
}
}
template _parseArgs(Args...)
{
alias _parseArgs = TypeTuple!Args;
}
void main()
{
auto myLib = MyLib!(a, b, c)();
foreach( item; myLib.GetNames!() ) //Error: expression has no
value
writeln(item);
//foreach( item; typeof(myLib).GetNames!() ) //This is working
// writeln(item);
}
Swapping lines that marked as error with commented lines makes it
working. In this example error happens using 2.065 and 2.066, but
in *my project*, where code is similar to this it compiles in
2.065 but fails in 2.066.
So what should be working in this example by language spec?
1. myLib.GetNames!()
2. typeof(myLib).GetNames!()
3. Both of the above
And it's interesting to see any reasons why this happens.
Re: Shouldn't have IsAlpha() from std.uni has a different name to avoid confusing from std.ascii?
On Thursday, 21 August 2014 at 15:36:41 UTC, ketmar via
Digitalmars-d wrote:
On Thu, 21 Aug 2014 15:27:46 +
MacAsm via Digitalmars-d digitalmars-d@puremagic.com wrote:
Any thoughts? I don't know if I'm missing something but two
functions (and not methods) with same name is very bad.
they doing much the same, but for different character sets. two
different names will just confuse users.
you can use fully qualified names and/or local imports to use
exactly
what you want. something like:
void myFunc (char ch) {
import std.ascii;
if (std.ascii.isAlpha(ch)) ...
}
local imports rocks! ;-)
It's useful advice. But the only problem that I experience from
time to time that local imports become source of linker error
that are not very easy to find. But language descision for this
is good and I like it a lot!
Re: $100 bounty for help with Windows Service code
https://github.com/duovia/WindowsServiceInD/blob/master/src/onedge/mysvc.d#L20 these are not necessarily static: it makes sense to have instance fields of shared types too.
Re: RFC: std.json sucessor
Am 22.08.2014 00:35, schrieb Sönke Ludwig: The DOM style JSONValue type is based on std.variant.Algebraic. This currently has a few usability issues that can be solved by upgrading/fixing Algebraic: - Operator overloading only works sporadically - (...) - Operations and conversions between different Algebraic types is not conveniently supported, which gets important when other similar formats get supported (e.g. BSON) https://github.com/D-Programming-Language/phobos/pull/2452 https://github.com/D-Programming-Language/phobos/pull/2453 Those fix the most important operators, index access and binary arithmetic.
Re: RFC: std.json sucessor
Very nice ! I had started (and dropped) a json module based on Algebraic too. So without opDispatch you plan to use a syntax like jPerson[age] = 10 ? You didn't use stdx.d.lexer. Any reason why ? (I am asking even if I never used this module.(never coded much in D in fact))
Re: RFC: std.json sucessor
Am 22.08.2014 14:17, schrieb matovitch: Very nice ! I had started (and dropped) a json module based on Algebraic too. So without opDispatch you plan to use a syntax like jPerson[age] = 10 ? You didn't use stdx.d.lexer. Any reason why ? (I am asking even if I never used this module.(never coded much in D in fact)) Exactly, that's the syntax you'd use for JSONValue. But my favorite way to work with most JSON data is actually to directly read the JSON string into a D struct using a serialization framework and then access the struct in a strongly typed way. This has both, less syntactic and less runtime overhead, and also greatly reduces the chance for field name/type related bugs. The module is written against current Phobos, which is why stdx.d.lexer wasn't really an option. I'm also unsure if std.lexer would be able to handle the parsing required for JSON numbers and strings. But it would certainly be nice already if at least the token structure could be reused. However, it should also be possible to find a painless migration path later, when std.lexer is actually part of Phobos.
Re: RFC: std.json sucessor
On Friday, 22 August 2014 at 12:39:08 UTC, Sönke Ludwig wrote: Am 22.08.2014 14:17, schrieb matovitch: Very nice ! I had started (and dropped) a json module based on Algebraic too. So without opDispatch you plan to use a syntax like jPerson[age] = 10 ? You didn't use stdx.d.lexer. Any reason why ? (I am asking even if I never used this module.(never coded much in D in fact)) Exactly, that's the syntax you'd use for JSONValue. But my favorite way to work with most JSON data is actually to directly read the JSON string into a D struct using a serialization framework and then access the struct in a strongly typed way. This has both, less syntactic and less runtime overhead, and also greatly reduces the chance for field name/type related bugs. Completely agree, I am waiting for a serializer too. I would love to see something like cap'n proto in D. The module is written against current Phobos, which is why stdx.d.lexer wasn't really an option. I'm also unsure if std.lexer would be able to handle the parsing required for JSON numbers and strings. But it would certainly be nice already if at least the token structure could be reused. However, it should also be possible to find a painless migration path later, when std.lexer is actually part of Phobos. Ok. I think I remember there was a stdx.d.lexer's Json parser provided as sample.
Re: RFC: std.json sucessor
Am 22.08.2014 14:47, schrieb matovitch: Ok. I think I remember there was a stdx.d.lexer's Json parser provided as sample. I see, so you just have to write your own number/string parsing routines: https://github.com/Hackerpilot/lexer-demo/blob/master/jsonlexer.d
Is there any preprocessor scripting language?
I just want to write something like this:
#ololo script
foreach(child; findAllChildrens())
{
child.insert(
static void doABarrelRoll() { }
);
}
#end
Templates/mixins is not enough for me... maybe because of
hands.dll error :)
Re: RFC: std.json sucessor
On Friday, 22 August 2014 at 13:00:19 UTC, Sönke Ludwig wrote:
Am 22.08.2014 14:47, schrieb matovitch:
Ok. I think I remember there was a stdx.d.lexer's Json parser
provided
as sample.
I see, so you just have to write your own number/string parsing
routines:
https://github.com/Hackerpilot/lexer-demo/blob/master/jsonlexer.d
It's kind of low level indeed...I don't know what kind of back
magic are doing all these template mixins but the code looks
quite clean.
Confusing :
// Therefore, this always returns false.
bool isSeparating(size_t offset) pure nothrow @safe
{
return true;
}
Re: Is there any preprocessor scripting language?
You can try D parsing libraries: http://forum.dlang.org/thread/jqwvudiwgiuprqcua...@forum.dlang.org they're believed to enable writing refactoring scripts.
Re: Is there any preprocessor scripting language?
Example:
import std.lexer;
import std.d.lexer;
import std.array;
import std.stdio;
void main(string[] args)
{
File input = File(args[1]);
File output = args.length 2 ? File(args[2]) : stdout;
ubyte[] inputBytes = uninitializedArray!(ubyte[])(input.size);
input.rawRead(inputBytes);
StringCache cache = StringCache(StringCache.defaultBucketCount);
LexerConfig config;
config.fileName = args[1];
config.stringBehavior = StringBehavior.source;
auto tokens = byToken(inputBytes, config, cache).array;
foreach (i; 0 .. tokens.length)
{
switch (tokens[i].type)
{
case tok!catch:
if (i + 1 tokens.length tokens[i + 1].type !=
tok!()
{
output.write(catch (Throwable));
break;
}
else
goto default;
default:
output.write(tokens[i].text is null
? str(tokens[i].type)
: tokens[i].text);
break;
}
}
}
Is there a native function to detect if file is UTF encoding?
To call decode() from std.encoding I need to make sure it is an UTF (may ne ASCII too) otherwise is will skyp over ASCII values. Is there any D native for it or I need to check byte order mark and write one myself?
Re: Some template code that worked in 2.065 is not working in 2.066
I believe it should work (it is no different from foreach(elem; myLib.Symbols) which works), but there are better experts on such topics hanging around.
Re: Is there a native function to detect if file is UTF encoding?
On Friday, 22 August 2014 at 13:53:04 UTC, MacAsm wrote: To call decode() from std.encoding I need to make sure it is an UTF (may ne ASCII too) otherwise is will skyp over ASCII values. Is there any D native for it or I need to check byte order mark and write one myself? You may want to take a look at http://dlang.org/phobos/std_stream.html#.EndianStream.readBOM . Note that this module is scheduled for depreciation...
Re: Automated source translation of C++ to D
On 8/22/14 1:29 AM, David Nadlinger wrote: On Friday, 22 August 2014 at 07:48:30 UTC, Daniel Murphy wrote: So no, you can't magically upgrade a project from C++ to D. Hence the name magicport? Sorry, could not resist. David It's pronounced sufficiently advanced technology port :)
Re: RFC: std.json sucessor
On 8/22/14, 3:33 AM, Sönke Ludwig wrote:
Am 22.08.2014 02:42, schrieb Ary Borenszweig:
Say I have a class Person with name (string) and age (int) with a
constructor that receives both. How would I create an instance of a
Person from a json with the json stream?
Suppose the json is this:
{age: 10, name: John}
And the class is this:
class Person {
this(string name, int age) {
// ...
}
}
Without a serialization framework it would in theory work like this:
JSONValue v = parseJSON(`{age: 10, name: John}`);
auto p = new Person(v[name].get!string, v[age].get!int);
unfortunately the operator overloading doesn't work like this currently,
so this is needed:
JSONValue v = parseJSON(`{age: 10, name: John}`);
auto p = new Person(
v.get!(Json[string])[name].get!string,
v.get!(Json[string])[age].get!int);
But does this parse the whole json into JSONValue? I want to create a
Person without creating an intermediate JSONValue for the whole json.
Can this be done?
Re: Is there a native function to detect if file is UTF encoding?
On Friday, 22 August 2014 at 13:53:04 UTC, MacAsm wrote:
To call decode() from std.encoding I need to make sure it is an
UTF (may ne ASCII too) otherwise is will skyp over ASCII
values. Is there any D native for it or I need to check byte
order mark and write one myself?
This may be simpler for reference:
https://github.com/kiith-sa/tinyendian/blob/master/source/tinyendian.d
Note that you _can't_ reliably differentiate between UTF-8 and
plain ASCII,
because not all UTF-8 files start with a UTF-8 BOM.
However, you can (relatively) quickly determine if a UTF-8/ASCII
buffer contains only ASCII characters; as UTF-8 bytes always have
the topmost bit set, and ASCII don't, you can use a 64-bit
bitmask and check by 8 characters at a time.
See
https://github.com/kiith-sa/D-YAML/blob/master/source/dyaml/reader.d,
specifically the countASCII() function - it should be easy to
change it into 'detectNonASCII':
/// Counts the number of ASCII characters in buffer until the
first UTF-8 sequence.
///
/// Used to determine how many characters we can process without
decoding.
size_t countASCII(const(char)[] buffer) @trusted pure nothrow
@nogc
{
size_t count = 0;
// The topmost bit in ASCII characters is always 0
enum ulong Mask8 = 0x7f7f7f7f7f7f7f7f;
enum uint Mask4 = 0x7f7f7f7f;
enum ushort Mask2 = 0x7f7f;
// Start by checking in 8-byte chunks.
while(buffer.length = Mask8.sizeof)
{
const block = *cast(typeof(Mask8)*)buffer.ptr;
const masked = Mask8 block;
if(masked != block) { break; }
count += Mask8.sizeof;
buffer = buffer[Mask8.sizeof .. $];
}
// If 8 bytes didn't match, try 4, 2 bytes.
import std.typetuple;
foreach(Mask; TypeTuple!(Mask4, Mask2))
{
if(buffer.length Mask.sizeof) { continue; }
const block = *cast(typeof(Mask)*)buffer.ptr;
const masked = Mask block;
if(masked != block) { continue; }
count += Mask.sizeof;
buffer = buffer[Mask.sizeof .. $];
}
// If even a 2-byte chunk didn't match, test just one byte.
if(buffer.empty || buffer[0] = 0x80) { return count; }
++count;
return count;
}
Re: Is there any preprocessor scripting language?
On Friday, 22 August 2014 at 13:33:12 UTC, Kagamin wrote: You can try D parsing libraries: http://forum.dlang.org/thread/jqwvudiwgiuprqcua...@forum.dlang.org they're believed to enable writing refactoring scripts. Thanks a lot! It will be useful.
Re: scope classes mentioned in tutorials, but deprecated
On 2014-08-22 10:37, Daniel Murphy wrote: It's listed as 'future', so it's not actually deprecated. Everyone is treating it as deprecated. While DDMD does currently use it extensively, it can be replaced if necessary. I'd much rather see it reinstated along with proper escape checking. Fair enough. -- /Jacob Carlborg
Re: RFC: std.json sucessor
On 2014-08-22 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 while. I'm quite pleased by the results so far, although without a serialization framework it still misses a very important building block. Code: https://github.com/s-ludwig/std_data_json Docs: http://s-ludwig.github.io/std_data_json/ DUB: http://code.dlang.org/packages/std_data_json * Opening braces should be put on their own line to follow Phobos style guides * I'm wondering about the assert in lexer.d, line 160. What happens if two invalid tokens after each other occur? * I think we have talked about this before, when reviewing D lexers. I'm thinking of how to handle invalid data. Is it the best solution to throw an exception? Would it be possible to return an error token and have the client decide what to do about? Shouldn't it be possible to build a JSON validator on this? * The lexer seems to always convert JSON types to their native D types, is that wise to do? That's unnecessary if you're implementing syntax highlighting -- /Jacob Carlborg
Re: scope classes mentioned in tutorials, but deprecated
On Thursday, 21 August 2014 at 18:07:31 UTC, Brad Anderson wrote: On Thursday, 21 August 2014 at 17:55:19 UTC, Timothee Cour via Digitalmars-d wrote: http://dlang.org/cpptod.html#raii mentions scope class and scope variables, which seem deprecated (http://dlang.org/deprecate.html) https://github.com/D-Programming-Language/dlang.org/pull/637 Didn't know about std.typecons.scoped. Nice!
Re: RFC: std.json sucessor
On Friday, 22 August 2014 at 15:47:51 UTC, Jacob Carlborg wrote: * I think we have talked about this before, when reviewing D lexers. I'm thinking of how to handle invalid data. Is it the best solution to throw an exception? Would it be possible to return an error token and have the client decide what to do about? Hmm... my initial reaction was not as default - it should throw on error, otherwise noone will check for errors. But if it's returning an error token, maybe it would be sufficient if that token throws when its value is accessed?
Re: RFC: std.json sucessor
Am 22.08.2014 17:47, schrieb Jacob Carlborg: On 2014-08-22 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 while. I'm quite pleased by the results so far, although without a serialization framework it still misses a very important building block. Code: https://github.com/s-ludwig/std_data_json Docs: http://s-ludwig.github.io/std_data_json/ DUB: http://code.dlang.org/packages/std_data_json * Opening braces should be put on their own line to follow Phobos style guides Will do. * I'm wondering about the assert in lexer.d, line 160. What happens if two invalid tokens after each other occur? There are actually no invalid tokens at all, the invalid enum value is only used to denote that no token is currently stored in _front. If readToken() doesn't throw, there will always be a valid token. * I think we have talked about this before, when reviewing D lexers. I'm thinking of how to handle invalid data. Is it the best solution to throw an exception? Would it be possible to return an error token and have the client decide what to do about? Shouldn't it be possible to build a JSON validator on this? That would indeed be a possibility, it's how I used to handle it in my private version of std.lexer, too. It could also be made a compile time option. * The lexer seems to always convert JSON types to their native D types, is that wise to do? That's unnecessary if you're implementing syntax highlighting It's basically the same trade-off as for unescaping string literals. For string inputs, it would be more efficient to just store a slice, but for generic input ranges it avoids the otherwise needed allocation. The proposed flag could make an improvement here, too.
Re: RFC: std.json sucessor
Am 22.08.2014 16:53, schrieb Ary Borenszweig:
On 8/22/14, 3:33 AM, Sönke Ludwig wrote:
Without a serialization framework it would in theory work like this:
JSONValue v = parseJSON(`{age: 10, name: John}`);
auto p = new Person(v[name].get!string, v[age].get!int);
unfortunately the operator overloading doesn't work like this currently,
so this is needed:
JSONValue v = parseJSON(`{age: 10, name: John}`);
auto p = new Person(
v.get!(Json[string])[name].get!string,
v.get!(Json[string])[age].get!int);
But does this parse the whole json into JSONValue? I want to create a
Person without creating an intermediate JSONValue for the whole json.
Can this be done?
That would be done by the serialization framework. Instead of using
parseJSON(), it could use parseJSONStream() to populate the Person
instance on the fly, without putting the whole JSON into memory. But I'd
like to leave that for a later addition, because we'd otherwise end up
with duplicate functionality once std.serialization gets finalized.
Manually it would work similar to this:
auto nodes = parseJSONStream(`{age: 10, name: John}`);
with (JSONParserNode.Kind) {
enforce(nodes.front == objectStart);
nodes.popFront();
while (nodes.front != objectEnd) {
auto key = nodes.front.key;
nodes.popFront();
if (key == name)
person.name = nodes.front.literal.string;
else if (key == age)
person.age = nodes.front.literal.number;
}
}
Re: RFC: std.json sucessor
Some thoughts about the API: 1) Instead of `parseJSONValue` and `lexJSON`, how about static methods `JSON.parse` and `JSON.lex`, or even a module level functions `std.data.json.parse` etc.? The JSON part of the name is redundant. 2) Also, `parseJSONValue` and `parseJSONStream` probably don't need to have different names. They can be distinguished by their parameter types. 3) `toJSONString` shouldn't just take a boolean as flag for pretty-printing. It should either use something like `Pretty.YES`, or the function should be called `toPrettyJSONString` (I believe I have seen this latter convention elsewhere). We should also think about whether we can just call the functions `toString` and `toPrettyString`. Alternatively, `toJSON` and `toPrettyJSON` should be considered.
Re: C++'s std::rotate
On Monday, 11 August 2014 at 14:45:09 UTC, Andrei Alexandrescu
wrote:
On 8/11/14, 2:11 AM, Nordlöw wrote:
On Monday, 11 August 2014 at 06:56:52 UTC, Dragos Carp wrote:
bool sliceOf(T)(in T[] whole, in T[] slice)
{
return whole.ptr = slice.ptr
whole.ptr + slice.length = whole.ptr + slice.length;
}
Shouldn't the function arguments of sliceOf be reversed to
given a more
intuitive UCFS as
if (slice.sliceOf(whole) { ... }
isSliceOf - yum
While sameHead and sameTail *could* have a good enough
generic implementation for ranges, there is absolutely no way to
make isSliceOf or overlap work for a generic range.
That said, sameHead and sameTail is just the iterator equivalent
of first1 == first2 and last1 == last2, which is used a lot
with iterators. You rarely see operator used with iterators
though, so I have doubts about why those two functions (isSliceOf
and overlap) would actually be of any use.
Re: RFC: std.json sucessor
It would be nice to have integers treated separately to doubles. I know it makes the number parsing simpler to just treat everything as double, but still, it could be annoying when you expect an integer type. I'd also like to see some benchmarks, particularly against some of the high performance C++ parsers, i.e. rapidjson, gason, sajson. Or even some of the not bad performance parsers with better APIs, i.e. QJsonDocument, jsoncpp and jsoncons (slow but perhaps comparable interface to this proposal?).
Re: RFC: std.json sucessor
Am 22.08.2014 18:15, schrieb Marc Schütz schue...@gmx.net: Some thoughts about the API: 1) Instead of `parseJSONValue` and `lexJSON`, how about static methods `JSON.parse` and `JSON.lex`, or even a module level functions `std.data.json.parse` etc.? The JSON part of the name is redundant. For those functions it may be acceptable, although I really dislike that style, because it makes the code harder to read (what exactly does this parse?) and the functions are rarely used, so that that typing that additional JSON should be no issue at all. On the other hand, if you always type JSON.lex it's more to type than just lexJSON. But for [JSON]Value it gets ugly really quick, because Values are such a common thing and quickly occur in multiple kinds in the same source file. 2) Also, `parseJSONValue` and `parseJSONStream` probably don't need to have different names. They can be distinguished by their parameter types. Actually they take exactly the same parameters and just differ in their return value. It would be more descriptive to name them parseAsJSONValue and parseAsJSONStream - or maybe parseJSONAsValue or parseJSONToValue? The current naming is somewhat modeled after std.conv's to!T and parse!T. 3) `toJSONString` shouldn't just take a boolean as flag for pretty-printing. It should either use something like `Pretty.YES`, or the function should be called `toPrettyJSONString` (I believe I have seen this latter convention elsewhere). We should also think about whether we can just call the functions `toString` and `toPrettyString`. Alternatively, `toJSON` and `toPrettyJSON` should be considered. Agreed, a boolean isn't good for a public interface, renaming the current writeAsString to private writeAsStringImpl and then adding (writeAs/to)[Pretty]String sounds reasonable. Actually I've done it that way for vibe.data.json.
Re: RFC: std.json sucessor
Am 22.08.2014 18:31, schrieb Christian Manning: It would be nice to have integers treated separately to doubles. I know it makes the number parsing simpler to just treat everything as double, but still, it could be annoying when you expect an integer type. That's how I've done it for vibe.data.json, too. For the new implementation, I've just used the number parsing routine from Andrei's std.jgrandson module. Does anybody have reservations about representing integers as long instead? I'd also like to see some benchmarks, particularly against some of the high performance C++ parsers, i.e. rapidjson, gason, sajson. Or even some of the not bad performance parsers with better APIs, i.e. QJsonDocument, jsoncpp and jsoncons (slow but perhaps comparable interface to this proposal?). That would indeed be nice to have, but I'm not sure if I can manage to squeeze that in besides finishing the module itself. My time frame for working on this is quite limited.
Re: Some template code that worked in 2.065 is not working in 2.066
On Friday, 22 August 2014 at 08:47:23 UTC, Uranuz wrote: In my project I have sort of complicated logic to implement data structure that is somehow similar to std.typecons.Tuple. I can't reproduce it, because I can't locate the source of bug. You could try using DustMite: https://github.com/CyberShadow/DustMite You can try to reduce the program to a smallest one that compiles in one version, but doesn't in another: https://github.com/CyberShadow/DustMite/wiki/Reducing-a-regression-between-two-D-versions You could also use Digger to find the compiler change which caused your code to stop compiling: https://github.com/CyberShadow/Digger
Re: RFC: std.json sucessor
On 8/22/14, 1:24 PM, Sönke Ludwig wrote:
Am 22.08.2014 16:53, schrieb Ary Borenszweig:
On 8/22/14, 3:33 AM, Sönke Ludwig wrote:
Without a serialization framework it would in theory work like this:
JSONValue v = parseJSON(`{age: 10, name: John}`);
auto p = new Person(v[name].get!string, v[age].get!int);
unfortunately the operator overloading doesn't work like this currently,
so this is needed:
JSONValue v = parseJSON(`{age: 10, name: John}`);
auto p = new Person(
v.get!(Json[string])[name].get!string,
v.get!(Json[string])[age].get!int);
But does this parse the whole json into JSONValue? I want to create a
Person without creating an intermediate JSONValue for the whole json.
Can this be done?
That would be done by the serialization framework. Instead of using
parseJSON(), it could use parseJSONStream() to populate the Person
instance on the fly, without putting the whole JSON into memory. But I'd
like to leave that for a later addition, because we'd otherwise end up
with duplicate functionality once std.serialization gets finalized.
Manually it would work similar to this:
auto nodes = parseJSONStream(`{age: 10, name: John}`);
with (JSONParserNode.Kind) {
enforce(nodes.front == objectStart);
nodes.popFront();
while (nodes.front != objectEnd) {
auto key = nodes.front.key;
nodes.popFront();
if (key == name)
person.name = nodes.front.literal.string;
else if (key == age)
person.age = nodes.front.literal.number;
}
}
Cool, that looks good :-)
Re: RFC: std.json sucessor
On Friday, 22 August 2014 at 16:48:44 UTC, Sönke Ludwig wrote: Am 22.08.2014 18:15, schrieb Marc Schütz schue...@gmx.net: Some thoughts about the API: 1) Instead of `parseJSONValue` and `lexJSON`, how about static methods `JSON.parse` and `JSON.lex`, or even a module level functions `std.data.json.parse` etc.? The JSON part of the name is redundant. For those functions it may be acceptable, although I really dislike that style, because it makes the code harder to read (what exactly does this parse?) and the functions are rarely used, so that that typing that additional JSON should be no issue at all. On the other hand, if you always type JSON.lex it's more to type than just lexJSON. I'm not really concerned about the amount of typing, it just seemed a bit odd to have the redundant JSON in there, as we have module names for namespacing. Your argument about readability is true nevertheless. But... But for [JSON]Value it gets ugly really quick, because Values are such a common thing and quickly occur in multiple kinds in the same source file. 2) Also, `parseJSONValue` and `parseJSONStream` probably don't need to have different names. They can be distinguished by their parameter types. Actually they take exactly the same parameters and just differ in their return value. It would be more descriptive to name them parseAsJSONValue and parseAsJSONStream - or maybe parseJSONAsValue or parseJSONToValue? The current naming is somewhat modeled after std.conv's to!T and parse!T. ... why not use exactly the same convention then? = `parse!JSONValue` Would be nice to have a pluggable API where you just need to specify the type in a factory method to choose the input format. Then there could be `parse!BSON`, `parse!YAML`, with the same style as `parse!(int[])`. I know this sound a bit like bike-shedding, but the API shouldn't stand by itself, but fit into the big picture, especially as there will probably be other parsers (you already named the module std._data_.json).
Re: RFC: std.json sucessor
On Friday, 22 August 2014 at 16:56:26 UTC, Sönke Ludwig wrote: Am 22.08.2014 18:31, schrieb Christian Manning: It would be nice to have integers treated separately to doubles. I know it makes the number parsing simpler to just treat everything as double, but still, it could be annoying when you expect an integer type. That's how I've done it for vibe.data.json, too. For the new implementation, I've just used the number parsing routine from Andrei's std.jgrandson module. Does anybody have reservations about representing integers as long instead? It should automatically fall back to double on overflow. Maybe even use BigInt if applicable?
Re: RFC: std.json sucessor
Am 22.08.2014 19:24, schrieb Marc Schütz schue...@gmx.net: On Friday, 22 August 2014 at 16:48:44 UTC, Sönke Ludwig wrote: Actually they take exactly the same parameters and just differ in their return value. It would be more descriptive to name them parseAsJSONValue and parseAsJSONStream - or maybe parseJSONAsValue or parseJSONToValue? The current naming is somewhat modeled after std.conv's to!T and parse!T. ... why not use exactly the same convention then? = `parse!JSONValue` Would be nice to have a pluggable API where you just need to specify the type in a factory method to choose the input format. Then there could be `parse!BSON`, `parse!YAML`, with the same style as `parse!(int[])`. I know this sound a bit like bike-shedding, but the API shouldn't stand by itself, but fit into the big picture, especially as there will probably be other parsers (you already named the module std._data_.json). That would be nice, but then it should also work together with std.conv, which basically is exactly this pluggable API. Just like this it would result in an ambiguity error if both std.data.json and std.conv are imported at the same time. Is there a way to make std.conv work properly with JSONValue? I guess the only theoretical way would be to put something in JSONValue, but that would result in a slightly ugly cyclic dependency between parser.d and value.d.
Re: RFC: std.json sucessor
Am 22.08.2014 19:27, schrieb Marc Schütz schue...@gmx.net: On Friday, 22 August 2014 at 16:56:26 UTC, Sönke Ludwig wrote: Am 22.08.2014 18:31, schrieb Christian Manning: It would be nice to have integers treated separately to doubles. I know it makes the number parsing simpler to just treat everything as double, but still, it could be annoying when you expect an integer type. That's how I've done it for vibe.data.json, too. For the new implementation, I've just used the number parsing routine from Andrei's std.jgrandson module. Does anybody have reservations about representing integers as long instead? It should automatically fall back to double on overflow. Maybe even use BigInt if applicable? I guess BigInt + exponent would be the only lossless way to represent any JSON number. That could then be converted to any desired smaller type as required. But checking for overflow during number parsing would definitely have an impact on parsing speed, as well as using a BigInt of course, so the question is how we want set up the trade off here (or if there is another way that is overhead-free).
Yet another victory for D
A friend of mine stumbled across this today: http://tomerfiliba.com/blog/dlang/ Rejoice! :-) T -- Why waste time reinventing the wheel, when you could be reinventing the engine? -- Damian Conway
Re: Yet another victory for D
On Friday, 22 August 2014 at 17:54:36 UTC, H. S. Teoh via Digitalmars-d wrote: A friend of mine stumbled across this today: http://tomerfiliba.com/blog/dlang/ Rejoice! :-) T There's a fairly active conversation going on about this article on Hacker News currently. https://news.ycombinator.com/item?id=8211639
Re: RFC: std.json sucessor
On Friday, 22 August 2014 at 17:35:20 UTC, Sönke Ludwig wrote:
... why not use exactly the same convention then? =
`parse!JSONValue`
Would be nice to have a pluggable API where you just need to
specify
the type in a factory method to choose the input format. Then
there
could be `parse!BSON`, `parse!YAML`, with the same style as
`parse!(int[])`.
I know this sound a bit like bike-shedding, but the API
shouldn't stand
by itself, but fit into the big picture, especially as there
will
probably be other parsers (you already named the module
std._data_.json).
That would be nice, but then it should also work together with
std.conv, which basically is exactly this pluggable API. Just
like this it would result in an ambiguity error if both
std.data.json and std.conv are imported at the same time.
Is there a way to make std.conv work properly with JSONValue? I
guess the only theoretical way would be to put something in
JSONValue, but that would result in a slightly ugly cyclic
dependency between parser.d and value.d.
The easiest and cleanest way would be to add a function in
std.data.json:
auto parse(Target, Source)(Source input)
if(is(Target == JSONValue))
{
return ...;
}
The various overloads of `std.conv.parse` already have mutually
exclusive template constraints, they will not collide with our
function.
Re: Yet another victory for D
On Friday, 22 August 2014 at 17:54:36 UTC, H. S. Teoh via Digitalmars-d wrote: A friend of mine stumbled across this today: http://tomerfiliba.com/blog/dlang/ Rejoice! :-) T http://forum.dlang.org/post/qycdbardacyhvabyq...@forum.dlang.org
Re: RFC: std.json sucessor
On Friday, 22 August 2014 at 17:45:03 UTC, Sönke Ludwig wrote: Am 22.08.2014 19:27, schrieb Marc Schütz schue...@gmx.net: On Friday, 22 August 2014 at 16:56:26 UTC, Sönke Ludwig wrote: Am 22.08.2014 18:31, schrieb Christian Manning: It would be nice to have integers treated separately to doubles. I know it makes the number parsing simpler to just treat everything as double, but still, it could be annoying when you expect an integer type. That's how I've done it for vibe.data.json, too. For the new implementation, I've just used the number parsing routine from Andrei's std.jgrandson module. Does anybody have reservations about representing integers as long instead? It should automatically fall back to double on overflow. Maybe even use BigInt if applicable? I guess BigInt + exponent would be the only lossless way to represent any JSON number. That could then be converted to any desired smaller type as required. But checking for overflow during number parsing would definitely have an impact on parsing speed, as well as using a BigInt of course, so the question is how we want set up the trade off here (or if there is another way that is overhead-free). As the functions will be templatized anyway, it should include a flags parameter. These and possible future extensions can then be selected by the user.
Re: Yet another victory for D
I got this FB chatted to me from an old programmer friend too yesterday who has never used D himself but knows I do. It seems to be getting somewhat broad exposure.
Re: RFC: std.json sucessor
On 8/21/2014 3:35 PM, Sönke Ludwig wrote: Destroy away! ;) Thanks for taking this on! This is valuable work. On to destruction! I'm looking at: http://s-ludwig.github.io/std_data_json/stdx/data/json/lexer/lexJSON.html I anticipate this will be used a LOT and in very high speed demanding applications. With that in mind, 1. There's no mention of what will happen if it is passed malformed JSON strings. I presume an exception is thrown. Exceptions are both slow and consume GC memory. I suggest an alternative would be to emit an Error token instead; this would be much like how the UTF decoding algorithms emit a replacement char for invalid UTF sequences. 2. The escape sequenced strings presumably consume GC memory. This will be a problem for high performance code. I suggest either leaving them undecoded in the token stream, and letting higher level code decide what to do about them, or provide a hook that the user can override with his own allocation scheme. If we don't make it possible to use std.json without invoking the GC, I believe the module will fail in the long term.
Re: RFC: std.json sucessor
Am 22.08.2014 19:57, schrieb Marc Schütz schue...@gmx.net:
On Friday, 22 August 2014 at 17:35:20 UTC, Sönke Ludwig wrote:
... why not use exactly the same convention then? = `parse!JSONValue`
Would be nice to have a pluggable API where you just need to specify
the type in a factory method to choose the input format. Then there
could be `parse!BSON`, `parse!YAML`, with the same style as
`parse!(int[])`.
I know this sound a bit like bike-shedding, but the API shouldn't stand
by itself, but fit into the big picture, especially as there will
probably be other parsers (you already named the module
std._data_.json).
That would be nice, but then it should also work together with
std.conv, which basically is exactly this pluggable API. Just like
this it would result in an ambiguity error if both std.data.json and
std.conv are imported at the same time.
Is there a way to make std.conv work properly with JSONValue? I guess
the only theoretical way would be to put something in JSONValue, but
that would result in a slightly ugly cyclic dependency between
parser.d and value.d.
The easiest and cleanest way would be to add a function in std.data.json:
auto parse(Target, Source)(Source input)
if(is(Target == JSONValue))
{
return ...;
}
The various overloads of `std.conv.parse` already have mutually
exclusive template constraints, they will not collide with our function.
Okay, for parse that may work, but what about to!()?
Re: Yet another victory for D
On Fri, Aug 22, 2014 at 05:55:03PM +, Dicebot via Digitalmars-d wrote: [...] http://forum.dlang.org/post/qycdbardacyhvabyq...@forum.dlang.org On Fri, Aug 22, 2014 at 05:56:12PM +, Brad Anderson via Digitalmars-d wrote: [...] There's a fairly active conversation going on about this article on Hacker News currently. https://news.ycombinator.com/item?id=8211639 I see that I've been ninja'd. Well, nevermind then! ;-) T -- I'm not childish; I'm just in touch with the child within! - RL
Re: Yet another victory for D
On Fri, Aug 22, 2014 at 06:05:03PM +, Adam D. Ruppe via Digitalmars-d wrote: I got this FB chatted to me from an old programmer friend too yesterday who has never used D himself but knows I do. It seems to be getting somewhat broad exposure. Ah, that would explain why this particular friend of mine found it. He's skeptical of D, even though he knows that I use it. In any case, broad exposure is all the better for us. :) T -- No! I'm not in denial!
Re: RFC: std.json sucessor
Am 22.08.2014 20:01, schrieb Marc Schütz schue...@gmx.net: On Friday, 22 August 2014 at 17:45:03 UTC, Sönke Ludwig wrote: Am 22.08.2014 19:27, schrieb Marc Schütz schue...@gmx.net: On Friday, 22 August 2014 at 16:56:26 UTC, Sönke Ludwig wrote: Am 22.08.2014 18:31, schrieb Christian Manning: It would be nice to have integers treated separately to doubles. I know it makes the number parsing simpler to just treat everything as double, but still, it could be annoying when you expect an integer type. That's how I've done it for vibe.data.json, too. For the new implementation, I've just used the number parsing routine from Andrei's std.jgrandson module. Does anybody have reservations about representing integers as long instead? It should automatically fall back to double on overflow. Maybe even use BigInt if applicable? I guess BigInt + exponent would be the only lossless way to represent any JSON number. That could then be converted to any desired smaller type as required. But checking for overflow during number parsing would definitely have an impact on parsing speed, as well as using a BigInt of course, so the question is how we want set up the trade off here (or if there is another way that is overhead-free). As the functions will be templatized anyway, it should include a flags parameter. These and possible future extensions can then be selected by the user. I'm actually in the process of converting the track_location parameter to a flags enum and to add support for an error token, so this would fit right in.
Re: const after initialization / pointers, references and values
First of all thanks for your replies, they are useful. @Philippe: A pure function is ok for initializing default_nodes but not for nodes because a pure function can't read a file. The static this has the problem it needs know the initializer at compile time but I wanted to choose the initializer at run time. I know default_nodes can be changed to immutable, but then it will require an explicit cast to remove the immutability. The final class may be a good point, I'll try this one. @Jakob: Thank you, but I'll go with Philippe's suggestion. @Wyatt: Certainly ref parameters help a lot, but I'm trying to get a Node by returning (a reference to) it. Does the ref keyword apply to the return type? Next time I'll post to D.learn, sorry for misplacing my question. Regards, Vicente.
Re: RFC: std.json sucessor
On Friday, 22 August 2014 at 18:08:34 UTC, Sönke Ludwig wrote:
Am 22.08.2014 19:57, schrieb Marc Schütz schue...@gmx.net:
The easiest and cleanest way would be to add a function in
std.data.json:
auto parse(Target, Source)(Source input)
if(is(Target == JSONValue))
{
return ...;
}
The various overloads of `std.conv.parse` already have mutually
exclusive template constraints, they will not collide with our
function.
Okay, for parse that may work, but what about to!()?
What's the problem with to!()?
Unused variables and bugs
Apparently there is evidence that unused variables in C-like languages correlate with bugs: https://kev.inburke.com/slides/errors/#error-correlations One problem with ruling out some classes of unused variables (like unused function arguments, unused private module-level variables, unused function-local variables, and so on) is that when you are writing code you sometimes add some unused variables, that you usually will use or remove later. So you usually don't want an error or warning for unused variables when you are writing code, but later there is a moment when you probably want to clean up your code and remove any unused variable to make the code more clean and tight. A simple solution in C-languages is to add a compiler switch that allows to disallow or allow the unused variables according to the phase of your working on the code. But compiler switch proliferation can be a problem (unless you use an IDE, that offers you a button to enable/disable such tests). Another solution is to leave such tests out of the core compiler, and put them in a lint tool that you run when you think your code is in good shape. Bye, bearophile
Re: RFC: std.json sucessor
On 8/22/14, Sönke Ludwig digitalmars-d@puremagic.com wrote:
Docs: http://s-ludwig.github.io/std_data_json/
This confused me for a solid minute:
// Lex a JSON string into a lazy range of tokens
auto tokens = lexJSON(`{name: Peter, age: 42}`);
with (JSONToken.Kind) {
assert(tokens.map!(t = t.kind).equal(
[objectStart, string, colon, string, comma,
string, colon, number, objectEnd]));
}
Generally I'd avoid using de-facto reserved names as enum member names
(e.g. string).
Re: Windows service in D
Ten years is a long time but perhaps this can help anyone running into this forum thread. https://github.com/duovia/WindowsServiceInD I'm using the Windows API library (source actually) on dsource.org. See link on the github page. I found it difficult to find a complete solution to the problem, so I'm going to cross post in a few places to make it easier to find for others seeking an answer to the same question. On Wednesday, 9 June 2004 at 21:18:45 UTC, Walter wrote: If probably means you need to link in the .obj for the module where SERVICE_TABLE_ENTRY is defined. Gifford Hesketh gifford.hesk...@savvis.net wrote in message news:c93ciu$lk8$1...@digitaldaemon.com... A few months ago, I asked if anyone had an example of a Windows service written in D. Not finding one, I wrote one -- although there was one outstanding issue I wanted to resolve before making it public. Looking at this again, D's tools changes seem to have broken the compilation. Before I make anyone wade through my code, does an error like the following look familiar to anyone ? \dm\samples\d\servicedmd -v service.d advapi32.lib parse service semantic service semantic2 service semantic3 service code service generating code for function 'main' generating code for function 'ServiceMain' generating code for function 'ServiceCtrlHandler' \dm\bin\link service,,,advapi32.lib+user32+kernel32/noi; OPTLINK (R) for Win32 Release 7.50B1 Copyright (C) Digital Mars 1989 - 2001 All Rights Reserved service.obj(service) Error 42: Symbol Undefined __init_6winsvc19SERVICE_TABLE_ENTRY --- errorlevel 1
Re: RFC: std.json sucessor
Am 22.08.2014 21:15, schrieb Andrej Mitrovic via Digitalmars-d:
On 8/22/14, Sönke Ludwig digitalmars-d@puremagic.com wrote:
Docs: http://s-ludwig.github.io/std_data_json/
This confused me for a solid minute:
// Lex a JSON string into a lazy range of tokens
auto tokens = lexJSON(`{name: Peter, age: 42}`);
with (JSONToken.Kind) {
assert(tokens.map!(t = t.kind).equal(
[objectStart, string, colon, string, comma,
string, colon, number, objectEnd]));
}
Generally I'd avoid using de-facto reserved names as enum member names
(e.g. string).
Hmmm, but it *is* a string. Isn't the problem more the use of with in
this case? Maybe the example should just use with(JSONToken) and then
Kind.string?
Re: $100 bounty for help with Windows Service code
On Friday, 22 August 2014 at 09:09:22 UTC, Kagamin wrote: https://github.com/duovia/WindowsServiceInD/blob/master/src/onedge/mysvc.d#L20 these are not necessarily static: it makes sense to have instance fields of shared types too. Yes, Kagamin, you're right. I'll pull those out of shared as the OnStart, OnStop, and other On methods get called by the SCM on the same thread. I'll make that change. Thanks.
Re: RFC: std.json sucessor
On Friday, 22 August 2014 at 17:45:03 UTC, Sönke Ludwig wrote: Am 22.08.2014 19:27, schrieb Marc Schütz schue...@gmx.net: On Friday, 22 August 2014 at 16:56:26 UTC, Sönke Ludwig wrote: Am 22.08.2014 18:31, schrieb Christian Manning: It would be nice to have integers treated separately to doubles. I know it makes the number parsing simpler to just treat everything as double, but still, it could be annoying when you expect an integer type. That's how I've done it for vibe.data.json, too. For the new implementation, I've just used the number parsing routine from Andrei's std.jgrandson module. Does anybody have reservations about representing integers as long instead? It should automatically fall back to double on overflow. Maybe even use BigInt if applicable? I guess BigInt + exponent would be the only lossless way to represent any JSON number. That could then be converted to any desired smaller type as required. But checking for overflow during number parsing would definitely have an impact on parsing speed, as well as using a BigInt of course, so the question is how we want set up the trade off here (or if there is another way that is overhead-free). You could check for a decimal point and a 0 at the front (excluding possible - sign), either would indicate a double, making the reasonable assumption that anything else will fit in a long.
Re: RFC: std.json sucessor
Am 22.08.2014 21:48, schrieb Christian Manning: On Friday, 22 August 2014 at 17:45:03 UTC, Sönke Ludwig wrote: Am 22.08.2014 19:27, schrieb Marc Schütz schue...@gmx.net: On Friday, 22 August 2014 at 16:56:26 UTC, Sönke Ludwig wrote: Am 22.08.2014 18:31, schrieb Christian Manning: It would be nice to have integers treated separately to doubles. I know it makes the number parsing simpler to just treat everything as double, but still, it could be annoying when you expect an integer type. That's how I've done it for vibe.data.json, too. For the new implementation, I've just used the number parsing routine from Andrei's std.jgrandson module. Does anybody have reservations about representing integers as long instead? It should automatically fall back to double on overflow. Maybe even use BigInt if applicable? I guess BigInt + exponent would be the only lossless way to represent any JSON number. That could then be converted to any desired smaller type as required. But checking for overflow during number parsing would definitely have an impact on parsing speed, as well as using a BigInt of course, so the question is how we want set up the trade off here (or if there is another way that is overhead-free). You could check for a decimal point and a 0 at the front (excluding possible - sign), either would indicate a double, making the reasonable assumption that anything else will fit in a long. Yes, no decimal point + no exponent would work without overhead to detect integers, but that wouldn't solve the proposed automatic long-double overflow, which is what I meant. My current idea is to default to double and optionally support any of long, BigInt and Decimal (BigInt+exponent), where integer overflow only works for long-BigInt.
Re: const after initialization / pointers, references and values
Indeed the ref can be applied to the return type:
http://dlang.org/function.html#ref-functions
So, does the following code copy any data from nodes?
If that is the case this solution avoids the class storage,
avoids pointers and nodes is encapsulated as read-only, that's
great.
The program I'm working on is still incomplete, so I still can't
benchmark it to compare with all proposed solutions.
@safe:
import std.stdio;
import std.string;
struct Node {
Node[] block;
uint num = 0;
};
immutable uint LAST = -1;
Node[] default_nodes = [
{num:3},
{block:[{num:4},{num:6},{block:[{num:5},{num:7}]}]},
// ...
{num:LAST},
];
class NodeProvider{
// change to const after constructor
private Node[] nodes;
private void parse_file(char[] file_name){
// initialize nodes from file
for(auto i=0; i3; i++){
nodes.length++;
nodes[$-1].num=i;
}
nodes.length++;
nodes[$-1].num=LAST;
}
this(){
nodes = default_nodes;
}
this(char[] file_name){
parse_file(file_name);
}
ref const(Node) get_node(const uint index){
return nodes[index];
}
}
string NodetoString(ref const(Node) n){
string str = format(%u{ , n.num);
foreach(b;n.block)
str ~= NodetoString(b);
str ~= } ;
return str;
}
@system: // for writeln
int main(char[][] args){
NodeProvider np;
uint i;
if(args.length==2)
np = new NodeProvider(args[1]);
else
np = new NodeProvider();
for(i=0;;i++){
const(Node) node = np.get_node(i);
if(node.num==LAST)
break;
writeln(NodetoString(node));
}
return 0;
}
Re: const after initialization / pointers, references and values
On Friday, 22 August 2014 at 18:21:06 UTC, Vicente wrote:
@Wyatt:
Certainly ref parameters help a lot, but I'm trying to get a
Node by returning (a reference to) it. Does the ref keyword
apply to the return type?
I poked it a bit and came out with this. I _think_ it's working
as expected:
import std.stdio;
import std.string;
// struct or class
struct Node {
Node[] block;
uint num = 0;
};
// static immutable
Node[] default_nodes = [
{num:3},
{block:[{num:4},{num:6},{block:[{num:5},{num:7}]}]},
// ...
];
class NodeProvider{
// change to const after constructor
private Node[] nodes;
private void parse_file(char[] file_name){
// initialize nodes from file
for(auto i=0; i3; i++){
nodes.length++;
nodes[$-1].num=i;
}
}
this(){
nodes = default_nodes;
}
this(char[] file_name){
parse_file(file_name);
}
auto ref opSlice(){return nodes[];};
}
string NodetoString(ref Node n){
string str = format(%u{ , n.num);
foreach(b;n.block)
str ~= NodetoString(b);
str ~= } ;
return str;
}
int main(char[][] args){
NodeProvider np;
if(args.length==2)
np = new NodeProvider(args[1]);
else
np = new NodeProvider();
foreach(node_ref; np){
writeln(NodetoString(node_ref));
}
return 0;
}
-Wyatt
Re: RFC: std.json sucessor
On Friday, 22 August 2014 at 20:02:41 UTC, Sönke Ludwig wrote: Am 22.08.2014 21:48, schrieb Christian Manning: On Friday, 22 August 2014 at 17:45:03 UTC, Sönke Ludwig wrote: Am 22.08.2014 19:27, schrieb Marc Schütz schue...@gmx.net: On Friday, 22 August 2014 at 16:56:26 UTC, Sönke Ludwig wrote: Am 22.08.2014 18:31, schrieb Christian Manning: It would be nice to have integers treated separately to doubles. I know it makes the number parsing simpler to just treat everything as double, but still, it could be annoying when you expect an integer type. That's how I've done it for vibe.data.json, too. For the new implementation, I've just used the number parsing routine from Andrei's std.jgrandson module. Does anybody have reservations about representing integers as long instead? It should automatically fall back to double on overflow. Maybe even use BigInt if applicable? I guess BigInt + exponent would be the only lossless way to represent any JSON number. That could then be converted to any desired smaller type as required. But checking for overflow during number parsing would definitely have an impact on parsing speed, as well as using a BigInt of course, so the question is how we want set up the trade off here (or if there is another way that is overhead-free). You could check for a decimal point and a 0 at the front (excluding possible - sign), either would indicate a double, making the reasonable assumption that anything else will fit in a long. Yes, no decimal point + no exponent would work without overhead to detect integers, but that wouldn't solve the proposed automatic long-double overflow, which is what I meant. My current idea is to default to double and optionally support any of long, BigInt and Decimal (BigInt+exponent), where integer overflow only works for long-BigInt. It might be the right choice anyway (seeing as json/js do overflow to double), but fwiw it's still atrocious. double a = long.max; assert(iota(1, 100).map!(d = (a+d)-a).until!a != 0.walkLength == 1024); Yuk. Floating point numbers and integers are so completely different in behaviour that it's just dishonest to transparently switch between the two. This especially the case for overflow from long - double, where by definition you're 10 bits past being able to reliably accurately represent the integer in question.
Re: Unused variables and bugs
On Friday, 22 August 2014 at 19:07:24 UTC, bearophile wrote: Another solution is to leave such tests out of the core compiler, and put them in a lint tool that you run when you think your code is in good shape. https://github.com/Hackerpilot/Dscanner The unused variable and unused parameter checks have existed since May. As far as I know it only gives false positives if mixin statements are present.
Re: RFC: std.json sucessor
Yes, no decimal point + no exponent would work without overhead to detect integers, but that wouldn't solve the proposed automatic long-double overflow, which is what I meant. My current idea is to default to double and optionally support any of long, BigInt and Decimal (BigInt+exponent), where integer overflow only works for long-BigInt. Ah I see. I have to say, if you are going to treat integers and floating point numbers differently, then you should store them differently. long should be used to store integers, double for floating point numbers. 64 bit signed integer (long) is a totally reasonable limitation for integers, but even that would lose precision stored as a double as you are proposing (if I'm understanding right). I don't think BigInt needs to be brought into this at all really. In the case of integers met in the parser which are too large/small to fit in long, give an error IMO. Such integers should be (and are by other libs IIRC) serialised in the form 1.234e-123 to force double parsing, perhaps losing precision at that stage rather than invisibly inside the library. Size of JSON numbers is implementation defined and the whole thing shouldn't be degraded in both performance and usability to cover JSON serialisers who go beyond common native number types. Of course, you are free to do whatever you like :)
Re: const after initialization / pointers, references and values
On Friday, 22 August 2014 at 20:12:39 UTC, Wyatt wrote:
I poked it a bit and came out with this. I _think_ it's
working as expected:
...
auto ref opSlice(){return nodes[];};
...
-Wyatt
Assuming it's working as expected, that is exactly what I was
looking for!
But the following code shows that at some point data gets copied.
By the way, neither works what I've posted previously.
In any case, thank you very much Wyatt.
Regards,
Vicente.
@safe:
import std.stdio;
import std.string;
struct Node { Node[] block; uint num = 0; };
/* immutable */ Node[] default_nodes = [ {num:3},
{block:[{num:4}]}, {num:6} ];
class NodeProvider{
private /* const */ Node[] nodes;
private Node[] tmp_nodes;
private void parse_file(char[] file_name){
tmp_nodes.length=1; tmp_nodes[0].num=5;
}
this(){ nodes = default_nodes; }
this(char[] file_name){
parse_file(file_name);
nodes = tmp_nodes;
}
auto ref opSlice(){return nodes[];};
}
@system: // for writeln
int main(char[][] args){
NodeProvider np;
if(args.length==2) np = new NodeProvider(args[1]);
else np = new NodeProvider();
// if they are real references this will modify the source data
foreach(node_ref; np) node_ref.num = 101;
// and will print all 101
foreach(node_ref; np) writeln(node_ref.num);
// but it prints unmodified 3, 0 and 6
return 0;
}
Re: Unused variables and bugs
Brian Schott: The unused variable and unused parameter checks have existed since May. As far as I know it only gives false positives if mixin statements are present. Another interesting feature is similar to -Wsuggest-final-types and -Wsuggest-final-methods. They give warnings when there is a method or whole class that can be tagged with final. This allows to avoid virtual methods. This in D is even more important than C++ because of the virtual on the default of D, that was widely discussed and at the end never fixed. Bye, bearophile
Re: RFC: std.json sucessor
Am 22.08.2014 20:08, schrieb Walter Bright: On 8/21/2014 3:35 PM, Sönke Ludwig wrote: Destroy away! ;) Thanks for taking this on! This is valuable work. On to destruction! I'm looking at: http://s-ludwig.github.io/std_data_json/stdx/data/json/lexer/lexJSON.html I anticipate this will be used a LOT and in very high speed demanding applications. With that in mind, 1. There's no mention of what will happen if it is passed malformed JSON strings. I presume an exception is thrown. Exceptions are both slow and consume GC memory. I suggest an alternative would be to emit an Error token instead; this would be much like how the UTF decoding algorithms emit a replacement char for invalid UTF sequences. The latest version now features a LexOptions.noThrow option which causes an error token to be emitted instead. After popping the error token, the range is always empty. 2. The escape sequenced strings presumably consume GC memory. This will be a problem for high performance code. I suggest either leaving them undecoded in the token stream, and letting higher level code decide what to do about them, or provide a hook that the user can override with his own allocation scheme. The problem is that it really depends on the use case and on the type of input stream which approach is more efficient (storing the escaped version of a string might require *two* allocations if the input range cannot be sliced and if the decoded string is then requested by the parser). My current idea therefore is to simply make this configurable, too. Enabling the use of custom allocators should be easily possible as an add-on functionality later on. At least my suggestion would be to wait with this until we have a finished std.allocator module.
Re: RFC: std.json sucessor
Am 22.08.2014 18:13, schrieb Sönke Ludwig: Am 22.08.2014 17:47, schrieb Jacob Carlborg: * Opening braces should be put on their own line to follow Phobos style guides Will do. * I'm wondering about the assert in lexer.d, line 160. What happens if two invalid tokens after each other occur? There are actually no invalid tokens at all, the invalid enum value is only used to denote that no token is currently stored in _front. If readToken() doesn't throw, there will always be a valid token. Renamed from invalid to none now to avoid confusion - * I think we have talked about this before, when reviewing D lexers. I'm thinking of how to handle invalid data. Is it the best solution to throw an exception? Would it be possible to return an error token and have the client decide what to do about? Shouldn't it be possible to build a JSON validator on this? That would indeed be a possibility, it's how I used to handle it in my private version of std.lexer, too. It could also be made a compile time option. and an additional error kind has been added, which implements the above. Enabled using LexOptions.noThrow. * The lexer seems to always convert JSON types to their native D types, is that wise to do? That's unnecessary if you're implementing syntax highlighting It's basically the same trade-off as for unescaping string literals. For string inputs, it would be more efficient to just store a slice, but for generic input ranges it avoids the otherwise needed allocation. The proposed flag could make an improvement here, too.
Re: Unused variables and bugs
On 08/22/2014 09:07 PM, bearophile wrote: Apparently there is evidence that unused variables in C-like languages correlate with bugs: https://kev.inburke.com/slides/errors/#error-correlations ... http://xkcd.com/552/
