Re: D 2.066 is out. Enjoy!
"Jonathan M Davis" wrote in message news:fxdqpmfcbskvtcafz...@forum.dlang.org... LOL. Yeah, well, it would be ni going to support C+ce if we could get an actual list of the C++ features that D currently supports somewhere (and how to use them if it's not obvious). You've been doing so much great work on that that I have no clue what the current state of things is. For instance, this is the first I've heard of anything about template support; I'd thought that we were never going to support templates. Is it just for name mangling or for actually compiling them? Templates are sort-of supported. The main motivation was to allow dmd's Array type to be used in function signatures. This is nice, because it only requires correct name mangling, you don't need to worry about instantiation. Being able to call templated free functions and call methods on templated types will require each referenced template to be explicitly instantiated on the C++ side. I don't think it's realistic for D to do this automatically, although it is possible to do things like generate a non-templated forwarding wrapper function for each instantiation. In DDMD, this is worked around by array.d containing a functionally-equivalent translation of array.h. The D code all ends up calling the D version, and the two must be kept exactly in sync. This approach is probably feasible for accessing stl types and other common, rarely changing C++ templates. There are two reason it's not better documented: 1. I hate writing documentation. I really really hate it. 2. These features are rather difficult to use, and I don't want people to think they can just plug-and-play. I've spent a lot of time fighting compiler alignment bugs, which are their own special kind of hell. Many of those issues have been resolved now, but only in the areas that ddmd actually exercises.
Re: D 2.066 is out. Enjoy!
"Walter Bright" wrote in message news:lt5l3k$2s5t$1...@digitalmars.com... The thing is, while the code was there, there wasn't a single test case for it in the test suite. Furthermore, at least for Elf, there was no support for the special mangling done for ::std:: stuff. Yeah, I don't know what happened to the test cases for template mangling. They were certainly tested when the new manger was being introduced, but somehow disappeared. There was no special std mangling because at the time C++ mangling was updated, there were no C++ namespaces in D. The thing is, modern C++ practice makes heavy use of std types. Having an interface to C++ code is fairly unusable unless D can also interface to std::string, std::vector, and a few others. The first step is to support the mangling of them. Then, try to construct a "workalike" on the D side that follows D rules, and yet is able to seamlessly interact with the corresponding C++ code. We'll see how far we can get with that, and then evaluate what to do next. It works for ddmd's array.d/array.h at least, although it's not very maintenance friendly. I assume you're aiming for something like a 'core.stdcpp.vector' with an implementation to match each stl implementation?
Re: D 2.066 is out. Enjoy!
On Thursday, 21 August 2014 at 20:49:48 UTC, bachmeier wrote: It would be nice to have a page to link to when questions come up on Reddit about compatibility with C++. We have this: http://dlang.org/cpp_interface.html From what I understand, it's not complete. For example it says that non-virtual and static member functions cannot be accesses, but that's not the case anymore, AFAIR. And the section about templates also says that there's no support. That page should also have information about avoiding the garbage collector and the status of GC removal from the standard library. This information is currently spread over several articles with a different focus each, and not up to date either: http://dlang.org/garbage.html http://wiki.dlang.org/Instantiating_Class_Objects_Elsewhere_Than_the_GC_Heap http://wiki.dlang.org/Memory_Management http://wiki.dlang.org/Versus_the_garbage_collector I don't think we should treat both topics on the same page, they're mostly unrelated (though people coming from C++ might be interested in both, of course).
Re: D 2.066 is out. Enjoy!
On Monday, 18 August 2014 at 19:00:23 UTC, Andrei Alexandrescu wrote: Congratulations to everyone involved! http://www.reddit.com/r/programming/comments/2dwqvy/d_2066_nogc_c_namespaces_multidimensional_slices/ https://www.facebook.com/dlang.org/posts/905593426121006 https://twitter.com/D_Programming/status/501443132115140609 Andrei Main dlang.org page still shows that 2.066 is in beta phase. Merge the https://github.com/D-Programming-Language/dlang.org/pull/638 to fix.
Re: D 2.066 is out. Enjoy!
On Friday, 22 August 2014 at 08:23:16 UTC, Marc Schütz wrote: On Thursday, 21 August 2014 at 20:49:48 UTC, bachmeier wrote: It would be nice to have a page to link to when questions come up on Reddit about compatibility with C++. We have this: http://dlang.org/cpp_interface.html From what I understand, it's not complete. For example it says that non-virtual and static member functions cannot be accesses, but that's not the case anymore, AFAIR. And the section about templates also says that there's no support. That's the problem. We don't want to link to a page that's not accurate when replying to comments on Reddit. That page should also have information about avoiding the garbage collector and the status of GC removal from the standard library. This information is currently spread over several articles with a different focus each, and not up to date either: http://dlang.org/garbage.html http://wiki.dlang.org/Instantiating_Class_Objects_Elsewhere_Than_the_GC_Heap http://wiki.dlang.org/Memory_Management http://wiki.dlang.org/Versus_the_garbage_collector I don't think we should treat both topics on the same page, they're mostly unrelated (though people coming from C++ might be interested in both, of course). Maybe it wouldn't have to go on the same page, but at least links to all the information should appear on the same page. The current system with everything scattered here and there makes for a bad first impression.
Re: D 2.066 is out. Enjoy!
On 8/22/14, 2:06 AM, Dejan Lekic wrote: On Monday, 18 August 2014 at 19:00:23 UTC, Andrei Alexandrescu wrote: Congratulations to everyone involved! http://www.reddit.com/r/programming/comments/2dwqvy/d_2066_nogc_c_namespaces_multidimensional_slices/ https://www.facebook.com/dlang.org/posts/905593426121006 https://twitter.com/D_Programming/status/501443132115140609 Andrei Main dlang.org page still shows that 2.066 is in beta phase. Merge the https://github.com/D-Programming-Language/dlang.org/pull/638 to fix. Pushed, thanks Dejan. -- Andrei
Re: Fix #2529: explicit protection package #3651
On Tuesday, 19 August 2014 at 17:08:25 UTC, Walter Bright wrote: On 8/19/2014 7:01 AM, Dicebot wrote: > Walter, now that release is out can you please state your opinion about > https://github.com/D-Programming-Language/dmd/pull/3651 ? It is blocking Phobos > module split and decoupling. I keep thinking there's gotta be a way to do this without language changes. For what it's worth I don't care how things turn out w.r.t. syntax, language extension or convention but the problem must be solved. The way I see the problem: There must be nice and clean way to have internal stuff that is invisible for user. Preferably this stuff must not be monolithic and have form of package. Example structure: mod/package.d mod/internal/bar.d mod/... I actually face it in Phobos right now, my blocked pull: https://github.com/D-Programming-Language/phobos/pull/2412 Options: 1. Use current package attribute. Disadvantages: a) Must retain internals in the same package, user may still import them no problem at all. At least it does not do much harm as nothing is accessible. b) Can't use std.mod.internal.bar 'package' stuff in std.mod (upper one). That makes it next to unusable. Basically it means we have to push internals up, instead of pushing them down. 2. Use separate public internal package. Main disadvantage: a) Now user may import and actually USE internal stuff. b) Not only that but also internal methods of equally internal structs and classes leak out. In other words: a struct defined in internal module may never be exposed without some kind of wrapping. Ugly and unnecessary complication. I'd rather have a language feature, but whatever you guys invent as 3rd option that doesn't suck will have my vote. --- Dmitry Olshansky
Re: D 2.066 is out. Enjoy!
On 8/22/2014 1:23 AM, Daniel Murphy wrote: "Walter Bright" wrote in message news:lt5l3k$2s5t$1...@digitalmars.com... The thing is, while the code was there, there wasn't a single test case for it in the test suite. Furthermore, at least for Elf, there was no support for the special mangling done for ::std:: stuff. Yeah, I don't know what happened to the test cases for template mangling. They were certainly tested when the new manger was being introduced, but somehow disappeared. Yeah, that can happen. There was no special std mangling because at the time C++ mangling was updated, there were no C++ namespaces in D. Makes sense. I assume you're aiming for something like a 'core.stdcpp.vector' with an implementation to match each stl implementation? Yes. While it'll be a significant effort to do this, it could be a big win for us.
Re: D 2.066 is out. Enjoy!
On Friday, 22 August 2014 at 14:36:13 UTC, Andrei Alexandrescu wrote: On 8/22/14, 2:06 AM, Dejan Lekic wrote: On Monday, 18 August 2014 at 19:00:23 UTC, Andrei Alexandrescu wrote: Congratulations to everyone involved! http://www.reddit.com/r/programming/comments/2dwqvy/d_2066_nogc_c_namespaces_multidimensional_slices/ https://www.facebook.com/dlang.org/posts/905593426121006 https://twitter.com/D_Programming/status/501443132115140609 Andrei Main dlang.org page still shows that 2.066 is in beta phase. Merge the https://github.com/D-Programming-Language/dlang.org/pull/638 to fix. Pushed, thanks Dejan. -- Andrei As I'm sure has been mentioned elsewhere, the website changes should be part of the release process, not an afterthought.
Re: D 2.066 is out. Enjoy!
On 8/22/2014 1:18 AM, Daniel Murphy wrote: There are two reason it's not better documented: 1. I hate writing documentation. I really really hate it. Join the club :-) 2. These features are rather difficult to use, and I don't want people to think they can just plug-and-play. I've spent a lot of time fighting compiler alignment bugs, which are their own special kind of hell. Many of those issues have been resolved now, but only in the areas that ddmd actually exercises. Sorry you got to be the pioneer with the arrows in your back, but you've paved the way for the rest of us.
Re: D 2.066 is out. Enjoy!
On 8/22/14, 10:04 AM, Walter Bright wrote: On 8/22/2014 1:23 AM, Daniel Murphy wrote: I assume you're aiming for something like a 'core.stdcpp.vector' with an implementation to match each stl implementation? Yes. While it'll be a significant effort to do this, it could be a big win for us. This is top priority for D. Above top if possible. -- Andrei
Re: D 2.066 is out. Enjoy!
On 8/22/14, 10:05 AM, John Colvin wrote: As I'm sure has been mentioned elsewhere, the website changes should be part of the release process, not an afterthought. Agreed. Who would like to volunteer being our webmaster? We'll discuss with our admin to give push rights. -- Andrei
Re: D 2.066 is out. Enjoy!
On Friday, 22 August 2014 at 17:06:31 UTC, Walter Bright wrote: On 8/22/2014 1:18 AM, Daniel Murphy wrote: There are two reason it's not better documented: 1. I hate writing documentation. I really really hate it. Join the club :-) 2. These features are rather difficult to use, and I don't want people to think they can just plug-and-play. I've spent a lot of time fighting compiler alignment bugs, which are their own special kind of hell. Many of those issues have been resolved now, but only in the areas that ddmd actually exercises. Sorry you got to be the pioneer with the arrows in your back, but you've paved the way for the rest of us. LOL! That's a hilarious comment! :)
Re: D 2.066 is out. Enjoy!
On 8/22/2014 11:33 AM, Andrei Alexandrescu via Digitalmars-d-announce wrote: On 8/22/14, 10:05 AM, John Colvin wrote: As I'm sure has been mentioned elsewhere, the website changes should be part of the release process, not an afterthought. Agreed. Who would like to volunteer being our webmaster? We'll discuss with our admin to give push rights. -- Andrei cronjob that does a git pull, and then everyone with pull permissions can keep the website updated.
Re: Classes to build a Windows service.
On Friday, 26 October 2007 at 18:47:43 UTC, Steve Teale wrote: Christoph Singewald Wrote: Hi! Did you put your classes somewhere, I'm interested how you build the service. At the moment I had no luck. tnx christoph Steve Teale Wrote: > BCS Wrote: > > > Reply to Steve, > > > > > I've built a set of classes: > > > > > > EventLogger > > > TinyXML > > > PropertyFile > > > ServiceBase > > > ServiceImplementation > > > BeepService (example) > > > Any suggestions (preferably positive) as to what I > > > should do with > > > them? > > > > > > > If you are looking for some place to host them and can't > > find a better place you can put them in scrapple. > > > > http://www.dsource.org/projects/scrapple/ > > > > just send me a dsource user name and I'll let you in > > > > > That seems sensible to start with. What should I actually > do? The stuff is at www.britseyeview.com/D/. It may be a little out of date with respect to Walter's current versions, since I have just moved to Tanzania, and it's taken me some time to get an Internet connection that is useful. Steve, I believe an early version of your code made it's way to me and this is what I ended up with after a fix to the Win32 bindings for x64. https://github.com/duovia/WindowsServiceInD I'm using the Windows API library (source actually) on dsource.org. See link on the github page. I found it difficult to find a complete solution to the problem, so I'm going to cross post in a few places to make it easier to find for others seeking an answer to the same question.
Re: Fix #2529: explicit protection package #3651
All I want is that whatever decision Walter makes to happen sooner than in few years from now.
Re: D 2.066 is out. Enjoy!
On Friday, 22 August 2014 at 08:18:18 UTC, Daniel Murphy wrote: 2. These features are rather difficult to use, and I don't want people to think they can just plug-and-play. I've spent a lot of time fighting compiler alignment bugs, which are their own special kind of hell. Many of those issues have been resolved now, but only in the areas that ddmd actually exercises. Do you suggest that C++ interfaces should be written by the compiler team?
Re: Fix #2529: explicit protection package #3651
Dicebot: All I want is that whatever decision Walter makes to happen sooner than in few years from now. There are other pending patches, like the support for the nice [$] syntax by Kenji. "I keep thinking there's gotta be a way to do this without language changes." or "I keep thinking there must be a better way than [$]." are the kind of standard answers Walter gives when he doesn't have time to think about some design (because he has time he usually needs only hours or very few days to implement features, like when he made UDAs or C++ namespeces). So I guess Walter is currently busy with something (like finishing the 2.066 release and its regressions, or developing Warp for Facebook, or something else), so you have to wait some time for him to come back to the language development side, to receive a good answer and a good solution. Bye, bearophile
Re: D 2.066 is out. Enjoy!
On 8/23/14, 3:33 AM, Andrei Alexandrescu wrote: On 8/22/14, 10:05 AM, John Colvin wrote: As I'm sure has been mentioned elsewhere, the website changes should be part of the release process, not an afterthought. Agreed. Who would like to volunteer being our webmaster? We'll discuss with our admin to give push rights. -- Andrei As I mentioned in an earlier post in this thread, I need access. I did the update for every beta/RC. This one was not an oversight, I intentionally did not update the page. Given the right to push the update, I will, But I'm not going to sit around creating pull requests for one a line delete or one character edit and the wait 24hour+ for it to be published before I can proceed with what I'm doing. Then again, if that's required is a cronjob as Brad has suggested, then I guess the problem is solved.
Re: D 2.066 new behavior
On Friday, 22 August 2014 at 02:26:38 UTC, safety0ff wrote: On Friday, 22 August 2014 at 01:54:55 UTC, Paul D Anderson wrote: Is this expected behavior that has never been enforced before, or is it something new? And is anyone else having the same problem? Paul Looks like a regression, I've filed it here: https://issues.dlang.org/show_bug.cgi?id=13351 Seems to be a duplicate of bug 13294: https://issues.dlang.org/show_bug.cgi?id=13294
Re: Fix #2529: explicit protection package #3651
On Fri, 22 Aug 2014 20:48:22 + bearophile via Digitalmars-d-announce wrote: or (smart plan!) just apply the necessary PRs, build dmd from sources and start using the features. if authors of popular libraries will do this, there will be no choice and maintainers will be forced to apply this patches. this is called 'driven by the community'. ;-) ok-ok-ok, you got me, this was a silly joke! or maybe not?.. signature.asc Description: PGP signature
Re: Fix #2529: explicit protection package #3651
On Sat, 23 Aug 2014 04:50:36 +0300 ketmar via Digitalmars-d-announce 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
Re: D for the Win
On Thursday, 21 August 2014 at 12:08:06 UTC, Dicebot wrote: On Thursday, 21 August 2014 at 12:05:40 UTC, ketmar via Digitalmars-d-announce wrote: ... Please, this is not important enough to argue here. And fairly common. The French one propose to use foreigner's blood to water the fields.
Re: D 2.066 is out. Enjoy!
"Walter Bright" wrote in message news:lt7tan$24ei$1...@digitalmars.com... > 1. I hate writing documentation. I really really hate it. Join the club :-) =) Sorry you got to be the pioneer with the arrows in your back, but you've paved the way for the rest of us. I don't really mind, for some reason I enjoy tracking down wrong-code bugs. I just don't want everyone to think it'll be easy to plug in their favourite C++ library.
