Re: core.stdcpp
On 8/26/2014 5:32 PM, Mike wrote: We currently have std.c and core.stdc. I believe core.stdc should be migrated to std.c, not the other way around. And before we make the same mistake with core.stdcpp, we should set a new precedent with std.cpp instead. The irony is D1 has std.c, and for D2 it was migrated to core.stdc. Moving it back in an endless search for taxonomical perfection just jerks the users around. We've done a lot of renaming in the runtime library, and an awful lot of ink has been spilled on the subject in these forums. But I'm not aware of a single user gained by these changes, and I suspect we've lost a few, not because they didn't like the newer names, but because they disliked the constant disruption of their code base.
Re: "Programming in D" book, "User Defined Attributes (UDA)" chapter
On Tue, 26 Aug 2014 23:16:14 -0700 Ali Çehreli via Digitalmars-d-announce wrote: > * Formatted element output with %( and %) by the way, i never knows about this feature. maybe i should RTFM someday... signature.asc Description: PGP signature
Re: "Programming in D" book, "User Defined Attributes (UDA)" chapter
On Tue, 26 Aug 2014 23:16:14 -0700 Ali Çehreli via Digitalmars-d-announce wrote: > * The 'User Defined Attributes (UDA)' chapter great! > * static this, static ~this, shared static this, and shared static > ~this and this too. signature.asc Description: PGP signature
"Programming in D" book, "User Defined Attributes (UDA)" chapter
I made some additions and corrections. The following are the major ones: * The 'User Defined Attributes (UDA)' chapter * @nogc * foreach_reverse * Formatted element output with %( and %) * static this, static ~this, shared static this, and shared static ~this As a reminder, the book is available as PDF, downloadable from the header of each chapter: http://ddili.org/ders/d.en/index.html Ali
Re: core.stdcpp
On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote: On Tuesday, 26 August 2014 at 18:28:38 UTC, Andrei Alexandrescu wrote: No. We currently have std.c and core.stdc. Let's not even say this is confusing.
Re: core.stdcpp
On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote: I'm asking this community to consider setting a new precedent for druntime: reduce the scope to just the language implementation, encapsulate and isolate the platform specific logic (e.g. the ports - see 11666), and deport the artificial dependencies to phobos or other libraries. Please understand that I'm not suggesting we start refactoring druntime for 2.067. All I'm asking for is that we recognize that C/C++ library and OS bindings don't belong in druntime as public modules, and we gradually work towards migrating them to phobos or some other library in the years to come. Since C++ language bindings are a new addition, let's not exacerbate the problem by putting it in druntime as core.stdcpp, but set a new precedent by putting them in std.cpp (or core.stdcpp in phobos, or whatever else you have in mind). Mike
Re: core.stdcpp
On Wednesday, 27 August 2014 at 01:21:59 UTC, deadalnix wrote: I think this cannot be understated. People have existing codebase that they aren't going to rewrite from scratch. PS: This is the reason why SDC unwind C++'s exception properly (but you obviously can't catch them).
Re: core.stdcpp
On Wednesday, 27 August 2014 at 01:57:38 UTC, Mike wrote: What do you think about following compromise: 1) C bindings are defined in spec to be optional 2) They are still kept in druntime repo but declared an implementation detail 3) C bindings are defined to be mandatory in Phobos - if Phobos is used with druntime that does not provide C bindings, it must expose ones of its own. It effectively keeps existing layout but moves from a specification to implementation detail making binding-free druntime 100% legal D implementation. By "C bindings" do you really mean "C/C++ bindings" given the context of this thread? Yeah, "any external / OS bindings" is probably more appropriate wording.
Re: core.stdcpp
On Wednesday, 27 August 2014 at 01:05:19 UTC, Dicebot wrote: On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote: I believe druntime's scope should be reduced to simply implementing the language, not creating an OS or library API. That's what phobos and DUB are for. I'm asking this community to consider setting a new precedent for druntime: reduce the scope to just the language implementation, encapsulate and isolate the platform specific logic (e.g. the ports - see 11666), and deport the artificial dependencies to phobos or other libraries. What do you think about following compromise: 1) C bindings are defined in spec to be optional 2) They are still kept in druntime repo but declared an implementation detail 3) C bindings are defined to be mandatory in Phobos - if Phobos is used with druntime that does not provide C bindings, it must expose ones of its own. It effectively keeps existing layout but moves from a specification to implementation detail making binding-free druntime 100% legal D implementation. By "C bindings" do you really mean "C/C++ bindings" given the context of this thread?
Re: core.stdcpp
On Tuesday, 26 August 2014 at 14:48:48 UTC, Andrei Alexandrescu wrote: On 8/26/14, 3:06 AM, Mike wrote: D has a lot of potential beyond it's current use. Please take this opportunity to reflect on what's been done, take a look ahead, and see if we can set a better precedent for the future. C++ interoperability is very important for D's future. -- Andrei I think this cannot be understated. People have existing codebase that they aren't going to rewrite from scratch.
Re: core.stdcpp
On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote: I believe druntime's scope should be reduced to simply implementing the language, not creating an OS or library API. That's what phobos and DUB are for. I'm asking this community to consider setting a new precedent for druntime: reduce the scope to just the language implementation, encapsulate and isolate the platform specific logic (e.g. the ports - see 11666), and deport the artificial dependencies to phobos or other libraries. What do you think about following compromise: 1) C bindings are defined in spec to be optional 2) They are still kept in druntime repo but declared an implementation detail 3) C bindings are defined to be mandatory in Phobos - if Phobos is used with druntime that does not provide C bindings, it must expose ones of its own. It effectively keeps existing layout but moves from a specification to implementation detail making binding-free druntime 100% legal D implementation.
Re: core.stdcpp
On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote: I'm asking this community to consider setting a new precedent for druntime: reduce the scope to just the language implementation, encapsulate and isolate the platform specific logic (e.g. the ports - see 11666), and deport the artificial dependencies to phobos or other libraries. ... and start by creating std.cpp instead of core.stdcpp.
Re: core.stdcpp
On Tuesday, 26 August 2014 at 18:28:38 UTC, Andrei Alexandrescu wrote: I don't understand the objection. Are you arguing that we shouldn't make core.stdc and core.stdcpp available, and instead let anyone who wants to use libc and libc++ write their own declarations? No. We currently have std.c and core.stdc. I believe core.stdc should be migrated to std.c, not the other way around. And before we make the same mistake with core.stdcpp, we should set a new precedent with std.cpp instead. "Why?" D is not subset of C. D is not defined in C. It is its own autonomous language (at least I though it was). Therefore, the dependencies on libc are artificial. Let's not add another artificial dependency with core.stdcpp. The OS bindings in core.sys are another artificial dependency, but let's not go there right now. "But druntime relies on libc?" Wrong! Some of the code needed to port druntime to certain platforms relies on libc (and actually doesn't need to). This code should be encapsulated and isolated from other ports, not publicly exposed and conflated with the rest of the language implementation. This is in the spirit of issue 11666. I believe druntime's scope should be reduced to simply implementing the language, not creating an OS or library API. That's what phobos and DUB are for. I'm asking this community to consider setting a new precedent for druntime: reduce the scope to just the language implementation, encapsulate and isolate the platform specific logic (e.g. the ports - see 11666), and deport the artificial dependencies to phobos or other libraries. Mike
Re: core.stdcpp
On Tuesday, 26 August 2014 at 19:22:22 UTC, Daniel Murphy wrote: "eles" wrote in message news:qrfucjdbmydvoqgey...@forum.dlang.org... Apart from the fact that it's too late to change of course. Well, that separation is just a detail of the implementation, not of the specification. You could simply say that phobos has several namespaces: std, etc, core. Druntime and phobos both had c/OS bindings at some point (core.stdc + std.c) but duplication is bad, so they were/are being moved into druntime. The question of dupplication may be addressed now better, since the newly fixed bug about hierarchical packaging. In druntime you have the true, hidden runtime code (startup, profiler, coverage, unittesting, AAs), plus core language stuff (GC, Thread (+core.time)). _only that_ should be the runtime. And the sole part that one needs to port in order to claim having a full port of the D language (that is, the compiler). These are the tires of the cars, the things that touch the ground. Everything else is optional. (Pirelli had a nice advertisemnt with this line) And, to go further, only c/OS bindings required for this are to be embedded at this level. Phobos is supposed to be 100% optional, although it isn't, quite. If you don't want to use phobos, for example if you are automatically porting a large C++ application, it's nice to simply ban phobos and have that clear distinction. Phobos shall be 100% optional, otherwise you don't have a language, but a framework. This is the separation line: the runtime is a must for the language, the standard library is not. If in doubt wether one piece belongs, cut here.
Re: LDC 0.14.0 released!
On Wednesday, 20 August 2014 at 04:48:02 UTC, Kai Nacke wrote: I managed to get mentioned in LLVM Weekly again. (http://llvmweekly.org/issue/33) LLVM weekly is a newsletter with high attention in the LLVM world. Regards, Kai Cool!
Re: core.stdcpp
"eles" wrote in message news:qrfucjdbmydvoqgey...@forum.dlang.org... While this might be acceptable, there is one more question: what use to have the druntime separated from phobos, in this case? Apart from the fact that it's too late to change of course. For me the druntime shall include only the runtime components that are required for a program to function and on which one could build the whole standard library. And that would be: handling the arguments, the GC, basically, the D program execution model. And by D here I mean "the language", not the "batteries included". Druntime and phobos both had c/OS bindings at some point (core.stdc + std.c) but duplication is bad, so they were/are being moved into druntime. In druntime you have the true, hidden runtime code (startup, profiler, coverage, unittesting, AAs), plus core language stuff (GC, Thread (+core.time)). Phobos is supposed to be 100% optional, although it isn't, quite. If you don't want to use phobos, for example if you are automatically porting a large C++ application, it's nice to simply ban phobos and have that clear distinction.
Re: core.stdcpp
On Tuesday, 26 August 2014 at 18:33:07 UTC, Daniel Murphy wrote: "Mike" wrote in message news:bkkdiikafdsraqssj...@forum.dlang.org... > I really don't see a practical problem with having them in > druntime, only a philosophical one. It give the impression that D requires the C standard library, the C++ standard library, and an full-featured desktop OS in order to function. If I create a port without core.stdc, it can be argued that my port is incomplete. Well I argue that my port is a complete implementation of the language and core.stdc is not part of the D language. What platform supports threads and GC but doesn't have a C lib available? I certainly would argue that this hypothetical port is incomplete, not because druntime including bindings to libc declares it part of the language, but because I can't see a good reason not to include them. Then they can be put in their own library instead of phobos. Yes, they could. IMO the downsides of having to maintain a third library outweighs the 'correctness' advantage, or even having a different root package for this stuff. And there is no way it's ever going to change at this point. That's even better as far as I'm concerned. GTKD isn't part of phobos or druntime. I don't see libc as being any different (in principle) than GTKD. Druntime doesn't use GTK, so it is different. The inclusion of C/OS bindings is historical, and not worth changing. > and they are used in druntime internally. For a practical implementation, those ports that have a libc can make use of it, but it should be internal, and isolated from the language implementation and the other ports, as is the spirit of 11666. There is no point as the bindings are already in druntime and there is very little chance that is going to change. But you could take it a step further for the principled approach. Implement those few features of libc that are needed by the druntime in D, and earn some bragging rights. You could, but it has very little practical value. I personally wouldn't waste my time bragging to someone who thinks druntime depending on libc is an argument against D. Why create DDMD? We already have an implementation in C++, right. What a waste of time... (of course I'm being facetious. Forgive me, but I think it's a great example of why we should do something in D even though a C/C++ implementation exists. No offense intended) It's possible you missed the point of DDMD. DMD is an actively developed codebase which can benefit from many of the features D offers. Well, that was my motivation anyway. I know other people got excited by the idea for other reasons. There is no practical advantage (to the project) from converting a fully debugged, optimized application or library to another language, unless the language barrier is preventing interop. A libc written in D would not give us anything of practical value. That's exactly my point. The debate that ensued with 11666 had nothing to do with the spirit of 11666. If those OS bindings weren't in druntime, 11666 would already be implemented without controversy. And we'd likely already have a few more ports of D to other platforms. The 11666 debate belongs in a std.linux debate or a liblinux debate or some other OS API port debate. No, the exact same thing would have happened if they were in a different package/repository. A different root package would not change the contributors or contribution process. Publicly exposing core.stdc and the OS bindings in druntime is getting in the way of bringing D to more platforms, and the 11666 debate demonstrates that. This is just nonsense. Changing the root package changes nothing. Or those features in libc could be implemented in D, removing the artificial dependency on libc. Re-implementing debugged and optimized code is a waste of time. Only the *port* should have bindings to libc. The language implementation should not. Again those bindings should be encapsulated in the port, not publicly exposed as part of the D language. 1) Being part of druntime does not automatically mean something HAS to be available on every platform. eg the windows bindings are not available on non-windows 2) I don't see any point in not exposing the c lib from druntime, nor do I see any platform where that would be a problem that does not have much more serious issues with hosting D. * It conflates the language with the platform. druntime should be solely the implementation of the language, not an OS API. I disagree, having the OS API in druntime is great and not a problem. * It conflates the implementation of the language with bindings for external libraries. C interop is part of D. Low level (direct) access to operating system APIs is part of D. Exposing them is useful. Again, druntime is the language implementation, not an application programming framework. By this logic the C lib he
Re: core.stdcpp
On Tuesday, 26 August 2014 at 17:09:58 UTC, Walter Bright wrote: On 8/26/2014 8:30 AM, Mike wrote: There's never going to be a clear distinction between druntime and phobos. The original reason for the split anyway was > druntime would be a Well, in C there is and I like that distinction: the runtime handles everything that doesn't need a #include, and that is: - formatting and passing the arguments to main() - replacing some constants (IIRC) at runtime, especially those with sizeof(array) While the distinction between druntime and phobos is one thing (and you are right that it was about Tango vs Phobos, because otherwise Tango was reimplementing those parts in a Phobos-incompatible ways, which prevented programs to use both), now the discussion is more about (c-like) runtime vs (c-like) standard library.
Re: core.stdcpp
"Mike" wrote in message news:bkkdiikafdsraqssj...@forum.dlang.org... > I really don't see a practical problem with having them in druntime, > only a philosophical one. It give the impression that D requires the C standard library, the C++ standard library, and an full-featured desktop OS in order to function. If I create a port without core.stdc, it can be argued that my port is incomplete. Well I argue that my port is a complete implementation of the language and core.stdc is not part of the D language. What platform supports threads and GC but doesn't have a C lib available? I certainly would argue that this hypothetical port is incomplete, not because druntime including bindings to libc declares it part of the language, but because I can't see a good reason not to include them. Then they can be put in their own library instead of phobos. Yes, they could. IMO the downsides of having to maintain a third library outweighs the 'correctness' advantage, or even having a different root package for this stuff. And there is no way it's ever going to change at this point. That's even better as far as I'm concerned. GTKD isn't part of phobos or druntime. I don't see libc as being any different (in principle) than GTKD. Druntime doesn't use GTK, so it is different. The inclusion of C/OS bindings is historical, and not worth changing. > and they are used in druntime internally. For a practical implementation, those ports that have a libc can make use of it, but it should be internal, and isolated from the language implementation and the other ports, as is the spirit of 11666. There is no point as the bindings are already in druntime and there is very little chance that is going to change. But you could take it a step further for the principled approach. Implement those few features of libc that are needed by the druntime in D, and earn some bragging rights. You could, but it has very little practical value. I personally wouldn't waste my time bragging to someone who thinks druntime depending on libc is an argument against D. Why create DDMD? We already have an implementation in C++, right. What a waste of time... (of course I'm being facetious. Forgive me, but I think it's a great example of why we should do something in D even though a C/C++ implementation exists. No offense intended) It's possible you missed the point of DDMD. DMD is an actively developed codebase which can benefit from many of the features D offers. Well, that was my motivation anyway. I know other people got excited by the idea for other reasons. There is no practical advantage (to the project) from converting a fully debugged, optimized application or library to another language, unless the language barrier is preventing interop. A libc written in D would not give us anything of practical value. That's exactly my point. The debate that ensued with 11666 had nothing to do with the spirit of 11666. If those OS bindings weren't in druntime, 11666 would already be implemented without controversy. And we'd likely already have a few more ports of D to other platforms. The 11666 debate belongs in a std.linux debate or a liblinux debate or some other OS API port debate. No, the exact same thing would have happened if they were in a different package/repository. A different root package would not change the contributors or contribution process. Publicly exposing core.stdc and the OS bindings in druntime is getting in the way of bringing D to more platforms, and the 11666 debate demonstrates that. This is just nonsense. Changing the root package changes nothing. Or those features in libc could be implemented in D, removing the artificial dependency on libc. Re-implementing debugged and optimized code is a waste of time. Only the *port* should have bindings to libc. The language implementation should not. Again those bindings should be encapsulated in the port, not publicly exposed as part of the D language. 1) Being part of druntime does not automatically mean something HAS to be available on every platform. eg the windows bindings are not available on non-windows 2) I don't see any point in not exposing the c lib from druntime, nor do I see any platform where that would be a problem that does not have much more serious issues with hosting D. * It conflates the language with the platform. druntime should be solely the implementation of the language, not an OS API. I disagree, having the OS API in druntime is great and not a problem. * It conflates the implementation of the language with bindings for external libraries. C interop is part of D. Low level (direct) access to operating system APIs is part of D. Exposing them is useful. Again, druntime is the language implementation, not an application programming framework. By this logic the C lib header files and windows.h files make an application programming framework. *
Re: Fix #2529: explicit protection package #3651
On 8/26/14, 9:46 AM, Dicebot wrote: ...and it has just been merged! ^_^ Thanks Walter! Congratulations for a job well done. -- Andrei
Re: core.stdcpp
On 8/26/14, 8:30 AM, Mike wrote: On Tuesday, 26 August 2014 at 14:48:48 UTC, Andrei Alexandrescu wrote: On 8/26/14, 3:06 AM, Mike wrote: D has a lot of potential beyond it's current use. Please take this opportunity to reflect on what's been done, take a look ahead, and see if we can set a better precedent for the future. C++ interoperability is very important for D's future. -- Andrei I know it is and I fully support it. I'm not arguing against it. Please add all C++ interoperability support you want to the compiler and to druntime. I look forward to making use of it. Great. But libstdc++ is not part of C++-the-language, and libc is not part of C-the-language. C and C++ can be used without them; I do every day. If core.stdcpp is intended to be the language bindings to libstdc++, I don't think it should belong it D's language implementation, druntime, any more the language bindings to Cairo or GTK should. The same goes for core.stdc and core.sys.linux and friends, as these are not part of D's language implementation. I don't understand the objection. Are you arguing that we shouldn't make core.stdc and core.stdcpp available, and instead let anyone who wants to use libc and libc++ write their own declarations? Andrei
Re: core.stdcpp
On Tuesday, 26 August 2014 at 17:09:58 UTC, Walter Bright wrote: On 8/26/2014 8:30 AM, Mike wrote: Regardless of where stdcpp goes, one issue is that the stuff in it goes into the namespace "std", which conflicts with Phobos' "std" higher level package name. wow. I remember the hot debate about the name o the standard library back then. Remember proposition dsl (D standard library) anyone? and your (sad) comment: "Nobody likes phobos" :)
Re: core.stdcpp
On Tuesday, 26 August 2014 at 18:13:01 UTC, eles wrote: On Tuesday, 26 August 2014 at 17:09:58 UTC, Walter Bright wrote: On 8/26/2014 8:30 AM, Mike wrote: wow. I remember the hot debate about the name o the standard library back then. well, namesace name
Re: core.stdcpp
On 8/26/2014 8:30 AM, Mike wrote: If core.stdcpp is intended to be the language bindings to libstdc++, I don't think it should belong it D's language implementation, druntime, any more the language bindings to Cairo or GTK should. The same goes for core.stdc and core.sys.linux and friends, as these are not part of D's language implementation. Regardless of where stdcpp goes, one issue is that the stuff in it goes into the namespace "std", which conflicts with Phobos' "std" higher level package name. So it has to be in a separate hierarchy. There's never going to be a clear distinction between druntime and phobos. The original reason for the split anyway was that druntime would be a common core between Tango and Phobos. That reason has faded away. I suggested core.stdcpp because given the existence of core.stdc, it's where people will expect to find it.
Re: Fix #2529: explicit protection package #3651
On Tue, 26 Aug 2014 16:46:19 + Dicebot via Digitalmars-d-announce wrote: > ..and it has just been merged! ^_^ WOW! that's great! > Thanks Walter! second that! signature.asc Description: PGP signature
Re: Fix #2529: explicit protection package #3651
..and it has just been merged! ^_^ Thanks Walter!
Re: LDC 0.14.0 released!
On Wednesday, 20 August 2014 at 04:48:02 UTC, Kai Nacke wrote: On Friday, 15 August 2014 at 15:04:44 UTC, Kai Nacke wrote: Hi everyone, LDC 0.14.0, the LLVM-based D compiler, is available for download! This release is based on the 2.065.0 frontend and standard library and supports LLVM 3.1-3.4.2 (OS X: 3.2/3.4 only). As usual, you can find links to the changelog and the binary packages over at digitalmars.D.ldc: http://forum.dlang.org/post/ynlnfdqwkweenkwct...@forum.dlang.org Regards, Kai I managed to get mentioned in LLVM Weekly again. (http://llvmweekly.org/issue/33) LLVM weekly is a newsletter with high attention in the LLVM world. Regards, Kai Nice :)
Re: core.stdcpp
On Tuesday, 26 August 2014 at 15:44:31 UTC, eles wrote: On Tuesday, 26 August 2014 at 15:30:35 UTC, Mike wrote: On Tuesday, 26 August 2014 at 14:48:48 UTC, Andrei Alexandrescu wrote: On 8/26/14, 3:06 AM, Mike wrote: The same goes for core.stdc and core.sys.linux and friends, as these are not part of D's language implementation. Am I correct to define the language as: begin file--- //no imports here //any code here - ? If you import, then is the library. That may be an oversimplification, but basically, "Yes".
Re: core.stdcpp
On Tuesday, 26 August 2014 at 12:54:49 UTC, Daniel Murphy wrote: I really don't see a practical problem with having them in druntime, only a philosophical one. It give the impression that D requires the C standard library, the C++ standard library, and an full-featured desktop OS in order to function. If I create a port without core.stdc, it can be argued that my port is incomplete. Well I argue that my port is a complete implementation of the language and core.stdc is not part of the D language. They should still be available when not using phobos, Then they can be put in their own library instead of phobos. That's even better as far as I'm concerned. GTKD isn't part of phobos or druntime. I don't see libc as being any different (in principle) than GTKD. and they are used in druntime internally. For a practical implementation, those ports that have a libc can make use of it, but it should be internal, and isolated from the language implementation and the other ports, as is the spirit of 11666. But you could take it a step further for the principled approach. Implement those few features of libc that are needed by the druntime in D, and earn some bragging rights. Why create DDMD? We already have an implementation in C++, right. What a waste of time... (of course I'm being facetious. Forgive me, but I think it's a great example of why we should do something in D even though a C/C++ implementation exists. No offense intended) 11666 is contentious because everybody has a different opinion on the layout. This is about personal preferences, and has nothing to do with OS bindings being in druntime. The same exact discussion would happen if they were in phobos. That's exactly my point. The debate that ensued with 11666 had nothing to do with the spirit of 11666. If those OS bindings weren't in druntime, 11666 would already be implemented without controversy. And we'd likely already have a few more ports of D to other platforms. The 11666 debate belongs in a std.linux debate or a liblinux debate or some other OS API port debate. Publicly exposing core.stdc and the OS bindings in druntime is getting in the way of bringing D to more platforms, and the 11666 debate demonstrates that. I get that you're saying this, but why? How will it make any difference to anything ever? libc is ubiquitous, and the parts that are used internally could trivially be reimplemented on a platform where it was missing. (or more likely, it could just be ported) Or those features in libc could be implemented in D, removing the artificial dependency on libc. ??? If you want to / need to, you can write a libc implementation in D. The fact that the major D platforms all choose to link against the system libc instead of rolling their own has no bearing on the language class of D. The fact that druntime includes a prototype for memcpy or fopen does not change anything either. It just makes D more convenient for porting C code. Only the *port* should have bindings to libc. The language implementation should not. Again those bindings should be encapsulated in the port, not publicly exposed as part of the D language. It could be my failing, but I really don't see the point. What are the potential consequences of maintaining and extending the C, C++ and OS bindings in druntime? * It conflates the language with the platform. druntime should be solely the implementation of the language, not an OS API. * It conflates the implementation of the language with bindings for external libraries. Again, druntime is the language implementation, not an application programming framework. * It sets the wrong precedent for a systems programming language. IMO a true systems programming language should be self-reliant. That is, it should be a language that can be used to build the first layer of hardware abstraction. * It creates artificial dependencies when there's no real dependency. C++ being a superset of C is an example of a real dependency. That is not D. * It gets in the way of porting the language to more platforms and complicates maintenance of the runtime. Case in point: the 11666 debate. * It makes D unportable to some platforms without creating their own dialect of the language or their own D runtime implementation In summary, I believe libc, libstd++, and the OS bindings should be encapsulated and isolated by the ports that need them, not publicly exposed as part of the D language implementation. Having bindings to these these libraries is super important, and I'm glad they exists. I just don't think they belong in the D language implementation, except as encapsulated, isolated artifacts of ports that need them. Mike
Re: core.stdcpp
On Tuesday, 26 August 2014 at 15:30:35 UTC, Mike wrote: On Tuesday, 26 August 2014 at 14:48:48 UTC, Andrei Alexandrescu wrote: On 8/26/14, 3:06 AM, Mike wrote: The same goes for core.stdc and core.sys.linux and friends, as these are not part of D's language implementation. Am I correct to define the language as: begin file--- //no imports here //any code here - ? If you import, then is the library.
Re: core.stdcpp
On Tuesday, 26 August 2014 at 14:48:48 UTC, Andrei Alexandrescu wrote: On 8/26/14, 3:06 AM, Mike wrote: D has a lot of potential beyond it's current use. Please take this opportunity to reflect on what's been done, take a look ahead, and see if we can set a better precedent for the future. C++ interoperability is very important for D's future. -- Andrei I know it is and I fully support it. I'm not arguing against it. Please add all C++ interoperability support you want to the compiler and to druntime. I look forward to making use of it. But libstdc++ is not part of C++-the-language, and libc is not part of C-the-language. C and C++ can be used without them; I do every day. If core.stdcpp is intended to be the language bindings to libstdc++, I don't think it should belong it D's language implementation, druntime, any more the language bindings to Cairo or GTK should. The same goes for core.stdc and core.sys.linux and friends, as these are not part of D's language implementation. Mike
Re: Miscelaneous D tool updates
On Thursday, 7 August 2014 at 23:36:59 UTC, Brian Schott wrote: dscanner: https://github.com/Hackerpilot/Dscanner Thanks for dscanner - a really helpful tool. BTW Your build.bat as of 2014-08-25 didn't work for me - it produced wrong paths, e.g. (shortened): dmd src\astprinter.d src\ctags.d ... analysis/src\asm_style.d analysis/src\base.d ... -O -release -inline -ofdscanner.exe Error: cannot read file analysis\src\asm_style.d analysis/src instead of src/analysis The following build.bat did work for me (and it took less than 10 seconds on an i5 with Win7 - 64): --- snip --- @echo off echo %time% setlocal enabledelayedexpansion set DFLAGS=-O -release -inline set CORE= set STD= set STDD= set ANALYSIS= set INIFILED= for %%x in (src\*.d) do set CORE=!CORE! %%x for %%x in (src\analysis\*.d) do set ANALYSIS=!ANALYSIS! %%x for %%x in (libdparse\src\std\*.d) do set STD=!STD! %%x for %%x in (libdparse\src\std\d\*.d) do set STDD=!STDD! %%x for %%x in (inifiled\source\*.d) do set INIFILED=!INIFILED! %%x @echo on dmd %CORE% %STD% %STDD% %ANALYSIS% %INIFILED% %DFLAGS% -ofdscanner.exe @echo off echo %time% --- snip ---
digitalmars-d-announce@puremagic.com
On Saturday, 23 August 2014 at 13:19:18 UTC, dlangophile wrote: On Thursday, 14 August 2014 at 07:51:11 UTC, Alex wrote: On Thursday, 14 August 2014 at 07:07:59 UTC, Alex wrote: Invoking stuff is easy. I'd rather reimplement the communication to the dcd server instead to not get such a bottleneck if you're on windows or typing really fast. Executing an entire program for each keystroke is a real unsustainable solution, imho. https://github.com/Hackerpilot/DCD/blob/master/client.d#L72 Alright. :-) Actually, someone has turned on the _"Enable Mixin & Template Mixin Analysis"_ options? Major drawbacks? I did - basic stuff which was tested works :-P https://github.com/aBothe/D_Parser/blob/master/Tests/ResolutionTests.cs#L3151-L3380 Someone has turned _off_ the _"Only indent code lines instead of rearrange code parts"_? Major drawbacks? I haven't implemented any new formatting features since indenting is totally satisfying for me. :-)
Re: core.stdcpp
On 8/26/14, 3:06 AM, Mike wrote: D has a lot of potential beyond it's current use. Please take this opportunity to reflect on what's been done, take a look ahead, and see if we can set a better precedent for the future. C++ interoperability is very important for D's future. -- Andrei
Re: D 2.066 is out. Enjoy!
On Friday, 22 August 2014 at 21:41:13 UTC, Andrew Edwards wrote: 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. I was waiting few days for someone to update the main page before I lost patience and created the pull-request. Even worse - it was not accepted until I explicitly asked Andrej to merge it on IRC... This said I am afraid I will have to agree with conclusion that our release manager will have to push the change of the main page with updated details, after each release.
Re: core.stdcpp
"Ola Fosheim Grøstad" " wrote in message news:mclztlymyjydwhcxs...@forum.dlang.org... Probably, at least without whole-program optimization turned on. Linking with D is not a concern for whole-program-optimized C++ programs. But you still have to track compiler version changelogs and then deal with possibly multiple D implementations just fro one compiler. I guess it can work out if you limit yourselves to just std::vector and std::string… Yes, it's a pain. I've done it with one templated struct inside DDMD, and that was a pain. I don't know if it will work sufficiently for mapping to stl, but it's worth a try. It's usually easier to test with multiple versions and manually determine differences when problems arise. Changelogs often do not cover anything more than API changes, especially with some vendors. This idea would have a more merit if DMD was 100% LLVM based and focused on one architecture… Doing this for many compilers on many architectures sounds like versioning hell. It would be easier, but I don't think it changes the merit of the idea. Matching calling conventions is a much more difficult problem (in dmd's backend at least) and yet interoperability is so useful that it's worthwhile.
Re: core.stdcpp
On Tuesday, 26 August 2014 at 12:23:18 UTC, Daniel Murphy wrote: I would be very surprised to find a C++ compiler that does this over public function boundaries, as it would prevent mixing optimized and unoptimized code. Probably, at least without whole-program optimization turned on. But you still have to track compiler version changelogs and then deal with possibly multiple D implementations just fro one compiler. I guess it can work out if you limit yourselves to just std::vector and std::string… This idea would have a more merit if DMD was 100% LLVM based and focused on one architecture… Doing this for many compilers on many architectures sounds like versioning hell.
Re: core.stdcpp
"Mike" wrote in message news:zjscnxerhbxnopvay...@forum.dlang.org... The C standard library and C++ standard library are not part of D-the-language. D would even be better served by putting these features in phobos as std.stdc and std.stdcpp. This would make them just as conveniently available to users, and reduce the coupling between the language and the platform. I really don't see a practical problem with having them in druntime, only a philosophical one. They should still be available when not using phobos, and they are used in druntime internally. I think this is what makes issue 11666[1] so difficult and controversial. The features of the C std lib that are needed by the D runtime are not many, and could be re-implemented in D. The OS bindings needed to implement the D runtime could be internal and moved to a separate folder as proposed in the spirit of 11666. Public OS bindings could be put in std.linux, std.windows, etc... along with std.stdc and std.stdcpp. 11666 is contentious because everybody has a different opinion on the layout. This is about personal preferences, and has nothing to do with OS bindings being in druntime. The same exact discussion would happen if they were in phobos. It might be expeditious to just wrap and link, but I argue that D would be more appealing as a language (rather than a framework) if this wasn't the case. I get that you're saying this, but why? How will it make any difference to anything ever? libc is ubiquitous, and the parts that are used internally could trivially be reimplemented on a platform where it was missing. (or more likely, it could just be ported) I concede this is true for the vast majority of systems out there, but it makes D an applications programming framework, not a systems programming language. ??? If you want to / need to, you can write a libc implementation in D. The fact that the major D platforms all choose to link against the system libc instead of rolling their own has no bearing on the language class of D. The fact that druntime includes a prototype for memcpy or fopen does not change anything either. It just makes D more convenient for porting C code. I politely ask those pursuing core.stdcpp to reconsider and look further in the future. Please think beyond desktop and server application programming. Consider what D could be used for, not just what it is currently used for, and darken the line between the language and the platform. Make it a more of a language, and less of a framework. It could be my failing, but I really don't see the point. What are the potential consequences of maintaining and extending the C, C++ and OS bindings in druntime?
Re: core.stdcpp
"Ola Fosheim Grøstad" " wrote in message news:pbfaphgiugafrhach...@forum.dlang.org... I know, but the vendor provided C++ libraries could trigger compiler-magic in the optimizer, so it might not be enough to look at the source code in the general case… I would be very surprised to find a C++ compiler that does this over public function boundaries, as it would prevent mixing optimized and unoptimized code.
Re: core.stdcpp
On Tuesday, 26 August 2014 at 10:57:10 UTC, eles wrote: For me, what it would be really nice to have in C from C++ would be templates. And from D, that scope(). When I think about it, I think one of the reasons for going from C to C++ in visualization/games was that 3D operations in C are unreadable. With operator overloading it got better. Of course, the C compiler could just have been extended with basic arithmetic operators on fixed size arrays… and added SIMDy alignment. I think C was a little late with adding needed features, that gave C++ room for marketing itself. The problem with starting designing (and implementing) frameworks instead of languages is that you have to keep up with everything and to never cease expanding. New needs will appear, new paradigms (platforms, distributed systems and so on) and you will have to play the game. Yep, that is true. It is OK to provide extensive standard library, but not put too much into the language (and, for me, the druntime shall be seen as part of the language, not of the framework). The problem is that once you go for RTTI and GC then the runtime is already quite big, so adding one piece to it does not seem like a big deal… I think a language like D is best suited for things that can be resolved at compile time than the more dynamic stuff. I'd rather see whole program analysis and as much static features as possible than all the dynamic aspects and the runtime requirements that come with it… That would give the project more focus and make it more suitable for real system level programming. But, still. Even Java and C# have a separation between the language and the framework, more than, for example, Go has. Yes, they compile to a medium level IR.
Re: core.stdcpp
On Tuesday, 26 August 2014 at 07:56:45 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 26 August 2014 at 07:06:57 UTC, eles wrote: convenient inlining and operator overloading. So people use it For me, what it would be really nice to have in C from C++ would be templates. And from D, that scope(). I bet D would have been slimmer if it had been part of a OS project, but my gut feeling is that it is more work to slim down D than C++. I think D would greatly benefit from a high level IR that various "D dialects" could compile to. Then analyse the high level IR to determine what the runtime requirements are. The problem with starting designing (and implementing) frameworks instead of languages is that you have to keep up with everything and to never cease expanding. New needs will appear, new paradigms (platforms, distributed systems and so on) and you will have to play the game. It is OK to provide extensive standard library, but not put too much into the language (and, for me, the druntime shall be seen as part of the language, not of the framework). But, still. Even Java and C# have a separation between the language and the framework, more than, for example, Go has.
Re: core.stdcpp
On Tuesday, 26 August 2014 at 10:44:03 UTC, Mike wrote: On Tuesday, 26 August 2014 at 07:56:45 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 26 August 2014 at 07:06:57 UTC, eles wrote: Yeah, I think C's success is directly linked to having a clear use scenario and avoiding being a "general purpose language" What? C is THE quintessential general purpose programming language. It can be used to program anything. Notice the quotes? :) C can be used to program anything, but it isn't suitable to program everything.
Re: core.stdcpp
On Tuesday, 26 August 2014 at 07:56:45 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 26 August 2014 at 07:06:57 UTC, eles wrote: Yeah, I think C's success is directly linked to having a clear use scenario and avoiding being a "general purpose language" What? C is THE quintessential general purpose programming language. It can be used to program anything.
[Zeus IDE] Dscanner Python Scripts
I've created a set of Zeus Python scripts to allow the Dscanner to be run from inside Zeus. The Dscanner will need to be downloaded and built form here: https://github.com/Hackerpilot/Dscanner The Zeus scripts can be found here: http://www.zeusedit.com/zforum/viewtopic.php?t=7196 Note: I'm the author of Zeus, Zeus is shareware, runs natively on the Windows platform and can also be run on Linux using Wine.
Re: core.stdcpp
On Tuesday, 26 August 2014 at 06:35:18 UTC, Walter Bright wrote: On 8/25/2014 11:12 PM, Mike wrote: The C standard library and C++ standard library are not part of D-the-language. D would even be better served by putting these features in phobos as std.stdc and std.stdcpp. This would make them just as conveniently available to users, and reduce the coupling between the language and the platform. It's beginning to look more and more like an stdcpp is achievable. The implementation of it, however, is going to be ugly and very specific to each C++ compiler. The user shouldn't need to have to see that ugliness, though. It also means that implementing stdcpp is going to require someone who is very willing to go spelunking around the underbelly of C++ ::std:: and understand it, which is a tall order. You must have stopped reading after my first paragraph :) I seem to have that effect :(
Re: core.stdcpp
On Tuesday, 26 August 2014 at 08:15:07 UTC, Marc Schütz wrote: On Tuesday, 26 August 2014 at 06:12:54 UTC, Mike wrote: The C standard library and C++ standard library are not part of D-the-language. D would even be better served by putting these features in phobos as std.stdc and std.stdcpp. This would make them just as conveniently available to users, and reduce the coupling between the language and the platform. But stdc is its own subpackage in druntime, it's already very modular. It should be easy to remove if you want to create a minimal druntime. For stdcpp, this will be even more true. Up until now, Phobos consists of mostly high-level modules, while those closer to the OS, and the compiler-dependent parts, reside in druntime. I think this is a good division. My argument isn't about making my own hobby D Runtime. It's about THE D Runtime and more importantly D-the-language (not library routines and OS bindings). There's quite a bit in the D Runtime that's not relevant to the language. I'm guessing it's there because it was convenient at the time. Take a look at the controversy 11666 caused. It had nothing to do with the language or it's portability, and everything to do with how to expose the Linux kernel headers. Just as it is right to separate Phobos from druntime, it is right to separate the language from the platform. It will ensure D's longevity and our return on investment for learning and contributing to this language. (You will likely not be programming the platform you're currently programming in 5 years) I'm not interested in Go, Rust, and other application and server programming languages. I want an alternative to C/C++ (and I'm not talking about libc, libm, and libcpp, I'm talking about the language). D has a lot of potential beyond it's current use. Please take this opportunity to reflect on what's been done, take a look ahead, and see if we can set a better precedent for the future. Mike
Re: core.stdcpp
On Tuesday, 26 August 2014 at 08:25:58 UTC, Jonathan M Davis via Digitalmars-d-announce wrote: Quite possibly, but then it wouldn't integrate with existing C++ libraries built with the system's C++ compiler, which would be the point. I know, but the vendor provided C++ libraries could trigger compiler-magic in the optimizer, so it might not be enough to look at the source code in the general case…
Re: core.stdcpp
On Tue, 26 Aug 2014 07:00:26 + Ola Fosheim Gr via Digitalmars-d-announce wrote: > On Tuesday, 26 August 2014 at 06:35:18 UTC, Walter Bright wrote: > > The implementation of it, however, is going to be ugly and very > > specific to each C++ compiler. The user shouldn't need to have > > to see that ugliness, though. > > Sounds easier to write your own ::std:: on the c++ side... Quite possibly, but then it wouldn't integrate with existing C++ libraries built with the system's C++ compiler, which would be the point. - Jonathan M Davis
Re: core.stdcpp
On Tuesday, 26 August 2014 at 06:12:54 UTC, Mike wrote: The C standard library and C++ standard library are not part of D-the-language. D would even be better served by putting these features in phobos as std.stdc and std.stdcpp. This would make them just as conveniently available to users, and reduce the coupling between the language and the platform. But stdc is its own subpackage in druntime, it's already very modular. It should be easy to remove if you want to create a minimal druntime. For stdcpp, this will be even more true. Up until now, Phobos consists of mostly high-level modules, while those closer to the OS, and the compiler-dependent parts, reside in druntime. I think this is a good division.
Re: core.stdcpp
On Tuesday, 26 August 2014 at 07:06:57 UTC, eles wrote: Apparently, all things have this tendency to get bloated. One of the main reasons for C's still unbelievable success is its slimness. Yeah, I think C's success is directly linked to having a clear use scenario and avoiding being a "general purpose language" and having "minimal runtime" as the basic philosophy. With a strong focus on OS development it was locked to it's roots. C++ was always perceived as more of an application level language, but was sometimes used as a C replacement because of convenient inlining and operator overloading. So people use it without RTTI, exceptions and ::std:: bloat… I bet D would have been slimmer if it had been part of a OS project, but my gut feeling is that it is more work to slim down D than C++. I think D would greatly benefit from a high level IR that various "D dialects" could compile to. Then analyse the high level IR to determine what the runtime requirements are.
Re: core.stdcpp
On Tuesday, 26 August 2014 at 06:12:54 UTC, Mike wrote: On Tuesday, 26 August 2014 at 05:03:01 UTC, Daniel Murphy wrote: "Mike" wrote in message news:sdrjfagsayomsngme...@forum.dlang.org... line between the language and the platform. Make it a more of a language, and less of a framework. Apparently, all things have this tendency to get bloated. One of the main reasons for C's still unbelievable success is its slimness.
Re: core.stdcpp
On Tuesday, 26 August 2014 at 06:35:18 UTC, Walter Bright wrote: The implementation of it, however, is going to be ugly and very specific to each C++ compiler. The user shouldn't need to have to see that ugliness, though. Sounds easier to write your own ::std:: on the c++ side...
