www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - D 2.066 is out. Enjoy!

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Aug 18 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
I have a mixed feelings about this release. It has some really 
cool features and is good to finally see live. But it has taken 
ages and there are still many open regressions 
(http://wiki.dlang.org/Beta_Testing). And stuff like 
https://issues.dlang.org/show_bug.cgi?id=11946 is just small 
disaster - complicated by the fact that no one but Kenji seems to 
be able neither to fix it nor even revert it.

I don't know if we can do anything better about it.
Aug 18 2014
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Monday, 18 August 2014 at 19:23:14 UTC, Dicebot wrote:
 I have a mixed feelings about this release. It has some really 
 cool features and is good to finally see live. But it has taken 
 ages and there are still many open regressions 
 (http://wiki.dlang.org/Beta_Testing). And stuff like 
 https://issues.dlang.org/show_bug.cgi?id=11946 is just small 
 disaster - complicated by the fact that no one but Kenji seems 
 to be able neither to fix it nor even revert it.

 I don't know if we can do anything better about it.
I agree, I am also surprised that 2.066 was released despite the regressions. I uncovered a few just by accidentally instructing someone on #d to build their project against git HEAD. Most of the regressions were found in his project's dub dependencies - libraries published on code.dlang.org. I was thinking of trying to see if more projects on the dub registry failed to build with the 2.066 RC once the current round of regressions was resolved. How is it decided when it's time to cut off a new release? Do we have two RCs and that's it?
Aug 18 2014
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Monday, 18 August 2014 at 20:43:44 UTC, Vladimir Panteleev 
wrote:
 On Monday, 18 August 2014 at 19:23:14 UTC, Dicebot wrote:
 I have a mixed feelings about this release. It has some really 
 cool features and is good to finally see live. But it has 
 taken ages and there are still many open regressions 
 (http://wiki.dlang.org/Beta_Testing). And stuff like 
 https://issues.dlang.org/show_bug.cgi?id=11946 is just small 
 disaster - complicated by the fact that no one but Kenji seems 
 to be able neither to fix it nor even revert it.

 I don't know if we can do anything better about it.
I agree, I am also surprised that 2.066 was released despite the regressions. I uncovered a few just by accidentally instructing someone on #d to build their project against git HEAD. Most of the regressions were found in his project's dub dependencies - libraries published on code.dlang.org. I was thinking of trying to see if more projects on the dub registry failed to build with the 2.066 RC once the current round of regressions was resolved. How is it decided when it's time to cut off a new release? Do we have two RCs and that's it?
I don't know. There was nothing in the mail list until Andrei came with announcement and I did not expect it at all - in fact I would have merged one of regression fixes for Phobos 12 hours earlier otherwise.
Aug 18 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Vladimir Panteleev:

 I agree, I am also surprised that 2.066 was released despite 
 the regressions.
There is an apparently endless stream of regressions, I have found another today (https://issues.dlang.org/show_bug.cgi?id=13321 ). I think D is not yet at the stage of its development where it can hope to fix all the regressions. So if you try to wait for all regressions to be fixed, you never ship a compiler version, and this has serious disadvantages. So better to be a little more practical for now. 2.066 has took ages to come out, it was overdue. I hope 2.067 will come out much quicker. Bye, bearophile
Aug 18 2014
next sibling parent reply "bachmeier" <no spam.net> writes:
On Monday, 18 August 2014 at 21:57:19 UTC, bearophile wrote:
 Vladimir Panteleev:

 I agree, I am also surprised that 2.066 was released despite 
 the regressions.
There is an apparently endless stream of regressions, I have found another today (https://issues.dlang.org/show_bug.cgi?id=13321 ). I think D is not yet at the stage of its development where it can hope to fix all the regressions. So if you try to wait for all regressions to be fixed, you never ship a compiler version, and this has serious disadvantages. So better to be a little more practical for now. 2.066 has took ages to come out, it was overdue. I hope 2.067 will come out much quicker. Bye, bearophile
What's the advantage of this over maintaing packages for the RC version until it's ready?
Aug 18 2014
parent reply ketmar via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
On Mon, 18 Aug 2014 22:01:24 +0000
bachmeier via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 What's the advantage of this over maintaing packages for the RC
 version until it's ready?
'cause not releasing periodically means "ah, it will never be ready! let's look at another language, D is not worth using yet."
Aug 18 2014
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Monday, 18 August 2014 at 22:20:19 UTC, ketmar via 
Digitalmars-d-announce wrote:
 On Mon, 18 Aug 2014 22:01:24 +0000
 bachmeier via Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com> wrote:

 What's the advantage of this over maintaing packages for the RC
 version until it's ready?
'cause not releasing periodically means "ah, it will never be ready! let's look at another language, D is not worth using yet."
I don't see how infrequent, stable releases are more likely to provoke that reaction than frequent, unstable releases.
Aug 18 2014
parent reply ketmar via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
On Mon, 18 Aug 2014 22:48:00 +0000
Vladimir Panteleev via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 I don't see how infrequent, stable releases are more likely to=20
 provoke that reaction than frequent, unstable releases.
"stability" is something that cannot be achieved in living language. and having official releases with new features is important to show that project is alive and "mature". i myself using dmd-git-head and heavily ;-) patched gdc, but when i tried to convince my co-workers to use D, they looked at the page with releases first. not feature list or some comparisons. neither to "buglist". "as this is relatively young language, it must have frequent releases with bugfixes and new features!" they tolerate some regressions in some releases, but they want to see that releases. don't ask me why they thinking like this. i don't know. but it's the fact.
Aug 18 2014
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 8/18/2014 7:07 PM, ketmar via Digitalmars-d-announce wrote:
 On Mon, 18 Aug 2014 22:48:00 +0000
 Vladimir Panteleev via Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com> wrote:

 I don't see how infrequent, stable releases are more likely to
 provoke that reaction than frequent, unstable releases.
"stability" is something that cannot be achieved in living language. and having official releases with new features is important to show that project is alive and "mature". i myself using dmd-git-head and heavily ;-) patched gdc, but when i tried to convince my co-workers to use D, they looked at the page with releases first. not feature list or some comparisons. neither to "buglist". "as this is relatively young language, it must have frequent releases with bugfixes and new features!" they tolerate some regressions in some releases, but they want to see that releases. don't ask me why they thinking like this. i don't know. but it's the fact.
Well, people will invent *any* excuse to pass over anything they don't feel like bothering with. It sounds like that's probably what they were doing.
Aug 18 2014
parent ketmar via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
On Mon, 18 Aug 2014 20:22:08 -0400
Nick Sabalausky via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 Well, people will invent *any* excuse to pass over anything they
 don't feel like bothering with. It sounds like that's probably what
 they were doing.
not exactly, 'cause they *are* interested in using D, especially after i demonstrated some 'D power' and pointed 'em to the excellent Ali's book.
Aug 18 2014
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Monday, 18 August 2014 at 23:07:27 UTC, ketmar via 
Digitalmars-d-announce wrote:
 i myself using dmd-git-head and heavily ;-) patched gdc, but 
 when i
 tried to convince my co-workers to use D, they looked at the 
 page with
 releases first. not feature list or some comparisons. neither to
 "buglist". "as this is relatively young language, it must have 
 frequent
 releases with bugfixes and new features!" they tolerate some
 regressions in some releases, but they want to see that 
 releases.

 don't ask me why they thinking like this. i don't know. but 
 it's the
 fact.
Can't it be addressed by publishing release schedule, like llvm does it, to indicate the work is going on?
Aug 20 2014
parent ketmar via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
On Wed, 20 Aug 2014 09:19:37 +0000
Kagamin via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 Can't it be addressed by publishing release schedule, like llvm=20
 does it, to indicate the work is going on?
hm. sounds reasonable. ;-)
Aug 20 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 18 August 2014 at 21:57:19 UTC, bearophile wrote:
 Vladimir Panteleev:

 I agree, I am also surprised that 2.066 was released despite 
 the regressions.
There is an apparently endless stream of regressions, I have found another today (https://issues.dlang.org/show_bug.cgi?id=13321 ). I think D is not yet at the stage of its development where it can hope to fix all the regressions. So if you try to wait for all regressions to be fixed, you never ship a compiler version, and this has serious disadvantages. So better to be a little more practical for now. 2.066 has took ages to come out, it was overdue. I hope 2.067 will come out much quicker. Bye, bearophile
I have checked the regression list daily since something like b3 - amount of "hard" regressions was steadily going down and many of newly added one were trivial and fixed quickly. Last time I checked there were only 2-3 really problematic cases (including one I have mentioned). Idea is quite simple - if we are incapable of doing compiler release without regressions, we should stop doing compiler releases until we learn how to do it. Risk of reputation damage we may get with 2.066 costs much more than delaying release even for several months. Remember, we are speaking about regressions, not even about critical bugs. I also propose to start 2.067 beta branch right now and declare it yet another bug-fixing release.
Aug 18 2014
next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Monday, 18 August 2014 at 23:14:45 UTC, Dicebot wrote:
 I also propose to start 2.067 beta branch right now and declare 
 it yet another bug-fixing release.
Isn't this what point-releases are for, though?
Aug 18 2014
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Monday, 18 August 2014 at 23:18:46 UTC, Vladimir Panteleev 
wrote:
 On Monday, 18 August 2014 at 23:14:45 UTC, Dicebot wrote:
 I also propose to start 2.067 beta branch right now and 
 declare it yet another bug-fixing release.
Isn't this what point-releases are for, though?
Why can't we have both? :) Point is that with current tempo it will take exactly 1.5-2 months to fix all stuff for next release if we start right now, otherwise it is likely to take as long as 2.066
Aug 18 2014
prev sibling parent reply "safety0ff" <safety0ff.dev gmail.com> writes:
On Monday, 18 August 2014 at 23:18:46 UTC, Vladimir Panteleev 
wrote:
 On Monday, 18 August 2014 at 23:14:45 UTC, Dicebot wrote:
 I also propose to start 2.067 beta branch right now and 
 declare it yet another bug-fixing release.
Isn't this what point-releases are for, though?
I agree, I think 2.066.next should be the focus considering the known issues of 2.066. On Monday, 18 August 2014 at 20:43:44 UTC, Vladimir Panteleev wrote:
 How is it decided when it's time to cut off a new release? Do 
 we have two RCs and that's it?
I find it hard to believe that it is just a coincidence that a surprise release occurred on the same day as Java 9 and C++14 announcements.
Aug 19 2014
next sibling parent reply Andrew Edwards <ridimz yahoo.com> writes:
On 8/20/14, 8:38 AM, safety0ff wrote:
 On Monday, 18 August 2014 at 23:18:46 UTC, Vladimir Panteleev wrote:
 On Monday, 18 August 2014 at 23:14:45 UTC, Dicebot wrote:
 I also propose to start 2.067 beta branch right now and declare it
 yet another bug-fixing release.
Isn't this what point-releases are for, though?
I agree, I think 2.066.next should be the focus considering the known issues of 2.066.
Fear not, point releases will address known deficiencies.
 On Monday, 18 August 2014 at 20:43:44 UTC, Vladimir Panteleev wrote:
 How is it decided when it's time to cut off a new release? Do we have
 two RCs and that's it?
I find it hard to believe that it is just a coincidence that a surprise release occurred on the same day as Java 9 and C++14 announcements.
Actually you can believe it. I am the one that called for the release and it pay ZERO attention to those two languages with the mild exception that when I have time I crack open a Java book to try to learn a little programming.
Aug 19 2014
next sibling parent "safety0ff" <safety0ff.dev gmail.com> writes:
On Wednesday, 20 August 2014 at 00:14:59 UTC, Andrew Edwards 
wrote:
 On 8/20/14, 8:38 AM, safety0ff wrote:
 I agree, I think 2.066.next should be the focus considering 
 the known
 issues of 2.066.
Fear not, point releases will address known deficiencies.
Btw, thank you for the good work you've done as release manager!
Aug 19 2014
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/19/14, 5:14 PM, Andrew Edwards wrote:
 Actually you can believe it. I am the one that called for the release
 and it pay ZERO attention to those two languages with the mild exception
 that when I have time I crack open a Java book to try to learn a little
 programming.
Yah, to amend my previous post: the release time was chosen by Andrew and the announcement time was chosen by me. Apparently neither of us knew about the other language announcements :o). -- Andrei
Aug 20 2014
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/19/14, 4:38 PM, safety0ff wrote:
 I find it hard to believe that it is just a coincidence that a surprise
 release occurred on the same day as Java 9 and C++14 announcements.
For my part I had no idea, and the exact announcement time was solely up to me. -- Andrei
Aug 20 2014
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 8/18/2014 7:14 PM, Dicebot wrote:
 I also propose to start 2.067 beta branch right now and declare it yet
 another bug-fixing release.
Seconded.
Aug 18 2014
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, 19 August 2014 at 00:23:22 UTC, Nick Sabalausky wrote:
 On 8/18/2014 7:14 PM, Dicebot wrote:
 I also propose to start 2.067 beta branch right now and 
 declare it yet
 another bug-fixing release.
Seconded.
Regardless of whether we start another release going that quickly or not, I think that we really need to figure out how to be doing regressionless releases more along the lines of 2 months apart. And if we're getting a lot of those, maybe we should operate more like the linux kernel, which has a merge window of something like a week after a release before they start turning that into the next release - in which case we would do something like continue to merge changes into master all the time but create a new branch and start regressing it within a week or two of actually completing the previous release. Certainly, I don't think that we should wait more than a month before branching, since if we took a month, that would leave a month to get all of the regressions ironed out and still have a 2 month release cycle, and with how things have been going, I'm not sure that we'd even manage to do that in a month. - Jonathan M Davis
Aug 18 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/18/14, 5:23 PM, Nick Sabalausky wrote:
 On 8/18/2014 7:14 PM, Dicebot wrote:
 I also propose to start 2.067 beta branch right now and declare it yet
 another bug-fixing release.
Seconded.
Well that's what happened - someone started 2.067. What's the advantage of doing this? Now we need to worry about master and 2.067 instead of just master. -- Andrei
Aug 18 2014
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, 19 August 2014 at 04:26:48 UTC, Andrei Alexandrescu 
wrote:
 Well that's what happened - someone started 2.067. What's the 
 advantage of doing this? Now we need to worry about master and 
 2.067 instead of just master. -- Andrei
Well, what you do at that point is just fix all of the regressions on the branch, and when it's ready you do another release. You don't put anything else on it. All of the normal dev work goes on master. And some point after the branch has been released as the next release, you branch again. Now, unless we have enough regressions on master that it's going to take us over a month to fix them, I think that branching right after releasing is a bit much, though if some of the regressions are bad enough, maybe it would make sense to release faster. And given how long we've been trying to get 2.066 ready after branching it and how much work has been done on master since then, maybe it makes sense. I don't know. I would have thought though that we'd aim to branch something like 2 to 4 weeks after releasing and then take about a month to make sure that all regressions are fixed so that we get a release about every two months. All the major dev work just continues on master, and it'll end up on a branch about every two months staggered from when that branch gets released as an official release. Certainly, aiming for something along those lines would get us faster releases than we've been doing. We've been waiting way too long to branch and then been rather slow about getting through all of the regressions. By branching earlier, we should be able to release more quickly. - Jonathan M Davis
Aug 18 2014
next sibling parent reply "Suliman" <evermind live.ru> writes:
Who could help with translation change logs to russian and 
publication it's on LOR?
Aug 18 2014
next sibling parent ketmar via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
On Tue, 19 Aug 2014 05:24:54 +0000
Suliman via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 Who could help with translation change logs to russian and=20
 publication it's on LOR?
DYI.
Aug 18 2014
prev sibling next sibling parent ketmar via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
On Tue, 19 Aug 2014 05:24:54 +0000
Suliman via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 Who could help with translation change logs to russian and=20
 publication it's on LOR?
sorry, i mean DIY. ;-)
Aug 18 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 19 August 2014 at 05:24:56 UTC, Suliman wrote:
 Who could help with translation change logs to russian and 
 publication it's on LOR?
Send me an e-mail if you need any help
Aug 19 2014
parent reply "Suliman" <evermind live.ru> writes:
On Tuesday, 19 August 2014 at 17:17:14 UTC, Dicebot wrote:
 On Tuesday, 19 August 2014 at 05:24:56 UTC, Suliman wrote:
 Who could help with translation change logs to russian and 
 publication it's on LOR?
Send me an e-mail if you need any help
Thanks user Lodin already did hight quality translation! Could you help me with:
I remember that it was planned to add functional future for 
iteration throw elements. Something like:
().times
().do
But I can't find original post about it and nothing related in 
changelogs...
Aug 19 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 19 August 2014 at 17:51:51 UTC, Suliman wrote:
 On Tuesday, 19 August 2014 at 17:17:14 UTC, Dicebot wrote:
 On Tuesday, 19 August 2014 at 05:24:56 UTC, Suliman wrote:
 Who could help with translation change logs to russian and 
 publication it's on LOR?
Send me an e-mail if you need any help
Thanks user Lodin already did hight quality translation! Could you help me with:
I remember that it was planned to add functional future for 
iteration throw elements. Something like:
().times
().do
But I can't find original post about it and nothing related in 
changelogs...
I remember merging this one : https://github.com/D-Programming-Language/phobos/pull/1965 , but it was after 2.066 branch has been created. There is also https://github.com/D-Programming-Language/phobos/pull/2024 but it is still in progress. I can't remember any other similar PR - probably it was merged before I started to do Phobos reviewing though.
Aug 19 2014
parent "Suliman" <evermind live.ru> writes:
 I remember merging this one : 
 https://github.com/D-Programming-Language/phobos/pull/1965 , 
 but it was after 2.066 branch has been created. There is also 
 https://github.com/D-Programming-Language/phobos/pull/2024 but 
 it is still in progress. I can't remember any other similar PR 
 - probably it was merged before I started to do Phobos 
 reviewing though.
Big thanks!
Aug 19 2014
prev sibling parent "Idan Arye" <GenericNPC gmail.com> writes:
On Tuesday, 19 August 2014 at 05:03:40 UTC, Jonathan M Davis 
wrote:
 On Tuesday, 19 August 2014 at 04:26:48 UTC, Andrei Alexandrescu 
 wrote:
 Well that's what happened - someone started 2.067. What's the 
 advantage of doing this? Now we need to worry about master and 
 2.067 instead of just master. -- Andrei
Well, what you do at that point is just fix all of the regressions on the branch, and when it's ready you do another release. You don't put anything else on it. All of the normal dev work goes on master. And some point after the branch has been released as the next release, you branch again. Now, unless we have enough regressions on master that it's going to take us over a month to fix them, I think that branching right after releasing is a bit much, though if some of the regressions are bad enough, maybe it would make sense to release faster. And given how long we've been trying to get 2.066 ready after branching it and how much work has been done on master since then, maybe it makes sense. I don't know. I would have thought though that we'd aim to branch something like 2 to 4 weeks after releasing and then take about a month to make sure that all regressions are fixed so that we get a release about every two months. All the major dev work just continues on master, and it'll end up on a branch about every two months staggered from when that branch gets released as an official release. Certainly, aiming for something along those lines would get us faster releases than we've been doing. We've been waiting way too long to branch and then been rather slow about getting through all of the regressions. By branching earlier, we should be able to release more quickly. - Jonathan M Davis
In that case, shouldn't it be 2.066.1?
Aug 19 2014
prev sibling parent reply Andrew Edwards <ridimz yahoo.com> writes:
On 8/19/14, 1:26 PM, Andrei Alexandrescu wrote:
 On 8/18/14, 5:23 PM, Nick Sabalausky wrote:
 On 8/18/2014 7:14 PM, Dicebot wrote:
 I also propose to start 2.067 beta branch right now and declare it yet
 another bug-fixing release.
Seconded.
Well that's what happened - someone started 2.067. What's the advantage of doing this? Now we need to worry about master and 2.067 instead of just master. -- Andrei
That was my doing... I am preparing myself for the next go around. The actual branch will be created on Sunday (24 Aug) for a Monday (0900 PDT) announcement. The beta cycle will run eight weeks following that. On the fourth week (22 Sept) I will transition from beta to RC. Betas will be release 5 days apart. RCs will be released 3 days apart. If no regression is fixed during that beta/RC window, the window will be extended an additional 3/5 days (as appropriate) until either fixes are received or the review period ends: at which time the final release is prepared and published. The only thing that will extend the review period is if a regression exiting at the time RC1 is released remains open at the end of the 8 weeks. At that time an additional week will be added to the release cycle to address those specific issues. If they cannot be addressed during that additional week, the cycle will be terminated and the final release published. All regressions not addressed in the main release will be addressed in point releases. Point releases will be published in 2 week increments following the final release (as warranted). Starting with 2.066, releases will be maintained for 1 year. Meaning, point releases will be published biweekly (as warranted) for 1 year after a major release. The only changes that will be pushed during point releases are known regressions and ICE. To pull this off, I absolutely need the community's assistance. Issues must clearly indicate which version affected by a particular regression. A volunteer to help me track and categorize ice and regressions would do wonders. Also, I need access to publish and upload to the s3 server. I cannot wait around on for files to be synched across servers or web pages to be updated with one word changes before I can take the next step, it is extremely time consuming and deteriorates productivity. Note: there will normally be a 4 week break between release cycles. When a cycle is extended, the break will be reduced to 3 weeks. This particular cycle will start early because 2.066 ended 5 weeks after the planned release date. Andrew
Aug 19 2014
next sibling parent ketmar via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
On Wed, 20 Aug 2014 10:41:29 +0900
Andrew Edwards via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

btw. http://wiki.dlang.org/Beta_Testing contains bug #10928 as
"blocker", but it's marked as "RESOLVED FIXED" in bugzilla. and bug
#12696 needs to be rechecked, as it seems to be fixed too.
Aug 19 2014
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 20/08/14 03:41, Andrew Edwards wrote:

 That was my doing... I am preparing myself for the next go around. The
 actual branch will be created on Sunday (24 Aug) for a Monday (0900 PDT)
 announcement. The beta cycle will run eight weeks following that. On the
 fourth week (22 Sept) I will transition from beta to RC.

 Betas will be release 5 days apart. RCs will be released 3 days apart.
 If no regression is fixed during that beta/RC window, the window will be
 extended an additional 3/5 days (as appropriate) until either fixes are
 received or the review period ends: at which time the final release is
 prepared and published.

 The only thing that will extend the review period is if a regression
 exiting at the time RC1 is released remains open at the end of the 8
 weeks. At that time an additional week will be added to the release
 cycle to address those specific issues. If they cannot be addressed
 during that additional week, the cycle will be terminated and the final
 release published.

 All regressions not addressed in the main release will be addressed in
 point releases. Point releases will be published in 2 week increments
 following the final release (as warranted).
I we're letting regressions through in the main release I'm wondering how likely they are to be fixed later.
 Starting with 2.066, releases will be maintained for 1 year. Meaning,
 point releases will be published biweekly (as warranted) for 1 year
 after a major release. The only changes that will be pushed during point
 releases are known regressions and ICE.

 To pull this off, I absolutely need the community's assistance. Issues
 must clearly indicate which version affected by a particular regression.
 A volunteer to help me track and categorize ice and regressions would do
 wonders.

 Also, I need access to publish and upload to the s3 server. I cannot
 wait around on for files to be synched across servers or web pages to be
 updated with one word changes before I can take the next step, it is
 extremely time consuming and deteriorates productivity.

 Note: there will normally be a 4 week break between release cycles. When
 a cycle is extended, the break will be reduced to 3 weeks. This
 particular cycle will start early because 2.066 ended 5 weeks after the
 planned release date.
All this should be written down somewhere in the wiki. -- /Jacob Carlborg
Aug 19 2014
prev sibling next sibling parent Iain Buclaw via Digitalmars-d-announce writes:
On 20 August 2014 02:41, Andrew Edwards via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:
 On 8/19/14, 1:26 PM, Andrei Alexandrescu wrote:
 On 8/18/14, 5:23 PM, Nick Sabalausky wrote:
 On 8/18/2014 7:14 PM, Dicebot wrote:
 I also propose to start 2.067 beta branch right now and declare it yet
 another bug-fixing release.
Seconded.
Well that's what happened - someone started 2.067. What's the advantage of doing this? Now we need to worry about master and 2.067 instead of just master. -- Andrei
That was my doing... I am preparing myself for the next go around. The actual branch will be created on Sunday (24 Aug) for a Monday (0900 PDT) announcement. The beta cycle will run eight weeks following that. On the fourth week (22 Sept) I will transition from beta to RC.
Hurrah! Iain
Aug 20 2014
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/19/14, 6:41 PM, Andrew Edwards wrote:
 On 8/19/14, 1:26 PM, Andrei Alexandrescu wrote:
 On 8/18/14, 5:23 PM, Nick Sabalausky wrote:
 On 8/18/2014 7:14 PM, Dicebot wrote:
 I also propose to start 2.067 beta branch right now and declare it yet
 another bug-fixing release.
Seconded.
Well that's what happened - someone started 2.067. What's the advantage of doing this? Now we need to worry about master and 2.067 instead of just master. -- Andrei
That was my doing... I am preparing myself for the next go around. The actual branch will be created on Sunday (24 Aug) for a Monday (0900 PDT) announcement. The beta cycle will run eight weeks following that. On the fourth week (22 Sept) I will transition from beta to RC.
[snip] Love the systematic approach. Thanks! -- Andrei
Aug 20 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 18/08/14 22:43, Vladimir Panteleev wrote:

 I agree, I am also surprised that 2.066 was released despite the
 regressions.
Same here.
 How is it decided when it's time to cut off a new release? Do we have
 two RCs and that's it?
It seems Andrei/Walter is very stressed to get the release out. -- /Jacob Carlborg
Aug 19 2014
prev sibling parent "eles" <eles215 gzk.dot> writes:
On Monday, 18 August 2014 at 19:23:14 UTC, Dicebot wrote:

 I don't know if we can do anything better about it.
2.067
Aug 18 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/18/2014 12:00 PM, 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
126 contributors, to be precise!
Aug 18 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 18 August 2014 at 19:47:52 UTC, Walter Bright wrote:
 On 8/18/2014 12:00 PM, 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
126 contributors, to be precise!
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.
Aug 19 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/19/14, 7:01 AM, Dicebot wrote:
 On Monday, 18 August 2014 at 19:47:52 UTC, Walter Bright wrote:
 On 8/18/2014 12:00 PM, 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
126 contributors, to be precise!
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.
LGTM. Any opposition to merging? -- Andrei
Aug 19 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 19 August 2014 at 21:13:53 UTC, Andrei Alexandrescu 
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.
LGTM. Any opposition to merging? -- Andrei
Walter seems to be the only one :) http://forum.dlang.org/post/lt00a9$2uoe$1 digitalmars.com
Aug 19 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/19/14, 3:09 PM, Dicebot wrote:
 On Tuesday, 19 August 2014 at 21:13:53 UTC, Andrei Alexandrescu 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.
LGTM. Any opposition to merging? -- Andrei
Walter seems to be the only one :) http://forum.dlang.org/post/lt00a9$2uoe$1 digitalmars.com
I think it would be great to motivate the change properly. -- Andrei
Aug 19 2014
next sibling parent ketmar via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
On Tue, 19 Aug 2014 15:27:34 -0700
Andrei Alexandrescu via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 I think it would be great to motivate the change properly. -- Andrei
aren't it motivated enough in PR? this will allow to build real package hierarchies instead of dumping everything in one flat package. my.package, my.package.internal, my.package.network, my.package.utils, etc. it's very convient and fits good in package system. we'll have modules, packages and package hierarchies, and everyone will be free to choose what he needs. modules for tiny projects, packages for small libraries, package hierarchies for big libraries (like phobos).
Aug 19 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 19 August 2014 at 22:27:28 UTC, Andrei Alexandrescu 
wrote:
 On 8/19/14, 3:09 PM, Dicebot wrote:
 On Tuesday, 19 August 2014 at 21:13:53 UTC, Andrei 
 Alexandrescu 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.
LGTM. Any opposition to merging? -- Andrei
Walter seems to be the only one :) http://forum.dlang.org/post/lt00a9$2uoe$1 digitalmars.com
I think it would be great to motivate the change properly. -- Andrei
I am not sure what can I add to what have been already said. To summarize: Without this addition package.d is much less useful in practice - we can't separate existing modules into smaller packages without making almost all symbols public, not if at there is more there one level of nested packages in question. Dmitry needs it for splitting std.regex, it will be needed for std.meta, existing std.internal can actually become controlled by compiler instead of being undocumented convention. And using more deeply nested module hiearchies with smaller modules is one of primary means for reducing internal Phobos dependencies and improving compile times that are currently lacking. It is also 100% backwards compatible and does not introduce any new language concept being much less intrusive change than, for example, C++ namespace support recently added.
Aug 19 2014
prev sibling parent reply "disapointed user" <disapointed aol.com> writes:
thank you general for your selfish and user considered release.
the lieutenants probably feel kind of really taken care of - as 
well as D users.
how do you test and release at facebook.
i am a user that considers to leave after many years. i am 
starting to dislike the language, as it is getting blown up and 
the the syntax getting ever weirder, less mainstream and a 
support for windows that really sucks.

good luck in the future for all you guys



On Tuesday, 19 August 2014 at 22:27:28 UTC, Andrei Alexandrescu 
wrote:
 On 8/19/14, 3:09 PM, Dicebot wrote:
 On Tuesday, 19 August 2014 at 21:13:53 UTC, Andrei 
 Alexandrescu 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.
LGTM. Any opposition to merging? -- Andrei
Walter seems to be the only one :) http://forum.dlang.org/post/lt00a9$2uoe$1 digitalmars.com
I think it would be great to motivate the change properly. -- Andrei
Aug 20 2014
next sibling parent reply ketmar via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
On Wed, 20 Aug 2014 09:15:53 +0000
disapointed user via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 support for windows that really sucks.
that is 'cause windows really sucks.
 good luck in the future for all you guys
you too.
Aug 20 2014
parent reply "disapointed user" <disapointed aol.com> writes:
too bad that i wasted my time for such a long time. i post a link 
to that thread with your answer to everywhere i can, so that 
others won't waste their time too.

anyway good luck in the future for you linux guys.



On Wednesday, 20 August 2014 at 09:37:24 UTC, ketmar via 
Digitalmars-d-announce wrote:
 On Wed, 20 Aug 2014 09:15:53 +0000
 disapointed user via Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com> wrote:

 support for windows that really sucks.
that is 'cause windows really sucks.
 good luck in the future for all you guys
you too.
Aug 20 2014
parent "Kagamin" <spam here.lot> writes:
On Wednesday, 20 August 2014 at 16:25:04 UTC, disapointed user 
wrote:
 too bad that i wasted my time for such a long time. i post a 
 link to that thread with your answer to everywhere i can, so 
 that others won't waste their time too.

 anyway good luck in the future for you linux guys.
Well, people have different perspectives :) see http://forum.dlang.org/post/lrsnjovurigezboqxnba forum.dlang.org
Aug 21 2014
prev sibling next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Wednesday, 20 August 2014 at 09:15:54 UTC, disapointed user 
wrote:
 thank you general for your selfish and user considered release.
 the lieutenants probably feel kind of really taken care of - as 
 well as D users.
 how do you test and release at facebook.
 i am a user that considers to leave after many years. i am 
 starting to dislike the language, as it is getting blown up and 
 the the syntax getting ever weirder, less mainstream and a 
 support for windows that really sucks.

 good luck in the future for all you guys
Anything specific you have problems with? Syntax changes aren't all that common these days (*dodges rock thrown by Brian Schott*) and Windows support is pretty solid. What I consider to be the last remaining large piece, 32-bit COFF support, was just merged.
Aug 20 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 20/08/14 18:57, Brad Anderson wrote:

 Anything specific you have problems with? Syntax changes aren't all that
 common these days
Support for C++ namespaces where just released and support for C++ templates will most likely end up in master soon. -- /Jacob Carlborg
Aug 20 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Jacob Carlborg"  wrote in message news:lt43pj$ral$1 digitalmars.com...

 Support for C++ namespaces where just released and support for C++ 
 templates will most likely end up in master soon.
Support for C++ templates was in the last release, and the new pull request is only for special mangling of some stl declarations.
Aug 21 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 21/08/14 12:10, Daniel Murphy wrote:

 Support for C++ templates was in the last release, and the new pull
 request is only for special mangling of some stl declarations.
You see, I get confused of all the syntax changes ;) -- /Jacob Carlborg
Aug 21 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Jacob Carlborg"  wrote in message news:lt50m0$20f0$1 digitalmars.com... 

 Support for C++ templates was in the last release, and the new pull
 request is only for special mangling of some stl declarations.
You see, I get confused of all the syntax changes ;)
Don't worry, so did Walter.
Aug 21 2014
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, 21 August 2014 at 15:20:49 UTC, Daniel Murphy wrote:
 "Jacob Carlborg"  wrote in message 
 news:lt50m0$20f0$1 digitalmars.com...

 Support for C++ templates was in the last release, and the 
 new pull
 request is only for special mangling of some stl 
 declarations.
You see, I get confused of all the syntax changes ;)
Don't worry, so did Walter.
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? - Jonathan M Davis
Aug 21 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/21/2014 11:54 AM, Jonathan M Davis wrote:
 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?
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. 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. There are no plans for actually compiling C++ code with a D compiler. The plan is for support like we do for C - have a .d "header" file for it.
Aug 21 2014
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, 21 August 2014 at 20:33:56 UTC, Walter Bright wrote:
 On 8/21/2014 11:54 AM, Jonathan M Davis wrote:
 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?
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. 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. There are no plans for actually compiling C++ code with a D compiler. The plan is for support like we do for C - have a .d "header" file for it.
Well, I wouldn't have expected us to be compiling C++ per se, but previously, it seemed like the party line was that we wouldn't be supporting C++ templates at all because of how hard they were and because we don't want a C++ compiler in the D compiler. I'm certainly all for anything we can do for C++ compatability without going off the deep end. I just don't hear much about what we're actually doing right now. So, I really have no idea what the current status of that is. With what was said at dconf and comments like these, it seems like we're making huge progress in comparison to where we were, and as far as I can tell, about the only way to hear about it is to either pay a lot of attention to dmd pulls or to see an occasonal comment from Daniel talking about it or from someone who's paying close attention to what he's up to. So, at some point in the near future, it would be nice if there were somewhere that actually said what D can actually do with C++ now, even if that doesn't include everything that's going to be coming or if much of it is marked as experimental and relatively untested. - Jonathan M Davis
Aug 21 2014
parent reply "bachmeier" <no spam.com> writes:
On Thursday, 21 August 2014 at 20:43:53 UTC, Jonathan M Davis 
wrote:
 On Thursday, 21 August 2014 at 20:33:56 UTC, Walter Bright 
 wrote:
 On 8/21/2014 11:54 AM, Jonathan M Davis wrote:
 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?
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. 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. There are no plans for actually compiling C++ code with a D compiler. The plan is for support like we do for C - have a .d "header" file for it.
Well, I wouldn't have expected us to be compiling C++ per se, but previously, it seemed like the party line was that we wouldn't be supporting C++ templates at all because of how hard they were and because we don't want a C++ compiler in the D compiler. I'm certainly all for anything we can do for C++ compatability without going off the deep end. I just don't hear much about what we're actually doing right now. So, I really have no idea what the current status of that is. With what was said at dconf and comments like these, it seems like we're making huge progress in comparison to where we were, and as far as I can tell, about the only way to hear about it is to either pay a lot of attention to dmd pulls or to see an occasonal comment from Daniel talking about it or from someone who's paying close attention to what he's up to. So, at some point in the near future, it would be nice if there were somewhere that actually said what D can actually do with C++ now, even if that doesn't include everything that's going to be coming or if much of it is marked as experimental and relatively untested. - Jonathan M Davis
It would be nice to have a page to link to when questions come up on Reddit about compatibility with C++. That page should also have information about avoiding the garbage collector and the status of GC removal from the standard library.
Aug 21 2014
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
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).
Aug 22 2014
parent "bachmeier" <no spam.net> writes:
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.
Aug 22 2014
prev sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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?
Aug 22 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Aug 22 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Aug 22 2014
prev sibling parent reply "Mike" <none none.com> writes:
On Friday, 22 August 2014 at 08:23:39 UTC, Daniel Murphy wrote:
 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?
What's the motivation for embedding these things in the d runtime? Wouldn't it be better to have a libc_d instead of core.stdc, libcpp_d instead of core.stdcpp, liblinux_d instead of core.sys.linux, etc...? I thought the D runtime was supposed to be simply an implementation of the language features, but it appears its scope is much more broad. This makes the language coupled to those platforms and less general purpose like C and C++. Mike
Aug 25 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Mike"  wrote in message news:sdrjfagsayomsngmeywp forum.dlang.org...

 What's the motivation for embedding these things in the d runtime?
Make them available.
 Wouldn't it be better to have a libc_d instead of core.stdc, libcpp_d 
 instead of core.stdcpp, liblinux_d instead of core.sys.linux, etc...?
I don't see how.
 I thought the D runtime was supposed to be simply an implementation of the 
 language features, but it appears its scope is much more broad.
Language features (gc, profiler, etc), OS bindings, C stdlib bindings. C++ bindings aren't a big leap from there. I think druntime started off including OS and stdlib bindings because it needed to use them internally, and it made more sense to expose them publically instead of adding dependencies or duplicating them.
 This makes the language coupled to those platforms and less general 
 purpose like C and C++.
I disagree. D does not depend on C++ being available, but druntime should provide bindings if possible. Depending on the C runtime is not a problem, because realistically you will either have a C runtime available for your platform, or be on a restricted platform where you will need to define your own D runtime, and can choose which parts of the C runtime to include.
Aug 25 2014
parent reply "Mike" <none none.com> writes:
On Tuesday, 26 August 2014 at 05:03:01 UTC, Daniel Murphy wrote:
 "Mike"  wrote in message 
 news:sdrjfagsayomsngmeywp forum.dlang.org...

 What's the motivation for embedding these things in the d 
 runtime?
Make them available.
 Wouldn't it be better to have a libc_d instead of core.stdc, 
 libcpp_d instead of core.stdcpp, liblinux_d instead of 
 core.sys.linux, etc...?
I don't see how.
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 thought the D runtime was supposed to be simply an 
 implementation of the language features, but it appears its 
 scope is much more broad.
Language features (gc, profiler, etc), OS bindings, C stdlib bindings. C++ bindings aren't a big leap from there. I think druntime started off including OS and stdlib bindings because it needed to use them internally, and it made more sense to expose them publically instead of adding dependencies or duplicating them.
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. 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.
 This makes the language coupled to those platforms and less 
 general purpose like C and C++.
I disagree. D does not depend on C++ being available, but druntime should provide bindings if possible. Depending on the C runtime is not a problem, because realistically you will either have a C runtime available for your platform, or be on a restricted platform where you will need to define your own D runtime, and can choose which parts of the C runtime to include.
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. 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. Mike [1] https://issues.dlang.org/show_bug.cgi?id=11666
Aug 25 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Aug 25 2014
next sibling parent reply "Ola Fosheim Gr" <ola.fosheim.grostad+dlang gmail.com> writes:
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...
Aug 26 2014
parent reply Jonathan M Davis via Digitalmars-d-announce writes:
On Tue, 26 Aug 2014 07:00:26 +0000
Ola Fosheim Gr via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> 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
Aug 26 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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…
Aug 26 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Ola Fosheim Grøstad" " wrote in message 
news:pbfaphgiugafrhachewl 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.
Aug 26 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Aug 26 2014
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Ola Fosheim Grøstad" " wrote in message 
news:mclztlymyjydwhcxsepk 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.
Aug 26 2014
prev sibling parent "Mike" <none none.com> writes:
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 :(
Aug 26 2014
prev sibling next sibling parent reply "eles" <eles eles.com> writes:
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:sdrjfagsayomsngmeywp 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.
Aug 26 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Aug 26 2014
next sibling parent reply "Mike" <none none.com> writes:
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.
Aug 26 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Aug 26 2014
prev sibling parent reply "eles" <eles eles.com> writes:
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.
Aug 26 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Aug 26 2014
prev sibling next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
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.
Aug 26 2014
parent reply "Mike" <none none.com> writes:
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
Aug 26 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Aug 26 2014
next sibling parent reply "Mike" <none none.com> writes:
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
Aug 26 2014
next sibling parent reply "eles" <eles eles.com> writes:
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.
Aug 26 2014
parent "Mike" <none none.com> writes:
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".
Aug 26 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Aug 26 2014
next sibling parent reply "eles" <eles215 gzk.dot> writes:
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" :)
Aug 26 2014
parent "eles" <eles215 gzk.dot> writes:
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
Aug 26 2014
prev sibling parent "eles" <eles215 gzk.dot> writes:
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.
Aug 26 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Aug 26 2014
parent reply "Mike" <none none.com> writes:
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
Aug 26 2014
next sibling parent "Mike" <none none.com> writes:
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.
Aug 26 2014
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
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.
Aug 26 2014
parent reply "Mike" <none none.com> writes:
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?
Aug 26 2014
parent reply "Dicebot" <public dicebot.lv> writes:
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.
Aug 26 2014
parent "Mike" <none none.com> writes:
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.
Aug 27 2014
prev sibling next sibling parent reply "Mike" <none none.com> writes:
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
Aug 26 2014
parent reply "Sean Kelly" <sean invisibleduck.org> writes:
On Wednesday, 27 August 2014 at 04:23:28 UTC, Mike wrote:
 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.
The reason these are in Druntime at all is because code in Druntime depends on them. So if they were split into a separate library then it would be a required library. And even if we completely eliminate any dependency on standard C functions, I don't see any way to avoid depending on platform-specific calls. Now I would be fine with including just a subset of declarations in Druntime (which is really what we have right now anyway), but if the remainder were split into a standalone library then things start to get weird. Please let me know if you have a solution to this problem.
Aug 29 2014
parent "Mike" <none none.com> writes:
On Friday, 29 August 2014 at 16:37:12 UTC, Sean Kelly wrote:
 On Wednesday, 27 August 2014 at 04:23:28 UTC, Mike wrote:
 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.
The reason these are in Druntime at all is because code in Druntime depends on them. So if they were split into a separate library then it would be a required library. And even if we completely eliminate any dependency on standard C functions, I don't see any way to avoid depending on platform-specific calls. Now I would be fine with including just a subset of declarations in Druntime (which is really what we have right now anyway), but if the remainder were split into a standalone library then things start to get weird. Please let me know if you have a solution to this problem.
I'm not suggesting we eliminate libc and platform-specific bindings, just encapsulate and isolate them. To make D work on any platform, druntime must be ported to that platform. To do the port, of course we have to make platform-specific calls. That's no problem. But they should be internally encapsulated in that port's logic, not publicly exposed. And if we implement 11666 we should isolate each port to its own folder so the abstraction between language and platform is clear. For example (what druntime may look like many years from now): If a port chooses to use libc, no problem. Just encapsulate the bindings in its own file/folder. Don't make it publicly available. If D programmers want bindings to libc in their programs, they should use std.c in phobos (or we could simply move core.stdc to phobos). This means that we may have duplicate bindings in druntime and std.c for the few features of libc that are required to implement the port. This isn't really a duplication of code as it should just be type declarations and function signatures - just information for the linker. Some time in the future, many years from now, it would be nice if gradually those C bindings were replaced with D implementations to throw out the middle-man and put the port directly on the platform. There's absolutely no hurry, and if it's never done, so be it. Now what about the stuff in core.sys.whateverOS? It's the same thing. Certainly these are needed to port druntime to a given platform, but they are an implementation detail of the port, not the language. Again they should be encapsulated and isolated. If users want to make calls to whateverOS libs, than we can either move core.sys.whateverOS to phobos, or create a new namespace std.whateverOS or whatever namespace name you want, and users can use that. Just get it out of the way of the language implementation. But NONE of this needs to be done right now, or even this year, or even next year. All I'm asking for with this thread is that instead of making it harder to move away from the current structure by adding core.stdcpp to druntime, we simply choose to put the C++ standard library bindings in std.cpp in phobos. Or you could choose to keep it as core.stdcpp, but just put it in phobos instead of druntime. The C++ standard library bindings don't exist yet. There's nothing to change. It's just a design decision. What do you want druntime to look like in 10 years? Let's make sure we're pointed in that direction with the C++ standard library bindings. Mike
Aug 30 2014
prev sibling next sibling parent "eles" <eles215 gzk.dot> writes:
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.
Aug 26 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Aug 26 2014
next sibling parent "eles" <eles eles.com> writes:
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."
Aug 27 2014
prev sibling next sibling parent reply "Mike" <none none.com> writes:
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.
Aug 27 2014
parent reply "Sean Kelly" <sean invisibleduck.org> writes:
On Wednesday, 27 August 2014 at 09:43:03 UTC, Mike wrote:
 On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright 
 wrote:
 The irony is D1 has std.c, and for D2 it was migrated to 
 core.stdc.
...and design takes the backseat to convenience.
This was a necessary part of the separation of the runtime components of the standard library from the extraneous stuff. Consider Druntime to be roughly equivalent to the java.lang package. It contains code and interfaces that pertain to the language definition, plus certain related low-level functionality. It will always be a judgement call for where to draw the line. For example, should Range be in Druntime since it's something the compiler is aware of? What about basic math routines that the compiler might replace with an intrinsic call? So far, we've actually erred on the side of having less in Druntime rather than more. It currently contains user-visible code that's actually required for every D application: the GC, threads, bit operations, and atomics, plus some additional code and declarations that are required to implement these features. And that's it. You might argue that Druntime shouldn't exist as a separate library at all, and at times I've wondered this myself, but some of the reasons for this have really borne out in practice, such as the forced elimination of unnecessary dependencies. If you look at D1 you'll find that the better part of the standard library is linked with every D application because some stuff that's always included (the GC code and what's in dmain, for example) uses high-level code which in turn depends on everything else. And while it's possible to avoid this with proper discipline, this is much easier to accomplish if the code simply isn't available in the first place. When making these arguments, please try thinking about the library from the perspective of a library designer and not an end user. Does the standard C interface truly belong in Phobos? In Druntime? Elsewhere? Why? And what factors might influence your decision? Are any of these factors currently present? Some of the reasons for the current design are historic and unnecessary and others are not. And anything can be changed if someone comes up with a better idea and is willing to do the work to make it so. It sounds like maybe you have a better idea so why not submit a pull request demonstrating the solution?
Aug 29 2014
parent reply "Mike" <none none.com> writes:
On Friday, 29 August 2014 at 16:54:18 UTC, Sean Kelly wrote:
 On Wednesday, 27 August 2014 at 09:43:03 UTC, Mike wrote:
 On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright 
 wrote:
 The irony is D1 has std.c, and for D2 it was migrated to 
 core.stdc.
...and design takes the backseat to convenience.
This was a necessary part of the separation of the runtime components of the standard library from the extraneous stuff. Consider Druntime to be roughly equivalent to the java.lang package. It contains code and interfaces that pertain to the language definition, plus certain related low-level functionality.
I don't believe it was necessary. D is quite capable of implementing the same logic that libc has. However, if for convenience, expediency, time-tested-reliance, optimization, or some other reason, one wishes to use libc, they can encapsulate it in the platform-specific logic, because that's what it is.
 It will always be a judgement call for where to draw the line.
 For example, should Range be in Druntime since it's something 
 the
 compiler is aware of?  What about basic math routines that the
 compiler might replace with an intrinsic call?  So far, we've
 actually erred on the side of having less in Druntime rather 
 than
 more.  It currently contains user-visible code that's actually
 required for every D application: the GC, threads, bit
 operations, and atomics, plus some additional code and
 declarations that are required to implement these features.  And
 that's it.
If D is defined as a garbage-collected language, then it makes sense for the GC to be in druntime. If D is defined as a language the intrinsically supports threads, then that belongs in druntime, etc... But D is not defined as a superset of libc, or a standard operating system API, so there is no reason to publicly expose these. My argument can be limited to core.stdc/stdcpp for now. * Only a very limited subset of libc is needed by druntime * These can be eliminated by implementing them in D, or by using what the platform provides (kernel libs, etc...). It may not be convenient/expedient to do so, and will take significant effort and testing, but I'm not saying it needs to be done right now, just that it should be a goal. * If it is decided to keep them for convenience/expediency or another reason, they can be encapsulated by the ports that need them rather than publicly exposed. D could be so much more than what it currently is. What I eventually would like to see is the following ports: Architecture (bare metal) ports: ------------------------------- X86 X86_64 ARM9 ARM7M MIPS etc.. OS Ports -------- Windows Posix Linux MacOS etc... I believe that list shows what a narrow focus D currently has. While a libc exists for all of these, and it might be convenient to use it, it is not necessary given D's capabilities. D could do it all, and I think that would set D apart from many other languages if it did. That being said, it certainly would be convenient to make use of libc for many of these ports, so let's use it. Just encapsulate it so if, in the future, someone like me wants to submit pull requests to gradually remove the dependency on libc, they can do so without breaking the API and causing controversy.
 You might argue that Druntime shouldn't exist as a separate
 library at all, and at times I've wondered this myself, but some
 of the reasons for this have really borne out in practice, such
 as the forced elimination of unnecessary dependencies.  If you
 look at D1 you'll find that the better part of the standard
 library is linked with every D application because some stuff
 that's always included (the GC code and what's in dmain, for
 example) uses high-level code which in turn depends on 
 everything
 else.  And while it's possible to avoid this with proper
 discipline, this is much easier to accomplish if the code simply
 isn't available in the first place.
I think it is good design to separate the implementation of the language spec and compiler intrinsics from library functions that implement domain-specific logic or commonly used utility functions even if they are considered "low-level". If one thinks of druntime as a low-level library, there's no reason to separate it from phobos. But if it's thought of as the language implementation, as I do, then the reason to separate the two is quite apparent, and the boundary between the two is quite stark.
 When making these arguments, please try thinking about the
 library from the perspective of a library designer and not an 
 end
 user.  Does the standard C interface truly belong in Phobos?  In
 Druntime?  Elsewhere?  Why?  And what factors might influence
 your decision?  Are any of these factors currently present?  
 Some
 of the reasons for the current design are historic and
 unnecessary and others are not.  And anything can be changed if
 someone comes up with a better idea and is willing to do the 
 work
 to make it so.  It sounds like maybe you have a better idea so
 why not submit a pull request demonstrating the solution?
I do have what I believe to be a better solution, and I believe I have articulated it, but it needs community support to go anywhere. I must have a different view of druntime than the rest of this community. I believe it should be an implementation of the language spec, compiler intrinsics, and encapsulated/isolated platform-specific logic. I don't see it as a low-level library. Low-level libraries are just another namespace in phobos. I don't see how one can even define a "low-level library" and that is probably why the line between phobos and druntime looks so blurry to some. In this thread, I'm simply trying to avoid having core.stdcpp thrown in the druntime when I'm trying to move core.stdc to std.c. It is wise to first use these forums to check for support first, before much time and energy is spent on work that will just be rejected. Take a look at all the work that went into DIP62 and how that worked out for the author. I'm judging by both the responses in this thread and the lack of responses in this thread that there isn't support, so I'm fine to go my own way with my ideas if that's what's preferred. Mike
Aug 29 2014
parent reply "eles" <eles215 gzk.dot> writes:
On Saturday, 30 August 2014 at 00:01:50 UTC, Mike wrote:
 On Friday, 29 August 2014 at 16:54:18 UTC, Sean Kelly wrote:
 On Wednesday, 27 August 2014 at 09:43:03 UTC, Mike wrote:
 On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright 
 wrote:
 I'm judging by both the responses in this thread and the lack 
 of responses in this thread that there isn't support, so I'm 
 fine to go my own way with my ideas if that's what's preferred.
Actuall, I am very much in favor of this, but I admit we are a bit in minority. I fel it is not because people ara gainst it, but because they feel is not very important. Plus, they have the impression that this will involve renaming modules and will need modifying curent source code. It is not about that. Names could remain just as they are, it is only about isolating that part of druntime that is really critical to run the language. As you defined very well, that part that corresponds to java.lang. There is one thing that bothers me, still, and I did not find the appropriate solution to it: if the language defines threads and garbage collector, I agree the mechanism for those should go in the runtime, but what to do with the function required to handle those? For example, creating a thread is done with a function (not with a keyword!) and the same goes for the GC.disable(), for example. So, this will kinda break the "runtime means no imports" mantra. Or, otherwise, how to do it? C++ fully accepted its dependency on stdlib when they wen with Threads, isn't? I find it uneasy that one accesses the runtime through "import". Why we should need that? In C you never import/include something for the runtime, nor you have control over it from inside the program. It is through compiler params.
Aug 30 2014
parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Saturday, 30 August 2014 at 08:39:12 UTC, eles wrote:
 On Saturday, 30 August 2014 at 00:01:50 UTC, Mike wrote:
 On Friday, 29 August 2014 at 16:54:18 UTC, Sean Kelly wrote:
 On Wednesday, 27 August 2014 at 09:43:03 UTC, Mike wrote:
 On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright 
 wrote:
 I'm judging by both the responses in this thread and the lack 
 of responses in this thread that there isn't support, so I'm 
 fine to go my own way with my ideas if that's what's preferred.
Actuall, I am very much in favor of this, but I admit we are a bit in minority. I fel it is not because people ara gainst it, but because they feel is not very important.
For the record: This describes my stance, too. I acknowledge that it would be cleaner to separate the C bindings in a dedicated package outside of druntime (though druntime could then import this library instead of keeping its own copy of some bindings around). This package could then contain bindings to higher-level libraries, too. I just don't see it as a pressing issue, nor are there obvious disadvantages to the current situation, from what I can tell.
 Plus, they have the impression that this will involve renaming 
 modules and will need modifying curent source code.

 It is not about that. Names could remain just as they are, it 
 is only about isolating that part of druntime that is really 
 critical to run the language. As you defined very well, that 
 part that corresponds to java.lang.

 There is one thing that bothers me, still, and I did not find 
 the appropriate solution to it: if the language defines threads 
 and garbage collector, I agree the mechanism for those should 
 go in the runtime, but what to do with the function required to 
 handle those? For example, creating a thread is done with a 
 function (not with a keyword!) and the same goes for the 
 GC.disable(), for example.

 So, this will kinda break the "runtime means no imports" 
 mantra. Or, otherwise, how to do it? C++ fully accepted its 
 dependency on stdlib when they wen with Threads, isn't?
I don't agree with this mantra, however. It makes sense for internally used functions like _d_throw, but it is fully acceptable IMO to treat some modules under core.* as part of the language that have to be imported when required.
 I find it uneasy that one accesses the runtime through 
 "import". Why we should need that? In C you never 
 import/include something for the runtime, nor you have control 
 over it from inside the program. It is through compiler params.
There are some very low-level things for which you have to include header files. varargs for one, setjmp/longjmp, exit()... I would argue that these are parts of the language that happen to be implemented in the standard library (I don't know how exactly the specification treats them, however).
Aug 30 2014
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
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 .
Aug 27 2014
next sibling parent reply "Sean Kelly" <sean invisibleduck.org> writes:
On Wednesday, 27 August 2014 at 21:38:04 UTC, deadalnix wrote:
 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 .
To be fair, the only part you bring with you are the dependencies that Druntime itself has. And nearly all of core.stdc is declarations anyway, so the only code bloat is unused ModuleInfo objects (notice that in places where Druntime uses C structs it declares them as "=void" to avoid depending on default initialization). The remaining issue becomes one of maintenance. If Druntime only declares the functions it needs, then where does the other stuff live? If you want to use that other library to get everything, does it publicly import core.stdc for the basics? What if Druntime needs a new call for some reason that's in this separate library? Do we declare it in core.stdc and cause collisions? What if D is ported to a new platform? That may require a whole raft of new declarations, both in a common API like core.stdc and in something more targeted like core.sys.linux. Don't get me wrong, I hate having to maintain the modules in core.stdc and core.sys. It's the worst job ever. I'm just not aware of a better solution to this particular problem.
Aug 29 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/29/14, 10:02 AM, Sean Kelly wrote:
 Don't get me wrong, I hate having to maintain the modules in
 core.stdc and core.sys.  It's the worst job ever.
It's also one of those jobs silently appreciated by many. -- Andrei
Aug 29 2014
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/27/2014 2:38 PM, deadalnix wrote:
 The problem is that you don't always want to bring libc and libstdc++ with you
 with every single project you write.
Remember that a library is not simply inserted bodily into the executable. A library is searched for modules that define unresolved symbols. I.e. only if you use code that refers to libc or libstd++ will those bits be linked in.
Aug 29 2014
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
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.
Aug 26 2014
parent "deadalnix" <deadalnix gmail.com> writes:
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).
Aug 26 2014
prev sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Mike"  wrote in message news:zjscnxerhbxnopvayxjh 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?
Aug 26 2014
parent reply "Mike" <none none.com> writes:
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
Aug 26 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Mike"  wrote in message news:bkkdiikafdsraqssjndv 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.
 * 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.
D can be used for that. But realistically, this is a constrained environment which will use a custom druntime, and be restricted to a subset of D.
 * 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.
I don't consider this to be a problem worth worrying about.
 * It gets in the way of porting the language to more platforms and 
 complicates maintenance of the runtime. Case in point: the 11666 debate.
No, it doesn't. Even if these bindings weren't in druntime, they'd be in another official library. Nothing would be different with respect to 11666.
 * It makes D unportable to some platforms without creating their own 
 dialect of the language or their own D runtime implementation
I expect D is already unportable to these platforms without doing these things. Removing libc bindings would not change this.
 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.
In an ideal world, the bindings would be more cleanly separated from other runtime stuff. But they're not. It would require a very compelling argument to move them now, and this really isn't it. We could document that core.stdc is not a required part of a D implementation, but it should be trivial to provide on any platform that can support a complete the rest of D, so there doesn't seem to be any point.
Aug 26 2014
parent reply "eles" <eles215 gzk.dot> writes:
On Tuesday, 26 August 2014 at 18:33:07 UTC, Daniel Murphy wrote:
 "Mike"  wrote in message 
 news:bkkdiikafdsraqssjndv 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.
 * 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.
D can be used for that. But realistically, this is a constrained environment which will use a custom druntime, and be restricted to a subset of D.
 * 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.
I don't consider this to be a problem worth worrying about.
 * It gets in the way of porting the language to more platforms 
 and complicates maintenance of the runtime. Case in point: the 
 11666 debate.
No, it doesn't. Even if these bindings weren't in druntime, they'd be in another official library. Nothing would be different with respect to 11666.
 * It makes D unportable to some platforms without creating 
 their own dialect of the language or their own D runtime 
 implementation
I expect D is already unportable to these platforms without doing these things. Removing libc bindings would not change this.
 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.
In an ideal world, the bindings would be more cleanly separated from other runtime stuff. But they're not. It would require a very compelling argument to move them now, and this really isn't it. We could document that core.stdc is not a required part of a D implementation, but it should be trivial to provide on any platform that can support a complete the rest of D, so there doesn't seem to be any point.
While this might be acceptable, there is one more question: what use to have the druntime separated from phobos, in this case? 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".
Aug 26 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"eles"  wrote in message news:qrfucjdbmydvoqgeyybp 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.
Aug 26 2014
parent reply "eles" <eles215 gzk.dot> writes:
On Tuesday, 26 August 2014 at 19:22:22 UTC, Daniel Murphy wrote:
 "eles"  wrote in message 
 news:qrfucjdbmydvoqgeyybp 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.
Aug 26 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"eles"  wrote in message news:ybcxmuwwpsiyupwerzsa 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.
Aug 27 2014
parent reply "eles" <eles eles.com> writes:
On Wednesday, 27 August 2014 at 07:52:18 UTC, Daniel Murphy wrote:
 "eles"  wrote in message 
 news:ybcxmuwwpsiyupwerzsa 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?
Aug 27 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"eles"  wrote in message news:rixtiaiokrukvqjsfrdh 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.
Aug 27 2014
parent reply "Sean Kelly" <sean invisibleduck.org> writes:
On Wednesday, 27 August 2014 at 18:06:00 UTC, Daniel Murphy wrote:
 "eles"  wrote in message 
 news:rixtiaiokrukvqjsfrdh forum.dlang.org...

 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.
There was a D runtime years ago created as a separate project around the time that Druntime had its beginnings (as Ares) that had no dependencies on standard C. The creator went by Maide in IRC, and she was doing some really cool stuff with it that made D work kind of like ObjectiveC. I don't think it's in development any more, but it's probably possible to track it down with enough googling.
Aug 29 2014
parent reply simendsjo <simendsjo+dlang gmail.com> writes:
On 08/29/2014 07:07 PM, Sean Kelly wrote:
 On Wednesday, 27 August 2014 at 18:06:00 UTC, Daniel Murphy wrote:
 "eles"  wrote in message news:rixtiaiokrukvqjsfrdh forum.dlang.org...

 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.
There was a D runtime years ago created as a separate project around the time that Druntime had its beginnings (as Ares) that had no dependencies on standard C. The creator went by Maide in IRC, and she was doing some really cool stuff with it that made D work kind of like ObjectiveC. I don't think it's in development any more, but it's probably possible to track it down with enough googling.
It's still available at dsource: http://www.dsource.org/projects/ares
Aug 29 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-08-29 23:00, simendsjo wrote:

 It's still available at dsource: http://www.dsource.org/projects/ares
I don't think he's referring to Ares, he's referring to some other D runtime. -- /Jacob Carlborg
Aug 30 2014
prev sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Jonathan M Davis"  wrote in message 
news:fxdqpmfcbskvtcafzfcp 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<T> 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.
Aug 22 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Aug 22 2014
next sibling parent "John" <john.joyus gmail.com> writes:
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! :)
Aug 22 2014
prev sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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.
Aug 22 2014
prev sibling parent reply "Kagamin" <spam here.lot> writes:
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?
Aug 22 2014
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Kagamin"  wrote in message news:ujtkjzyvjhtvmcvjhgqb forum.dlang.org...

 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?
I'm just saying you need a fairly good knowledge of the low-level workings on C++ and D, especially if something goes wrong. One example I hit, is that on windows if you had overloaded virtual functions, they would be inserted into the vtable backwards. These parts of the compiler are not very well tested, so if you're not comfortable debugging this sort of thing it might be better to wait until extern(C++) has seen heavier use.
Aug 23 2014
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/20/14, 2:15 AM, disapointed user wrote:
 thank you general for your selfish and user considered release.
 the lieutenants probably feel kind of really taken care of - as well as
 D users.
 how do you test and release at facebook.
 i am a user that considers to leave after many years. i am starting to
 dislike the language, as it is getting blown up and the the syntax
 getting ever weirder, less mainstream and a support for windows that
 really sucks.

 good luck in the future for all you guys
What is it that we could help with? -- Andrei
Aug 20 2014
next sibling parent reply ketmar via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
On Wed, 20 Aug 2014 10:18:09 -0700
Andrei Alexandrescu via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> wrote:

 What is it that we could help with? -- Andrei
he's drama queen, he doesn't need any help, only attention.
Aug 20 2014
parent "eles" <eles215 gzk.dot> writes:
On Thursday, 21 August 2014 at 01:30:52 UTC, ketmar via 
Digitalmars-d-announce wrote:
 On Wed, 20 Aug 2014 10:18:09 -0700
 Andrei Alexandrescu via Digitalmars-d-announce
 <digitalmars-d-announce puremagic.com> wrote:

 What is it that we could help with? -- Andrei
he's drama queen, he doesn't need any help, only attention.
Just let's try to be less harsher. Even if that's true, being harsh would be of no good for that person and for us neither.
Aug 20 2014
prev sibling parent "John" <john.joyus gmail.com> writes:
On Wednesday, 20 August 2014 at 17:18:08 UTC, Andrei Alexandrescu 
wrote:
 What is it that we could help with? -- Andrei
Windows users basically need something like Lazarus but with D language. http://www.lazarus.freepascal.org/
Aug 21 2014
prev sibling parent reply "eles" <eles215 gzk.dot> writes:
On Wednesday, 20 August 2014 at 09:15:54 UTC, disapointed user 
wrote:

 the the syntax getting ever weirder, less mainstream and a
While I agree with some of your remarks (particularily, the fact that it becomes too "scripting" language) ... where to go? I don't like Go (syntax, mainly). The sole contender in the C++-like family, for systems programming, would be Vala, but since they dropped the posix profile... :(
Aug 20 2014
next sibling parent "Ola Fosheim Gr" <ola.fosheim.grostad+dlang gmail.com> writes:
On Wednesday, 20 August 2014 at 22:00:58 UTC, eles wrote:
 On Wednesday, 20 August 2014 at 09:15:54 UTC, disapointed user 
 wrote:

 the the syntax getting ever weirder, less mainstream and a
While I agree with some of your remarks (particularily, the fact that it becomes too "scripting" language) ... where to go? I don't like Go (syntax, mainly). The sole contender in the C++-like family, for systems programming, would be Vala, but since they dropped the posix profile... :(
I don't know, but I am keeping an eye on bitc: http://www.coyotos.org/pipermail/bitc-dev/ I like how Shapiro discuss the various issues.
Aug 20 2014
prev sibling next sibling parent "Mike" <none none.com> writes:
On Wednesday, 20 August 2014 at 22:00:58 UTC, eles wrote:
 On Wednesday, 20 August 2014 at 09:15:54 UTC, disapointed user 
 wrote:

 the the syntax getting ever weirder, less mainstream and a
While I agree with some of your remarks (particularily, the fact that it becomes too "scripting" language) ... where to go? I don't like Go (syntax, mainly). The sole contender in the C++-like family, for systems programming, would be Vala, but since they dropped the posix profile... :(
D has set a new standard for me. No CTFE, no thanks.
Aug 20 2014
prev sibling parent ketmar via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
On Wed, 20 Aug 2014 22:00:57 +0000
eles via Digitalmars-d-announce <digitalmars-d-announce puremagic.com>
wrote:

 I don't like Go (syntax, mainly). The sole contender in the=20
 C++-like family, for systems programming, would be Vala, but=20
 since they dropped the posix profile... :(
language without CTFE is soo unpleasant to use after D. i'm programmed in various lisps and schemes and was very glad to find the C-like language with metaprogramming abilities. and I WANT AST MACROS! ;-) no, i don't want to write code to *support* AST macros, i want to write code that *uses* AST macros. ;-)
Aug 20 2014
prev sibling next sibling parent =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
On Monday, 18 August 2014 at 19:00:23 UTC, Andrei Alexandrescu 
wrote:

Support for new flag -vcolumns in Emacs FlyCheck is soon about to 
follow:

https://github.com/flycheck/flycheck/issues/460
Aug 18 2014
prev sibling next sibling parent "hane" <han.ehit.suzi.0 gmail.com> writes:
Hmm, list of bug fixes in dlang.org/changelog.html contains bugs 
that have been fixed but yet pushed into 2.066 branch.
Aug 18 2014
prev sibling next sibling parent "Suliman" <evermind live.ru> writes:
I remember that it was planned to add functional future for 
iteration throw elements. Something like:
().times
().do

But I can't find original post about it and nothing related in 
changelogs...
Aug 18 2014
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 18/08/14 21:00, 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
Did someone finish the changelog? -- /Jacob Carlborg
Aug 19 2014
next sibling parent reply "novice2" <sorry noem.ail> writes:
http://dlang.org/changelog.html
Version D 2.066 August 18, 2014
...
Phobos enhancements
  1.Bugzilla 3780: getopt improvements by Igor Lesik
Sorry, i can't find this improvements nor in getopt.d nor in http://dlang.org/phobos/std_getopt.html. Is this announce prematurely, and that this changes will be seen in 2.067 ?
Aug 19 2014
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, 19 August 2014 at 08:14:41 UTC, novice2 wrote:
http://dlang.org/changelog.html
Version D 2.066 August 18, 2014
...
Phobos enhancements
 1.Bugzilla 3780: getopt improvements by Igor Lesik
Sorry, i can't find this improvements nor in getopt.d nor in http://dlang.org/phobos/std_getopt.html. Is this announce prematurely, and that this changes will be seen in 2.067 ?
I suspect that the changelog was done by dates rather than based on what was actually merged. Someone else was commenting that some stuff was in there that's going to be in 2.067 and not 2.066, and 2.066 took long enough after it was branched, that it would be easy to accidentally list 2.067 stuff for 2.066 if you were looking at merge dates rather than what actually went on the 2.066 branch. - Jonathan M Davis
Aug 21 2014
prev sibling parent Nick Treleaven <ntrel-public yahoo.co.uk> writes:
On 19/08/2014 08:21, Jacob Carlborg wrote:
 Did someone finish the changelog?
One thing missing is a Note on compiler conversions for unique expressions, like: https://github.com/D-Programming-Language/phobos/pull/2109/files#diff-0baf0d34bf308dc66e131c0e56e4239bR761
Aug 19 2014
prev sibling next sibling parent reply "KrzaQ" <kq kq.kq> writes:
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
The new Windows installer executable is over 70x bigger in 2.066 than it was for 2.065. What's the reason? http://i.imgur.com/OPsYoWf.png
Aug 19 2014
parent reply Andrew Edwards <ridimz yahoo.com> writes:
On 8/19/14, 7:42 PM, KrzaQ 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
The new Windows installer executable is over 70x bigger in 2.066 than it was for 2.065. What's the reason? http://i.imgur.com/OPsYoWf.png
Yes, the installer is self contained. Meaning it no longer downloads a zip file for use during installation. In essence, it was always this big, just you never saw it because it got downloaded during the installation process.
Aug 19 2014
parent reply "Brad Anderson" <eco gnuk.net> writes:
On Tuesday, 19 August 2014 at 11:12:25 UTC, Andrew Edwards wrote:
 [...]
 In essence, it was always this big, just you never saw it 
 because it got downloaded during the installation process.
It was also significantly bigger before because the download it did was the >30MB dmd zip that contained files for all platform, not just Windows. The installer is LZMA compressed too so it's even smaller than the dmd windows-only zip (16MB). Because of this, download size is now 1/3rd what it was and installation size dropped from 176 MB to just 71 MB.
Aug 19 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/19/14, 7:28 PM, Brad Anderson wrote:
 On Tuesday, 19 August 2014 at 11:12:25 UTC, Andrew Edwards wrote:
 [...]
 In essence, it was always this big, just you never saw it because it
 got downloaded during the installation process.
It was also significantly bigger before because the download it did was the >30MB dmd zip that contained files for all platform, not just Windows. The installer is LZMA compressed too so it's even smaller than the dmd windows-only zip (16MB). Because of this, download size is now 1/3rd what it was and installation size dropped from 176 MB to just 71 MB.
Glad to finally see that one taken care of! -- Andrei
Aug 20 2014
prev sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
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.
Aug 22 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Aug 22 2014
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
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.
Aug 22 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Aug 22 2014
next sibling parent Brad Roberts via Digitalmars-d-announce writes:
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.
Aug 22 2014
prev sibling parent reply Andrew Edwards <ridimz yahoo.com> writes:
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.
Aug 22 2014
parent "Dejan Lekic" <dejan.lekic gmail.com> writes:
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.
Aug 26 2014