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: Programming in D book, User Defined Attributes (UDA) chapter
On Tue, 26 Aug 2014 23:16:14 -0700 Ali Çehreli via Digitalmars-d-announce digitalmars-d-announce@puremagic.com 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
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 digitalmars-d-announce@puremagic.com 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: 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: core.stdcpp
eles wrote in message news:ybcxmuwwpsiyupwer...@forum.dlang.org... The question of dupplication may be addressed now better, since the newly fixed bug about hierarchical packaging. I don't see how. _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) Well, I agree it absolutely has to be in druntime. And, to go further, only c/OS bindings required for this are to be embedded at this level. Requiring full c/OS bindings in druntime is so useful, and it costs us so little. Besides a warm fuzzy feeling, not requiring them seems to only benefit D implementations for theoretical platforms that probably don't exist. 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. Call it what you want. Phobos is supposed to be 100% optional but it currently is not. We get to decide where the line goes, and with D it is almost always decided on usefulness, not correctness. Requiring c bindings is useful.
Re: core.stdcpp
On Wednesday, 27 August 2014 at 07:52:18 UTC, Daniel Murphy wrote: eles wrote in message news:ybcxmuwwpsiyupwer...@forum.dlang.org... Requiring full c/OS bindings in druntime is so useful, and it costs us so little. But the request is simply to split the current druntime in a language-runtime and a phobos-runtime. The namespace and so on might even remain the same and the existing code would run unmodified. What is really important is that a clear separation exists between the two *inside* the implementation. The users of D are not concerned about that, the compiler designers are. Have, as now, the language-runtime + the phobos-runtime calles as druntime. Why does bother you a re-modularization of druntime? Besides a warm fuzzy feeling, not requiring them seems to only benefit D implementations for theoretical platforms that probably don't exist. One such platform exists and is the embedded system, others are the linux kernel and the like, and even others are writing D compiler back-ends and, yes, druntimes (well, exactly the part that it is called phobos-runtime above). If you make porting harder, then you can safely bet that those ports won't ever exist. But is this truly what we want?
Re: core.stdcpp
On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright wrote: On 8/26/2014 5:32 PM, Mike wrote: Moving it back in an endless search for taxonomical perfection Well, keeping things in limbo for such many years (@property, anyone?) is not going to help neither. I agree it is a fine balance between changing for better consistency and conserve for compatibility. Still, some changes are small and would solve problems for the many years to come. I still cannot forget that decision to keep the flawed std.uni name instead of a std.unicode name. It wasn't even costly. But, well... And one day from now you will write The paradox is that at one moment we decided to keep the std.uni name because of taxonomical compatibility etc. etc. etc.
Re: core.stdcpp
On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright wrote: 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. ...and design takes the backseat to convenience. 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. I completely understand and sympathize. This is most unfortunate.
Re: core.stdcpp
On Wednesday, 27 August 2014 at 02:17:39 UTC, Dicebot wrote: 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. It's a step in the right direction, but ultimately just a formality. Maybe that's the best I can hope for.
Re: core.stdcpp
eles wrote in message news:rixtiaiokrukvqjsf...@forum.dlang.org... But the request is simply to split the current druntime in a language-runtime and a phobos-runtime. The namespace and so on might even remain the same and the existing code would run unmodified. What is really important is that a clear separation exists between the two *inside* the implementation. The users of D are not concerned about that, the compiler designers are. Have, as now, the language-runtime + the phobos-runtime calles as druntime. Why does bother you a re-modularization of druntime? I disagree that it's important, or even useful. One such platform exists and is the embedded system, others are the linux kernel and the like, and even others are writing D compiler back-ends and, yes, druntimes (well, exactly the part that it is called phobos-runtime above). An embedded system that can support all of D but doesn't have a cruntime? I don't believe it. If it has a cruntime then providing bindings is a non-issue, and if it can't support all of D then supporting only a subset (and then being free to exclude core.stdc) is inevitable. If you make porting harder, then you can safely bet that those ports won't ever exist. But is this truly what we want? I think it's more likely that those ports won't exist because those platforms don't exist.
DMD v2.067.0-b1
Hello all, Binaries for beta 1 is available for download and testing. You can find them at: http://wiki.dlang.org/Beta_Testing Test!!! Document bugs/regressions!!! Enjoy!!! Thanks to those who have contributed to the maintenance/upkeep of the wiki page. As I am no a full-time student with an overly aggressive class schedule, I am finding less and less time to keep track of what is going on. I appreciate the assistance. Andrew
Re: DMD v2.067.0-b1
On 8/27/2014 2:19 PM, Andrew Edwards wrote: Hello all, Binaries for beta 1 is available for download and testing. You can find them at: http://wiki.dlang.org/Beta_Testing Test!!! Document bugs/regressions!!! Enjoy!!! Thanks to those who have contributed to the maintenance/upkeep of the wiki page. As I am no a full-time student with an overly aggressive class schedule, I am finding less and less time to keep track of what is going on. I appreciate the assistance. Andrew There has been a lot of valid criticism about us releasing 2.066 with outstanding regressions. https://issues.dlang.org/buglist.cgi?bug_severity=regressionbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDlist_id=88763query_format=advanced Fixes exist: https://github.com/D-Programming-Language/dmd/pull/3884 https://github.com/D-Programming-Language/dmd/pull/3879 Let's get them reviewed/pulled and do a 2.066 point release.
Re: DMD v2.067.0-b1
On Wednesday, 27 August 2014 at 21:22:42 UTC, Walter Bright wrote: On 8/27/2014 2:19 PM, Andrew Edwards wrote: Hello all, Binaries for beta 1 is available for download and testing. You can find them at: http://wiki.dlang.org/Beta_Testing Test!!! Document bugs/regressions!!! Enjoy!!! Thanks to those who have contributed to the maintenance/upkeep of the wiki page. As I am no a full-time student with an overly aggressive class schedule, I am finding less and less time to keep track of what is going on. I appreciate the assistance. Andrew There has been a lot of valid criticism about us releasing 2.066 with outstanding regressions. https://issues.dlang.org/buglist.cgi?bug_severity=regressionbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDlist_id=88763query_format=advanced Fixes exist: https://github.com/D-Programming-Language/dmd/pull/3884 https://github.com/D-Programming-Language/dmd/pull/3879 Let's get them reviewed/pulled and do a 2.066 point release. Very true but this does not conflict with 2.067 cycle (other than competing for attention of compiler developers)
Re: core.stdcpp
On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright wrote: 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. I don't think the problem here is about naming. Both std.c and core.stdc are good. The problem is that you don't always want to bring libc and libstdc++ with you with every single project you write. Thus it shouldn't be in the runtime (except the very bit you can't get rid of). It can still be core.stdc .
Re: DMD v2.067.0-b1
On 8/27/2014 2:27 PM, Dicebot wrote: Let's get them reviewed/pulled and do a 2.066 point release. Very true but this does not conflict with 2.067 cycle (other than competing for attention of compiler developers) You're right, somehow I misread 2.067 as 2.066. My mistake.
Re: DMD v2.067.0-b1
Does this 2.67 release contain COFF32, and the new package fix? On 28 August 2014 07:45, Walter Bright via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 8/27/2014 2:27 PM, Dicebot wrote: Let's get them reviewed/pulled and do a 2.066 point release. Very true but this does not conflict with 2.067 cycle (other than competing for attention of compiler developers) You're right, somehow I misread 2.067 as 2.066. My mistake.
