Re: D 2.066 is out. Enjoy!

2014-08-22 Thread Daniel Murphy via Digitalmars-d-announce
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!

2014-08-22 Thread Daniel Murphy via Digitalmars-d-announce

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!

2014-08-22 Thread via Digitalmars-d-announce

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!

2014-08-22 Thread Dejan Lekic via Digitalmars-d-announce
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!

2014-08-22 Thread bachmeier via Digitalmars-d-announce

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!

2014-08-22 Thread Andrei Alexandrescu via Digitalmars-d-announce

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

2014-08-22 Thread Dmitry Olshansky via Digitalmars-d-announce

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!

2014-08-22 Thread Walter Bright via Digitalmars-d-announce

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!

2014-08-22 Thread John Colvin via Digitalmars-d-announce
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!

2014-08-22 Thread Walter Bright via Digitalmars-d-announce

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!

2014-08-22 Thread Andrei Alexandrescu via Digitalmars-d-announce

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!

2014-08-22 Thread Andrei Alexandrescu via Digitalmars-d-announce

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!

2014-08-22 Thread John via Digitalmars-d-announce

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!

2014-08-22 Thread Brad Roberts via Digitalmars-d-announce

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.

2014-08-22 Thread Tyler Jensen via Digitalmars-d-announce

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

2014-08-22 Thread Dicebot via Digitalmars-d-announce
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!

2014-08-22 Thread Kagamin via Digitalmars-d-announce

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

2014-08-22 Thread bearophile via Digitalmars-d-announce

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!

2014-08-22 Thread Andrew Edwards via Digitalmars-d-announce

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

2014-08-22 Thread Paul D Anderson via Digitalmars-d-announce

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

2014-08-22 Thread ketmar via Digitalmars-d-announce
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

2014-08-22 Thread ketmar via Digitalmars-d-announce
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

2014-08-22 Thread ParkHyunAh12A via Digitalmars-d

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

2014-08-22 Thread ParkHyunAh12A via Digitalmars-d

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

2014-08-22 Thread Sönke Ludwig via Digitalmars-d

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

2014-08-22 Thread Sönke Ludwig via Digitalmars-d

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

2014-08-22 Thread Sönke Ludwig via Digitalmars-d

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

2014-08-22 Thread Daniel Murphy via Digitalmars-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

2014-08-22 Thread Jacob Carlborg via Digitalmars-d

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

2014-08-22 Thread bearophile via Digitalmars-d

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

2014-08-22 Thread David Nadlinger via Digitalmars-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

2014-08-22 Thread Daniel Murphy via Digitalmars-d

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

2014-08-22 Thread Daniel Murphy via Digitalmars-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

2014-08-22 Thread ketmar via Digitalmars-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

2014-08-22 Thread Uranuz via Digitalmars-d
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?

2014-08-22 Thread Uranuz via Digitalmars-d
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

2014-08-22 Thread Kagamin via Digitalmars-d
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

2014-08-22 Thread Sönke Ludwig via Digitalmars-d

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

2014-08-22 Thread matovitch via Digitalmars-d
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

2014-08-22 Thread Sönke Ludwig via Digitalmars-d

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

2014-08-22 Thread matovitch via Digitalmars-d

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

2014-08-22 Thread Sönke Ludwig via Digitalmars-d

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?

2014-08-22 Thread MarisaLovesUsAll via Digitalmars-d

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

2014-08-22 Thread matovitch via Digitalmars-d

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?

2014-08-22 Thread Kagamin via Digitalmars-d
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?

2014-08-22 Thread Kagamin via Digitalmars-d

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?

2014-08-22 Thread MacAsm via Digitalmars-d
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

2014-08-22 Thread Dicebot via Digitalmars-d
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?

2014-08-22 Thread Dejan Lekic via Digitalmars-d

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

2014-08-22 Thread David Gileadi via Digitalmars-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

2014-08-22 Thread Ary Borenszweig via Digitalmars-d

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?

2014-08-22 Thread Kiith-Sa via Digitalmars-d

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?

2014-08-22 Thread MarisaLovesUsAll via Digitalmars-d

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

2014-08-22 Thread Jacob Carlborg via Digitalmars-d

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

2014-08-22 Thread Jacob Carlborg via Digitalmars-d

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

2014-08-22 Thread Gary Willoughby via Digitalmars-d

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

2014-08-22 Thread via Digitalmars-d

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

2014-08-22 Thread Sönke Ludwig via Digitalmars-d

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

2014-08-22 Thread Sönke Ludwig via Digitalmars-d

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

2014-08-22 Thread via Digitalmars-d

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

2014-08-22 Thread monarch_dodra via Digitalmars-d
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

2014-08-22 Thread Christian Manning via Digitalmars-d
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

2014-08-22 Thread Sönke Ludwig via Digitalmars-d

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

2014-08-22 Thread Sönke Ludwig via Digitalmars-d

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

2014-08-22 Thread Vladimir Panteleev via Digitalmars-d

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

2014-08-22 Thread Ary Borenszweig via Digitalmars-d

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

2014-08-22 Thread via Digitalmars-d

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

2014-08-22 Thread via Digitalmars-d

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

2014-08-22 Thread Sönke Ludwig via Digitalmars-d

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

2014-08-22 Thread Sönke Ludwig via Digitalmars-d

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

2014-08-22 Thread H. S. Teoh via Digitalmars-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

2014-08-22 Thread Brad Anderson via Digitalmars-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

2014-08-22 Thread via Digitalmars-d

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

2014-08-22 Thread Dicebot via Digitalmars-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

2014-08-22 Thread via Digitalmars-d

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

2014-08-22 Thread Adam D. Ruppe via Digitalmars-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

2014-08-22 Thread Walter Bright via Digitalmars-d

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

2014-08-22 Thread Sönke Ludwig via Digitalmars-d

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

2014-08-22 Thread H. S. Teoh via Digitalmars-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

2014-08-22 Thread H. S. Teoh via Digitalmars-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

2014-08-22 Thread Sönke Ludwig via Digitalmars-d

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

2014-08-22 Thread Vicente via Digitalmars-d

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

2014-08-22 Thread via Digitalmars-d

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

2014-08-22 Thread bearophile via Digitalmars-d
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

2014-08-22 Thread 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).



Re: Windows service in D

2014-08-22 Thread Tyler Jensen via Digitalmars-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

2014-08-22 Thread Sönke Ludwig via Digitalmars-d

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

2014-08-22 Thread Tyler Jensen via Digitalmars-d

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

2014-08-22 Thread Christian Manning via Digitalmars-d

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

2014-08-22 Thread Sönke Ludwig via Digitalmars-d

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

2014-08-22 Thread Vicente via Digitalmars-d

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

2014-08-22 Thread Wyatt via Digitalmars-d

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

2014-08-22 Thread John Colvin via Digitalmars-d

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

2014-08-22 Thread Brian Schott via Digitalmars-d

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

2014-08-22 Thread Christian Manning via Digitalmars-d
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

2014-08-22 Thread Vicente via Digitalmars-d

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

2014-08-22 Thread bearophile via Digitalmars-d

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

2014-08-22 Thread Sönke Ludwig via Digitalmars-d

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

2014-08-22 Thread Sönke Ludwig via Digitalmars-d

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

2014-08-22 Thread Timon Gehr via Digitalmars-d

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/


  1   2   3   >