www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What remains to be done for D2?

reply Petr Janda <janda.petr gmail.com> writes:
Hi,

Can someone please explain what needs to be done (other than fixing
the plethora of bugs) to call D2 final? And if someone can provide
an approximate estimate of when?

I would like to switch majority of my programming from C++ to D2 but
the number of bugs and uncertainty of how exactly will non-garbage
collected classes work makes me a bit cautious.(could someone please
explain too)

Also, how much slower is D2 compared to C++? Will D2 final have
comparable performance?

Thanks
Petr Janda
Jun 13 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Petr Janda" <janda.petr gmail.com> wrote in message 
news:it6npg$6l8$1 digitalmars.com...

 Also, how much slower is D2 compared to C++? Will D2 final have
 comparable performance?


D2 already has comparable performance to C++. And various things like 
built-in slices and good metaprogramming make it easier to write fast code:

http://dotnot.org/blog/archives/2008/03/10/xml-benchmarks-parsequerymutateserialize/
http://dotnot.org/blog/archives/2008/03/10/xml-benchmarks-updated-graphs-with-rapidxml/
http://dotnot.org/blog/archives/2008/03/12/why-is-dtango-so-fast-at-parsing-xml/

http://www.semitwist.com/articles/EfficientAndFlexible/SinglePage/
Jun 13 2011
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Petr Janda" <janda.petr gmail.com> wrote in message 
news:it6npg$6l8$1 digitalmars.com...

 Hi,

 Can someone please explain what needs to be done (other than fixing
 the plethora of bugs) to call D2 final? And if someone can provide
 an approximate estimate of when?


I already find D2, even with occasional bugs, to be *far* better than 
dealing with C++.

And no language is ever "final" unless it's a dead language. D2's already 
ready for production use IMO, and many people are already using it 
professionally.


 uncertainty of how exactly will non-garbage
 collected classes work makes me a bit cautious.(could someone please
 explain too)


Basically you can use either structs (which are not heap-allocated unless 
you specifically ask for them to be) or you use "emplace". For emplace, you 
allocate your own chunk of memory however you want, and then pass it to the 
emplace function in Phobos which will construct your object right there "in 
place" instead of allocating new GC'ed memory. Somebody else can explain the 
details better than I can, I've never actually used emplace myself.
Jun 13 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 14.06.2011 07:24, schrieb Nick Sabalausky:

 "Petr Janda" <janda.petr gmail.com> wrote in message 
 news:it6npg$6l8$1 digitalmars.com...

 Hi,

 Can someone please explain what needs to be done (other than fixing
 the plethora of bugs) to call D2 final? And if someone can provide
 an approximate estimate of when?


 
 I already find D2, even with occasional bugs, to be *far* better than 
 dealing with C++.
 
 And no language is ever "final" unless it's a dead language. D2's already 
 ready for production use IMO, and many people are already using it 
 professionally.
 

 uncertainty of how exactly will non-garbage
 collected classes work makes me a bit cautious.(could someone please
 explain too)


 
 Basically you can use either structs (which are not heap-allocated unless 
 you specifically ask for them to be) or you use "emplace". For emplace, you 
 allocate your own chunk of memory however you want, and then pass it to the 
 emplace function in Phobos which will construct your object right there "in 
 place" instead of allocating new GC'ed memory. Somebody else can explain the 
 details better than I can, I've never actually used emplace myself.
 


Example of an custom (de)allocator for class-objects (using C
malloc/free and emplace()): http://pastebin.com/9Qgf3vc7

Cheers,
- Daniel
Jun 13 2011
parent reply Petr Janda <janda.petr gmail.com> writes:
I see. Thank you.

I do have a couple of questions about myNew and myDelete though.

T ret = emplace!(T, Args)(objMem, args);
return ret; // return new custom allocated Object

So emplace runs the constructor of T.

1) Does emplace return a copy of T?
2) Is Object "ret"  constructed as a copy(via copy constructor) of
what emplace returns?
3) Is there some kind of internal reference counting/smart pointer
happening that I can't see?

And about myDelete:

core.stdc.stdlib.free(cast(void*)obj);

Casting object to a pointer to a heap allocated memory? That's neat!
Jun 13 2011
parent Daniel Gibson <metalcaedes gmail.com> writes:
Am 14.06.2011 08:55, schrieb Petr Janda:

 I see. Thank you.
 
 I do have a couple of questions about myNew and myDelete though.
 
 T ret = emplace!(T, Args)(objMem, args);
 return ret; // return new custom allocated Object
 
 So emplace runs the constructor of T.
 
 1) Does emplace return a copy of T?


T is a class, not an object, so it can't return "a copy".
What emplace does is that it creates an object in the given memory
(objMem[] in my example), i.e. it initializes the memory and runs the
given constructor on it - just like new does with memory from the heap
that it allocates itself.
See also http://d-programming-language.org/phobos/std_conv.html#emplace
for a description of emplace (I used the "T em­place(T, Args...)(void[]
chunk, Args args);" version).


 2) Is Object "ret"  constructed as a copy(via copy constructor) of
 what emplace returns?
 3) Is there some kind of internal reference counting/smart pointer
 happening that I can't see?


No, not at all. My example just gets memory from the C heap (via
malloc()), "makes it an object" with emplace (this means, it will
contain all data an object created by new would contain) and returns
that object.
Just like in C++ you have to delete it (with myDelete) to prevent memory
leaks.
You could of course implement reference counting yourself, maybe with a
custom class and a custom myNew that creates objects of that class and
initializes the reference counter or something.


 
 And about myDelete:
 
 core.stdc.stdlib.free(cast(void*)obj);
 
 Casting object to a pointer to a heap allocated memory? That's neat!


malloc() returned a void pointer (that was casted to void[] and then
made an object with emplace). By casting the Object to void* we get a
pointer pointing with the same value as the one returned by malloc()
before, so we can call free() on it.
But before that, clear() is used, so the Object's destructor is called.

Also note that malloc() and free() were just examples, you could also
use chunks of memory obtained by other means (like mmap) with emplace.

Cheers,
- Daniel
Jun 14 2011
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
Petr Janda wrote:

 Hi,
 
 Can someone please explain what needs to be done (other than fixing
 the plethora of bugs) to call D2 final? And if someone can provide
 an approximate estimate of when?


There are a couple of areas of major missing functionality:
* CTFE should support pointers (upcoming release 2.054) and classes (2.055).
* alias this, inout, safe aren't fully implemented, and will probably 
require language changes/clarifications.
* Built-in struct functions (opEquals, toString, etc) need more thought.
* I suspect that we'll see changes to the modifiers for function 
parameters (in, out, inout, ref, auto ref)

At the current rate of progress I estimate we are about six months from 
having the language implemented (but still with bugs).
But there will still be bugs which can only be fixed by making small 
changes to the language spec.

Phobos is quite a bit further away from being "final".

With regard to bugs: the last release fixed more than half of the most 
important and difficult structural bugs remaining in the compiler, 
including some which had been deferred for years. There are a huge 
number of open bugs, of course, but we are on a downhill run now.


 I would like to switch majority of my programming from C++ to D2 but
 the number of bugs and uncertainty of how exactly will non-garbage
 collected classes work makes me a bit cautious.(could someone please
 explain too)
 
 Also, how much slower is D2 compared to C++? Will D2 final have
 comparable performance?
 
 Thanks
 Petr Janda
Jun 14 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-06-14 02:07, Don wrote:

 Petr Janda wrote:

 Hi,
 
 Can someone please explain what needs to be done (other than fixing
 the plethora of bugs) to call D2 final? And if someone can provide
 an approximate estimate of when?


 
 There are a couple of areas of major missing functionality:
 * CTFE should support pointers (upcoming release 2.054) and classes
 (2.055). * alias this, inout, safe aren't fully implemented, and will
 probably require language changes/clarifications.
 * Built-in struct functions (opEquals, toString, etc) need more thought.
 * I suspect that we'll see changes to the modifiers for function
 parameters (in, out, inout, ref, auto ref)
 
 At the current rate of progress I estimate we are about six months from
 having the language implemented (but still with bugs).
 But there will still be bugs which can only be fixed by making small
 changes to the language spec.
 
 Phobos is quite a bit further away from being "final".
 
 With regard to bugs: the last release fixed more than half of the most
 important and difficult structural bugs remaining in the compiler,
 including some which had been deferred for years. There are a huge
 number of open bugs, of course, but we are on a downhill run now.


Yeah. It's been pretty amazing how much the speed of compiler development has 
picked up since we've moved to github. The situation with Phobos has been 
improving as well between the move to github and having new modules reviewed 
in the newsgroup, but it hasn't been improving at anywhere near the rate that 
the compiler has been - though there are certain classes of issues which 
require that the compiler be improved before they can be fixed in Phobos (such 
as adding some sort of conditional attributes to allow for pure,  safe, and 
nothrow on templated functions whose ability to have those attributes depends 
on the arguments that they're instantiated with). I do think that it's only 
natural that Phobos would be a bit behind the language itself since it has to 
use the language to do whatever it does, but we could definitely use more help 
developing Phobos - be it fixing bugs, implementing new features, or simply 
reviewing pull requests on github.

- Jonathan M Davis
Jun 14 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/14/11 4:07 AM, Don wrote:

 Petr Janda wrote:

 Hi,

 Can someone please explain what needs to be done (other than fixing
 the plethora of bugs) to call D2 final? And if someone can provide
 an approximate estimate of when?


 There are a couple of areas of major missing functionality:
 * CTFE should support pointers (upcoming release 2.054) and classes
 (2.055).
 * alias this, inout, safe aren't fully implemented, and will probably
 require language changes/clarifications.
 * Built-in struct functions (opEquals, toString, etc) need more thought.
 * I suspect that we'll see changes to the modifiers for function
 parameters (in, out, inout, ref, auto ref)


* Work last kinks out of qualified constructors and destructors
* Low-level threading support with shared; change language to match TDPL 
(that means e.g. shared/synchronized methods is at class level, not 
method level).
* Minor touches such as user-defined operator '$',  disable etc.

Work that is not quintessential for using D but very important:

* Finish typechecking for SafeD
* Make SafeD == CompileTimeD

We should put this list somewhere.


 At the current rate of progress I estimate we are about six months from
 having the language implemented (but still with bugs).
 But there will still be bugs which can only be fixed by making small
 changes to the language spec.

 Phobos is quite a bit further away from being "final".


* Define allocator abstraction
* Overhaul std.container to use it; add classic containers to 
std.container (doubly-linked list, hash, deque)
* Define streaming abstraction (already in my head)
* Add high-level networking (Jonas, where art thou?)
* Redo xml (Tomek)
* Many other changes and additions


Andrei
Jun 14 2011
next sibling parent Don <nospam nospam.com> writes:
Andrei Alexandrescu wrote:

 On 6/14/11 4:07 AM, Don wrote:

 Petr Janda wrote:

 Hi,

 Can someone please explain what needs to be done (other than fixing
 the plethora of bugs) to call D2 final? And if someone can provide
 an approximate estimate of when?


 There are a couple of areas of major missing functionality:
 * CTFE should support pointers (upcoming release 2.054) and classes
 (2.055).
 * alias this, inout, safe aren't fully implemented, and will probably
 require language changes/clarifications.
 * Built-in struct functions (opEquals, toString, etc) need more thought.
 * I suspect that we'll see changes to the modifiers for function
 parameters (in, out, inout, ref, auto ref)


 
 * Work last kinks out of qualified constructors and destructors
 * Low-level threading support with shared; change language to match TDPL 
 (that means e.g. shared/synchronized methods is at class level, not 
 method level).
 * Minor touches such as user-defined operator '$',  disable etc.
 
 Work that is not quintessential for using D but very important:
 
 * Finish typechecking for SafeD
 * Make SafeD == CompileTimeD
 
 We should put this list somewhere.
 

 At the current rate of progress I estimate we are about six months from
 having the language implemented (but still with bugs).
 But there will still be bugs which can only be fixed by making small
 changes to the language spec.

 Phobos is quite a bit further away from being "final".


 
 * Define allocator abstraction
 * Overhaul std.container to use it; add classic containers to 
 std.container (doubly-linked list, hash, deque)
 * Define streaming abstraction (already in my head)
 * Add high-level networking (Jonas, where art thou?)
 * Redo xml (Tomek)
 * Many other changes and additions
 
 
 Andrei


Added to the existing roadmap at:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel
Jun 14 2011
prev sibling next sibling parent reply Petr Janda <janda.petr gmail.com> writes:
 Overhaul std.container to use it; add classic containers to




std.container (doubly-linked list, hash, deque)

Hi Andrei,

I think it would be fantastic if D could have most, if not all of
the C++ containers, so that D also has containers that do not rely
on garbage collection. I believe I read somewhere that D arrays rely
on the GC which may not be desirable in certain situations (OS
programming etc).

Can you let me know what you think as you are seemingly the chief
Phobos developer.

Thank you,
Petr Janda
Jun 14 2011
next sibling parent Mafi <mafi example.org> writes:
Am 15.06.2011 02:12, schrieb Petr Janda:

 Overhaul std.container to use it; add classic containers to




 std.container (doubly-linked list, hash, deque)

 Hi Andrei,

 I think it would be fantastic if D could have most, if not all of
 the C++ containers, so that D also has containers that do not rely
 on garbage collection. I believe I read somewhere that D arrays rely
 on the GC which may not be desirable in certain situations (OS
 programming etc).

 Can you let me know what you think as you are seemingly the chief
 Phobos developer.

 Thank you,
 Petr Janda


The core of D's arrays don't rely on an GC. You can malloc, slice the 
pointer and free it again.
Only concatening and appending use the GC, everything else should work 
without a GC.

Mafi
Jun 15 2011
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/14/11 7:12 PM, Petr Janda wrote:

 Overhaul std.container to use it; add classic containers to




 std.container (doubly-linked list, hash, deque)

 Hi Andrei,

 I think it would be fantastic if D could have most, if not all of
 the C++ containers, so that D also has containers that do not rely
 on garbage collection. I believe I read somewhere that D arrays rely
 on the GC which may not be desirable in certain situations (OS
 programming etc).


I'm currently trying to figure out a design that offers the following:

* several allocation schemes (GC, refcounting, malloc, regions, reaps, 
tempalloc)

* two approaches to safety (safe vs. unsafe); sealing can make use of 
malloc safe.

* how to distribute responsibility of the above between containers and 
what I call "storage models" (which are akin to STL allocators).


Andrei
Jun 15 2011
prev sibling parent reply jdrewsen <jdrewsen nospam.com> writes:
Den 14-06-2011 15:17, Andrei Alexandrescu skrev:

 On 6/14/11 4:07 AM, Don wrote:

 Petr Janda wrote:

 Hi,

 Can someone please explain what needs to be done (other than fixing
 the plethora of bugs) to call D2 final? And if someone can provide
 an approximate estimate of when?


 There are a couple of areas of major missing functionality:
 * CTFE should support pointers (upcoming release 2.054) and classes
 (2.055).
 * alias this, inout, safe aren't fully implemented, and will probably
 require language changes/clarifications.
 * Built-in struct functions (opEquals, toString, etc) need more thought.
 * I suspect that we'll see changes to the modifiers for function
 parameters (in, out, inout, ref, auto ref)


 * Work last kinks out of qualified constructors and destructors
 * Low-level threading support with shared; change language to match TDPL
 (that means e.g. shared/synchronized methods is at class level, not
 method level).
 * Minor touches such as user-defined operator '$',  disable etc.

 Work that is not quintessential for using D but very important:

 * Finish typechecking for SafeD
 * Make SafeD == CompileTimeD

 We should put this list somewhere.


 At the current rate of progress I estimate we are about six months from
 having the language implemented (but still with bugs).
 But there will still be bugs which can only be fixed by making small
 changes to the language spec.

 Phobos is quite a bit further away from being "final".


 * Define allocator abstraction
 * Overhaul std.container to use it; add classic containers to
 std.container (doubly-linked list, hash, deque)
 * Define streaming abstraction (already in my head)
 * Add high-level networking (Jonas, where art thou?)


Finishing off some major changes to the curl wrapper. I'm posting a RFC 
on the updated code in a sec.


 * Redo xml (Tomek)
 * Many other changes and additions


 Andrei
Jun 18 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 06/18/2011 03:23 PM, jdrewsen wrote:

 Finishing off some major changes to the curl wrapper. I'm posting a RFC
 on the updated code in a sec.


Can't wait, thanks for doing this work!

I wonder whether we can distribute the libcurl libraries on Windows.


Andrei
Jun 18 2011
parent Brad Anderson <eco gnuk.net> writes:
This seems to be a good roundup of all issues involved with distributing
libcurl.

http://curl.haxx.se/legal/licmix.html

TL;DR Yes, you can include a libcurl binary but a lot care needs to be taken
with the other libraries libcurl can use.

On Sat, Jun 18, 2011 at 2:32 PM, Andrei Alexandrescu <
SeeWebsiteForEmail erdani.org> wrote:


 On 06/18/2011 03:23 PM, jdrewsen wrote:


 Finishing off some major changes to the curl wrapper. I'm posting a RFC
 on the updated code in a sec.


 Can't wait, thanks for doing this work!

 I wonder whether we can distribute the libcurl libraries on Windows.


 Andrei
Jun 19 2011
prev sibling parent reply Kagamin <spam here.lot> writes:
Petr Janda Wrote:


 I think it would be fantastic if D could have most, if not all of
 the C++ containers, so that D also has containers that do not rely
 on garbage collection. I believe I read somewhere that D arrays rely
 on the GC which may not be desirable in certain situations (OS
 programming etc).


For OS programming you'll definitely need another infrastructure, not existing
druntime/phobos/dmd.
Jun 15 2011
parent Kagamin <spam here.lot> writes:
Kagamin Wrote:


 Petr Janda Wrote:
 

 I think it would be fantastic if D could have most, if not all of
 the C++ containers, so that D also has containers that do not rely
 on garbage collection. I believe I read somewhere that D arrays rely
 on the GC which may not be desirable in certain situations (OS
 programming etc).


 
 For OS programming you'll definitely need another infrastructure, not existing
druntime/phobos/dmd.


http://d.puremagic.com/issues/show_bug.cgi?id=5219
Jun 15 2011