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:


"blocker", but it's marked as "RESOLVED FIXED" in bugzilla. and bug
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).


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.



 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