Re: What remains to be done for D2?
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 seewebsiteforem...@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
Re: What remains to be done for D2?
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
Re: What remains to be done for D2?
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
Re: What remains to be done for D2?
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
Re: What remains to be done for D2?
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.
Re: What remains to be done for D2?
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
Re: What remains to be done for D2?
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
Re: What remains to be done for D2?
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!
Re: What remains to be done for D2?
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 emplace(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
Re: What remains to be done for D2?
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
Re: What remains to be done for D2?
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
Re: What remains to be done for D2?
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
Re: What remains to be done for D2?
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
What remains to be done for D2?
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
Re: What remains to be done for D2?
Petr Janda janda.p...@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/
Re: What remains to be done for D2?
Petr Janda janda.p...@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.
Re: What remains to be done for D2?
Am 14.06.2011 07:24, schrieb Nick Sabalausky: Petr Janda janda.p...@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
