www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Moving towards D2 2.061 (and D1 1.076)

reply Walter Bright <newshound2 digitalmars.com> writes:
It's time to do a release; to that end we should be working on tidying up the 
regressions.

This will be the last official D1 release.
Dec 09 2012
next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 10-12-2012 01:33, Walter Bright wrote:
 It's time to do a release; to that end we should be working on tidying
 up the regressions.

 This will be the last official D1 release.

A few pull requests I'd *really* like to have in this release: https://github.com/D-Programming-Language/druntime/pull/340 https://github.com/D-Programming-Language/druntime/pull/361 https://github.com/D-Programming-Language/dmd/pull/1145 -- Alex Rønne Petersen alex lycus.org http://lycus.org
Dec 09 2012
prev sibling next sibling parent reply "alex" <info alexanderbothe.com> writes:
On Monday, 10 December 2012 at 00:34:33 UTC, Walter Bright wrote:
 It's time to do a release; to that end we should be working on 
 tidying up the regressions.

 This will be the last official D1 release.

Totally amazing to read this. Thank all of you for your efforts! Furthermore, is there a dedicated list of changes made to the D spec? Just to ensure that my parser still recognizes all language features ;)
Dec 09 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/9/2012 4:42 PM, alex wrote:
 Furthermore, is there a dedicated list of changes made to the D spec? Just to
 ensure that my parser still recognizes all language features ;)

Going through the "What's New" section of the changelog should do that.
Dec 09 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, December 09, 2012 16:33:44 Walter Bright wrote:
 It's time to do a release; to that end we should be working on tidying up
 the regressions.

Can we please get dmd pull# 1287 ( https://github.com/D-Programming- Language/dmd/pull/1287 ) resolved before the next release (preferably by merging it)? If we don't, and we merge it later, then we'll have added the -di flag for nothing, causing people to start using it and then stop after the 2.062. I think that it would be best if we did not cause that sort of churn, and I think that making deprecated warn by default will cause us far fewer problems with deprecated in the future and help us avoid breaking people's code when we actually have to change APIs for whatever reason. As it stands, deprecating _anything_ breaks code, which makes deprecated useless if we refuse to ever break people's code. With the pull# 1287, that would no longer be the case. Given how much you hate breaking users' code, I'm kind of surprised that you haven't merged it already. But regarldess, given the flag issue, I think that it should be settled before the next release rather than waiting. - Jonathan M Davis
Dec 09 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Dec 10, 2012 at 01:38:16AM +0100, Alex Rnne Petersen wrote:
 On 10-12-2012 01:33, Walter Bright wrote:
It's time to do a release; to that end we should be working on tidying
up the regressions.

This will be the last official D1 release.

A few pull requests I'd *really* like to have in this release: https://github.com/D-Programming-Language/druntime/pull/340

+1. Don't know about the other two pull requests, but this one is important to Linux users because it causes compilation failures due to deprecated octal literals. T -- It is widely believed that reinventing the wheel is a waste of time; but I disagree: without wheel reinventers, we would be still be stuck with wooden horse-cart wheels.
Dec 09 2012
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Monday, 10 December 2012 at 00:34:33 UTC, Walter Bright wrote:
 It's time to do a release; to that end we should be working on 
 tidying up the regressions.

 This will be the last official D1 release.

Several things : 1/ Is it possible to reenable the GC ? The argument saying that this is faster without only work on toy project. On any real size project, the huge amount of memory consumed cause swapping, which make things way slower. 2/ I'd really like to see that one fixed : https://github.com/D-Programming-Language/dmd/pull/1313 Without that, it is basically impossible to do separate compilation, and one of the consequence is to make 1/ even worse. 3/ Now that UDA are in master, what to do with them ? They clearly are not ready for release.
Dec 09 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-12-10 08:16, Jonathan M Davis wrote:
 On Monday, December 10, 2012 08:11:52 deadalnix wrote:
 3/ Now that UDA are in master, what to do with them ? They
 clearly are not ready for release.

Move them to a branch and remove them from master.

It will be interesting to see what happens. -- /Jacob Carlborg
Dec 09 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-12-10 08:11, deadalnix wrote:

 Several things :

 1/ Is it possible to reenable the GC ? The argument saying that this is
 faster without only work on toy project. On any real size project, the
 huge amount of memory consumed cause swapping, which make things way
 slower.
 2/ I'd really like to see that one fixed :
 https://github.com/D-Programming-Language/dmd/pull/1313 Without that, it
 is basically impossible to do separate compilation, and one of the
 consequence is to make 1/ even worse.
 3/ Now that UDA are in master, what to do with them ? They clearly are
 not ready for release.

4. What will happen to Win64, is that ready for release? -- /Jacob Carlborg
Dec 09 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/9/2012 11:40 PM, Jacob Carlborg wrote:
 4. What will happen to Win64, is that ready for release?

It will be an 'alpha' for Win64.
Dec 10 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-12-10 20:41, H. S. Teoh wrote:

 Wouldn't this be the right time to put the D stable idea to work? Leave
 UDA in master, but create a 2.061 release branch without UDA, and
 release that.

I think it's the right time. -- /Jacob Carlborg
Dec 10 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, December 10, 2012 08:11:52 deadalnix wrote:
 3/ Now that UDA are in master, what to do with them ? They
 clearly are not ready for release.

Move them to a branch and remove them from master. - Jonathan M Davis
Dec 09 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, December 10, 2012 08:40:25 Jacob Carlborg wrote:
 4. What will happen to Win64, is that ready for release?

It'll probably be left in with the changelog stating that it's at alpha quality. That's pretty much what happened with 64-bit support on Linux. - Jonathan M Davis
Dec 09 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-12-10 01:33, Walter Bright wrote:
 It's time to do a release; to that end we should be working on tidying
 up the regressions.

What about the release and development process we've been talking about for, I don't know, the last three releases. What's happening on that front?
 This will be the last official D1 release.

Is it already time? Still no support for dynamic libraries in sight: http://forum.dlang.org/thread/jc0ic5$18bv$2 digitalmars.com?page=8#post-jc9qus:248o0:242:40digitalmars.com -- /Jacob Carlborg
Dec 09 2012
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, December 10, 2012 08:50:39 Jacob Carlborg wrote:
 This will be the last official D1 release.

Is it already time? Still no support for dynamic libraries in sight: http://forum.dlang.org/thread/jc0ic5$18bv$2 digitalmars.com?page=8#post-jc9q us:248o0:242:40digitalmars.com

It was previously stated that official support for D1 was ending at the end of this year, so it makes perfect sense that the next release would be the last one given that it's likely to be later this month (though could be at the beginning of next year if sorting out regressions takes too long). AFAIK, D1 hasn't gotten any new features in ages, and if it doesn't support dynamic libraries yet, I wouldn't expect it to ever support them. But that's up to Walter. - Jonathan M Davis
Dec 09 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/9/2012 11:50 PM, Jacob Carlborg wrote:
 On 2012-12-10 01:33, Walter Bright wrote:
 It's time to do a release; to that end we should be working on tidying
 up the regressions.

What about the release and development process we've been talking about for, I don't know, the last three releases. What's happening on that front?

Andrei is working on that, I think he'll do a proposal for it soon.
 This will be the last official D1 release.

Is it already time? Still no support for dynamic libraries in sight:

If someone wants to do the work to support them, I'll fold it in.
Dec 10 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-12-10 12:07, Walter Bright wrote:

 If someone wants to do the work to support them, I'll fold it in.

Same old, same old. I guess I have to do it myself if I want something done. -- /Jacob Carlborg
Dec 10 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/10/2012 4:30 AM, Jacob Carlborg wrote:
 On 2012-12-10 12:07, Walter Bright wrote:

 If someone wants to do the work to support them, I'll fold it in.

Same old, same old. I guess I have to do it myself if I want something done.

BTW, I've fixed every bug report on the dynamic libraries where anyone identified an issue with how dmd generates PIC code for dynamic libraries.
Dec 10 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-12-10 13:43, Walter Bright wrote:

 BTW, I've fixed every bug report on the dynamic libraries where anyone
 identified an issue with how dmd generates PIC code for dynamic libraries.

Yeah, that's great. But that doesn't make dynamic libraries magically work. The runtime still need to support it. On Mac OS X there will most likely need to be made some changes to the compiler as well. I'm thinking mostly to support TLS, the ___tls_get_addr need to receive an image (mach_header) in addition to the address of the variable. -- /Jacob Carlborg
Dec 10 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-12-10 14:03, Jacob Carlborg wrote:

 Yeah, that's great. But that doesn't make dynamic libraries magically
 work. The runtime still need to support it. On Mac OS X there will most
 likely need to be made some changes to the compiler as well. I'm
 thinking mostly to support TLS, the ___tls_get_addr need to receive an
 image (mach_header) in addition to the address of the variable.

On the other hand, TLS has nothing to do with D1, my bad. -- /Jacob Carlborg
Dec 10 2012
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/10/2012 5:03 AM, Jacob Carlborg wrote:
 On 2012-12-10 13:43, Walter Bright wrote:

 BTW, I've fixed every bug report on the dynamic libraries where anyone
 identified an issue with how dmd generates PIC code for dynamic libraries.

Yeah, that's great. But that doesn't make dynamic libraries magically work. The runtime still need to support it.

I know.
Dec 10 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-12-10 21:04, Jonathan M Davis wrote:

 That's the way that it works with pretty much everything around here. It's
 just that there are more people working on D2 and its components than D1. In
 either case, if no one else has the time or inclination to do what you want,
 you have to do it. It's one of the major downsides to a volunteer work force.

I would think that others have interest in this as well. And it's not just for D1, it's for D2 as well. -- /Jacob Carlborg
Dec 10 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/10/2012 12:55 PM, Jacob Carlborg wrote:
 I would think that others have interest in this as well. And it's not just for
 D1, it's for D2 as well.

If that was the only thing others have interest in, then it would be top priority. But there are endless "why haven't you fixed xxx yet?" issues.
Dec 10 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-12-10 22:49, Walter Bright wrote:

 If that was the only thing others have interest in, then it would be top
 priority. But there are endless "why haven't you fixed xxx yet?" issues.

I know. I just thought there would be more interest in this feature than it seems to be. -- /Jacob Carlborg
Dec 10 2012
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, December 10, 2012 13:30:39 Jacob Carlborg wrote:
 On 2012-12-10 12:07, Walter Bright wrote:
 If someone wants to do the work to support them, I'll fold it in.

Same old, same old. I guess I have to do it myself if I want something done.

That's the way that it works with pretty much everything around here. It's just that there are more people working on D2 and its components than D1. In either case, if no one else has the time or inclination to do what you want, you have to do it. It's one of the major downsides to a volunteer work force. - Jonathan M Davis
Dec 10 2012
prev sibling next sibling parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
10.12.2012 4:33, Walter Bright пишет:
 It's time to do a release; to that end we should be working on tidying
 up the regressions.

 This will be the last official D1 release.

Sorry, but I have never understand how can anybody call D stable and why are you doing all this "support". Let me explain: A long time ago I wrote one (not open source) application in D1+Tango. I'm still supporting it. The last D1 compiler I can use is 1.066 as then a fatal regression was introduced and templates became unusable because of ICE. Am I the only one who use templates in D1? If not, what is the purpose for all this needless D1 releases as compiler doesn't work for almost any project with templates? And let me beat utterly: Now imagine: a person updated a compiler and get ICE. On *huge* codebase. What will he do? He will use old working one. But I decided to go further, found a DustMite and decided to find the source of the error. Do you know that current D2 compiler ICE-s with compiling DustMite? Imagine, what will feel a person when bug finding tool ICE-s a compiler? He will probably consider "D is a peace of unstable shit" and go away. And he will be right as it is unforgivable for us to talk about any "stability" of D. "D is for crazy nerd who are ready to find, report and workaround infinite compiler bugs on any complicated code with templates", that's all we can tell. But I finally managed to compile DustMite without ICE, found the regression and reported. Still unfixed... -- Денис В. Шеломовский Denis V. Shelomovskij
Dec 10 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/10/2012 12:56 AM, Denis Shelomovskij wrote:
 A long time ago I wrote one (not open source) application in D1+Tango.
 I'm still supporting it. The last D1 compiler I can use is 1.066 as then a
fatal
 regression was introduced and templates became unusable because of ICE. Am I
the
 only one who use templates in D1? If not, what is the purpose for all this
 needless D1 releases as compiler doesn't work for almost any project with
 templates?

What is the bugzilla issue number for that? In bugzilla, you can tag issues as being "regressions", and I don't recall seeing one like you describe. Here is the current list of regressions: http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
 And let me beat utterly:

 Now imagine: a person updated a compiler and get ICE. On *huge* codebase. What
 will he do? He will use old working one. But I decided to go further, found a
 DustMite and decided to find the source of the error. Do you know that current
 D2 compiler ICE-s with compiling DustMite? Imagine, what will feel a person
when
 bug finding tool ICE-s a compiler? He will probably consider "D is a peace of
 unstable shit" and go away.

 And he will be right as it is unforgivable for us to talk about any "stability"
 of D. "D is for crazy nerd who are ready to find, report and workaround
infinite
 compiler bugs on any complicated code with templates", that's all we can tell.

 But I finally managed to compile DustMite without ICE, found the regression and
 reported. Still unfixed...

What is the bugzilla issue number?
Dec 10 2012
parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
10.12.2012 15:11, Walter Bright пишет:
 On 12/10/2012 12:56 AM, Denis Shelomovskij wrote:
 A long time ago I wrote one (not open source) application in D1+Tango.
 I'm still supporting it. The last D1 compiler I can use is 1.066 as
 then a fatal
 regression was introduced and templates became unusable because of
 ICE. Am I the
 only one who use templates in D1? If not, what is the purpose for all
 this
 needless D1 releases as compiler doesn't work for almost any project with
 templates?

What is the bugzilla issue number for that? In bugzilla, you can tag issues as being "regressions", and I don't recall seeing one like you describe. Here is the current list of regressions: http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
 And let me beat utterly:

 Now imagine: a person updated a compiler and get ICE. On *huge*
 codebase. What
 will he do? He will use old working one. But I decided to go further,
 found a
 DustMite and decided to find the source of the error. Do you know that
 current
 D2 compiler ICE-s with compiling DustMite? Imagine, what will feel a
 person when
 bug finding tool ICE-s a compiler? He will probably consider "D is a
 peace of
 unstable shit" and go away.

 And he will be right as it is unforgivable for us to talk about any
 "stability"
 of D. "D is for crazy nerd who are ready to find, report and
 workaround infinite
 compiler bugs on any complicated code with templates", that's all we
 can tell.

 But I finally managed to compile DustMite without ICE, found the
 regression and
 reported. Still unfixed...

What is the bugzilla issue number?

This was the result of DustMite-ing my sources: http://d.puremagic.com/issues/show_bug.cgi?id=6296 Currently the bug state is a bit confusing. It is a regression (but I didn't mark it that way, only write in description, sorry) but is resolved as a duplicate of a non-regression unfixed bug 4269. It was a small war between "regression" and "normal" state of 4269 and now it is marked as "normal". -- Денис В. Шеломовский Denis V. Shelomovskij
Dec 10 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/10/2012 8:28 AM, Denis Shelomovskij wrote:
 This was the result of DustMite-ing my sources:
 http://d.puremagic.com/issues/show_bug.cgi?id=6296

 Currently the bug state is a bit confusing. It is a regression (but I didn't
 mark it that way, only write in description, sorry) but is resolved as a
 duplicate of a non-regression unfixed bug 4269. It was a small war between
 "regression" and "normal" state of 4269 and now it is marked as "normal".

It isn't a regression, and the test cases you reported work in D1 and D2.
Dec 10 2012
next sibling parent Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
11.12.2012 3:01, Walter Bright пишет:
 On 12/10/2012 8:28 AM, Denis Shelomovskij wrote:
 This was the result of DustMite-ing my sources:
 http://d.puremagic.com/issues/show_bug.cgi?id=6296

 Currently the bug state is a bit confusing. It is a regression (but I
 didn't
 mark it that way, only write in description, sorry) but is resolved as a
 duplicate of a non-regression unfixed bug 4269. It was a small war
 between
 "regression" and "normal" state of 4269 and now it is marked as "normal".

It isn't a regression, and the test cases you reported work in D1 and D2.

I had a code base that worked. With new compiler it stopped working. I DustMite-ed code base and posted this issue. It's really surprising that it wasn't a regression... I know that tests from the issue pass now. I just didn't think I have to DustMite again to provide new ones as the issue is marked as a duplicate of an unfixed one. -- Денис В. Шеломовский Denis V. Shelomovskij
Dec 10 2012
prev sibling parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
11.12.2012 3:01, Walter Bright пишет:
 On 12/10/2012 8:28 AM, Denis Shelomovskij wrote:
 This was the result of DustMite-ing my sources:
 http://d.puremagic.com/issues/show_bug.cgi?id=6296

 Currently the bug state is a bit confusing. It is a regression (but I
 didn't
 mark it that way, only write in description, sorry) but is resolved as a
 duplicate of a non-regression unfixed bug 4269. It was a small war
 between
 "regression" and "normal" state of 4269 and now it is marked as "normal".

It isn't a regression, and the test cases you reported work in D1 and D2.

How can I suppress DMD "abnormal program termination" pop-up when launched with "dmd ... 2>&1"? DustMite's code: https://github.com/CyberShadow/DustMite/wiki/Suppressing-DMD-crashes fails in this call: "FindWindowExA(h, null, "Button", "OK");" -- Денис В. Шеломовский Denis V. Shelomovskij
Dec 11 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/11/2012 12:08 AM, Denis Shelomovskij wrote:
 How can I suppress DMD "abnormal program termination" pop-up when launched with
 "dmd ... 2>&1"?

 DustMite's code:
 https://github.com/CyberShadow/DustMite/wiki/Suppressing-DMD-crashes
 fails in this call: "FindWindowExA(h, null, "Button", "OK");"

dmd never calls FindWindowExA.
Dec 11 2012
next sibling parent Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
11.12.2012 12:25, Walter Bright пишет:
 On 12/11/2012 12:08 AM, Denis Shelomovskij wrote:
 How can I suppress DMD "abnormal program termination" pop-up when
 launched with
 "dmd ... 2>&1"?

 DustMite's code:
 https://github.com/CyberShadow/DustMite/wiki/Suppressing-DMD-crashes
 fails in this call: "FindWindowExA(h, null, "Button", "OK");"

dmd never calls FindWindowExA.

I didn't write that dmd calls FindWindowExA! -- Денис В. Шеломовский Denis V. Shelomovskij
Dec 11 2012
prev sibling parent dennis luehring <dl.soluz gmx.net> writes:
Am 11.12.2012 09:25, schrieb Walter Bright:
 On 12/11/2012 12:08 AM, Denis Shelomovskij wrote:
 How can I suppress DMD "abnormal program termination" pop-up when launched with
 "dmd ... 2>&1"?

 DustMite's code:
 https://github.com/CyberShadow/DustMite/wiki/Suppressing-DMD-crashes
 fails in this call: "FindWindowExA(h, null, "Button", "OK");"

dmd never calls FindWindowExA.

this "tools" just tries to find and close the maybe popping up "access violation" window when compiling with dmd
Dec 11 2012
prev sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 12/11/2012 12:08 AM, Denis Shelomovskij wrote:
 11.12.2012 3:01, Walter Bright пишет:
 On 12/10/2012 8:28 AM, Denis Shelomovskij wrote:
 This was the result of DustMite-ing my sources:
 http://d.puremagic.com/issues/show_bug.cgi?id=6296

 Currently the bug state is a bit confusing. It is a regression (but I
 didn't
 mark it that way, only write in description, sorry) but is resolved as a
 duplicate of a non-regression unfixed bug 4269. It was a small war
 between
 "regression" and "normal" state of 4269 and now it is marked as
 "normal".

It isn't a regression, and the test cases you reported work in D1 and D2.

How can I suppress DMD "abnormal program termination" pop-up when launched with "dmd ... 2>&1"? DustMite's code: https://github.com/CyberShadow/DustMite/wiki/Suppressing-DMD-crashes fails in this call: "FindWindowExA(h, null, "Button", "OK");"

Edit dmd with OllyDbg cf http://forum.dlang.org/thread/k1954u$lsq$1 digitalmars.com#post-k1lkbv:2421n7:241:40digitalmars.com for the calls you're looking for
Dec 11 2012
parent Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
12.12.2012 5:36, Ellery Newcomer пишет:
 Edit dmd with OllyDbg

 cf

 http://forum.dlang.org/thread/k1954u$lsq$1 digitalmars.com#post-k1lkbv:2421n7:241:40digitalmars.com


 for the calls you're looking for

Thanks, it helped. I managed to reduce (in "1 day, 1 hour, 44 minutes, 43 secs, and 125 ms" as DustMite said) and fill http://d.puremagic.com/issues/show_bug.cgi?id=9189 -- Денис В. Шеломовский Denis V. Shelomovskij
Dec 20 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-12-10 09:56, Denis Shelomovskij wrote:

 Sorry, but I have never understand how can anybody call D stable and why
 are you doing all this "support".


 Let me explain:

 A long time ago I wrote one (not open source) application in D1+Tango.
 I'm still supporting it. The last D1 compiler I can use is 1.066 as then
 a fatal regression was introduced and templates became unusable because
 of ICE. Am I the only one who use templates in D1? If not, what is the
 purpose for all this needless D1 releases as compiler doesn't work for
 almost any project with templates?

I have still one project left that uses D1 and Tango. It do have some templates but not much and not anything advanced.
 And let me beat utterly:

 Now imagine: a person updated a compiler and get ICE. On *huge*
 codebase. What will he do? He will use old working one. But I decided to
 go further, found a DustMite and decided to find the source of the
 error. Do you know that current D2 compiler ICE-s with compiling
 DustMite? Imagine, what will feel a person when bug finding tool ICE-s a
 compiler? He will probably consider "D is a peace of unstable shit" and
 go away.

 And he will be right as it is unforgivable for us to talk about any
 "stability" of D. "D is for crazy nerd who are ready to find, report and
 workaround infinite compiler bugs on any complicated code with
 templates", that's all we can tell.

 But I finally managed to compile DustMite without ICE, found the
 regression and reported. Still unfixed...

I understand your frustration and feel the same. -- /Jacob Carlborg
Dec 10 2012
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Monday, 10 December 2012 at 11:12:21 UTC, Walter Bright wrote:
 On 12/10/2012 12:56 AM, Denis Shelomovskij wrote:
 Do you know that current
 D2 compiler ICE-s with compiling DustMite? Imagine, what will 
 feel a person when
 bug finding tool ICE-s a compiler? He will probably consider 
 "D is a peace of
 unstable shit" and go away.

What is the bugzilla issue number?

http://d.puremagic.com/issues/show_bug.cgi?id=6395
Dec 10 2012
prev sibling parent "Mathias Laurenz Baumann" <mathias.baumann sociomantic.com> writes:
On Mon, 10 Dec 2012 09:56:44 +0100, Denis Shelomovskij  =

<verylonglogin.reg gmail.com> wrote:

 10.12.2012 4:33, Walter Bright =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
 It's time to do a release; to that end we should be working on tidyin=


 up the regressions.

 This will be the last official D1 release.

Sorry, but I have never understand how can anybody call D stable and w=

 are you doing all this "support".


 Let me explain:

 A long time ago I wrote one (not open source) application in D1+Tango.=

 I'm still supporting it. The last D1 compiler I can use is 1.066 as th=

 a fatal regression was introduced and templates became unusable becaus=

 of ICE. Am I the only one who use templates in D1? If not, what is the=

 purpose for all this needless D1 releases as compiler doesn't work for=

 almost any project with templates?

We have our whole infrastructure in D1 and tango and currentl are using = = dmd 1.075 for compilation. We don't have any major problems with templates (just a few= = dmd hickups every now and then).
 And let me beat utterly:

 Now imagine: a person updated a compiler and get ICE. On *huge*  =

 codebase. What will he do? He will use old working one. But I decided =

 go further, found a DustMite and decided to find the source of the  =

 error. Do you know that current D2 compiler ICE-s with compiling  =

 DustMite? Imagine, what will feel a person when bug finding tool ICE-s=

 compiler? He will probably consider "D is a peace of unstable shit" an=

 go away.

 And he will be right as it is unforgivable for us to talk about any  =

 "stability" of D. "D is for crazy nerd who are ready to find, report a=

 workaround infinite compiler bugs on any complicated code with  =

 templates", that's all we can tell.

 But I finally managed to compile DustMite without ICE, found the  =

 regression and reported. Still unfixed...

What you say is partly true, work around and such, but it isn't as bad a= s = you describe it above. We have big projects and the still work. --Marenz -- Mathias Baumann Research and Development sociomantic labs GmbH Paul-Linke-Ufer 39/40 10999 Berlin http://www.sociomantic.com Fon: +49 (0)30 3087 4615 Fax: +49 (0)30 3087 4619 Skype: Mathias Baumann (m4renz) Irc: irc://irc.freenode.net User Marenz or Suprano ----------------------------------------------------------- sociomantic labs GmbH, Location: Berlin Commercial Register - AG Charlottenburg: HRB 121302 B VAT No. - USt-ID: DE 266262100 Managing Directors: Thomas Nicolai, Thomas Brandhoff
Dec 20 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Dec 09, 2012 at 11:16:32PM -0800, Jonathan M Davis wrote:
 On Monday, December 10, 2012 08:11:52 deadalnix wrote:
 3/ Now that UDA are in master, what to do with them ? They
 clearly are not ready for release.

Move them to a branch and remove them from master.

Wouldn't this be the right time to put the D stable idea to work? Leave UDA in master, but create a 2.061 release branch without UDA, and release that. T -- Любишь кататься - люби и саночки возить.
Dec 10 2012
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, December 10, 2012 11:41:29 H. S. Teoh wrote:
 On Sun, Dec 09, 2012 at 11:16:32PM -0800, Jonathan M Davis wrote:
 On Monday, December 10, 2012 08:11:52 deadalnix wrote:
 3/ Now that UDA are in master, what to do with them ? They
 clearly are not ready for release.

Move them to a branch and remove them from master.

[...] Wouldn't this be the right time to put the D stable idea to work? Leave UDA in master, but create a 2.061 release branch without UDA, and release that.

D stable is being run by someone else. It seems like the current plan is for us to continue to put out releases like we have been but the D stable folks will manage a separate repo which only has the stable changes and then fully syncs up with master at some interval. Whether that's the best way to deal with it is another matter, but that at least looks like what they're planning on doing. Regardless, the UDA stuff can't be in the next release. If we want to create a branch that we do the release from (which we should be doing anyway), then UDA can be explicitly removed from there rather than master, but it needs to not be released regardless. How D stable gets managed is a related matter, but based on the discussions on that, I expect that that will be sorted out _after_ the next release rather than with the next release (particularly since this is the last release with D1, and Walter is more open to changing how does things after he doesn't have to support D1 anymore). - Jonathan M Davis
Dec 10 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/10/2012 12:04 PM, Jonathan M Davis wrote:
 Regardless, the UDA stuff can't be in the next release.

Why? (It's being heavily used by some people.)
Dec 10 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/10/2012 1:57 PM, Adam D. Ruppe wrote:
 On Monday, 10 December 2012 at 21:50:47 UTC, Walter Bright wrote:
 Why? (It's being heavily used by some people.)

I'm *really* looking forward to UDAs in the next release. Even if the syntax changes in 2.62, I'd still like to have it in 2.61 just because there's so many things I can do with it.

The syntax will be: (attributes) and: identifier although the latter isn't implemented yet.
Dec 10 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/10/2012 2:20 PM, Max Samukha wrote:
 On Monday, 10 December 2012 at 22:15:09 UTC, Walter Bright wrote:
 On 12/10/2012 1:57 PM, Adam D. Ruppe wrote:
 On Monday, 10 December 2012 at 21:50:47 UTC, Walter Bright wrote:
 Why? (It's being heavily used by some people.)

I'm *really* looking forward to UDAs in the next release. Even if the syntax changes in 2.62, I'd still like to have it in 2.61 just because there's so many things I can do with it.

The syntax will be: (attributes) and: identifier although the latter isn't implemented yet.

So identifier(args) and identifier!(args) will require parens?

Good question. I think it shouldn't.
Dec 10 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-12-11 00:19, Max Samukha wrote:

 Probably it should. Single parametrized attributes (in the form of
 templates or CTFE constructors) are very likely to occur as often (if
 not more often) as parameterless (as they do in C#, for example).

I've just made a pull request, see: http://forum.dlang.org/thread/ka3amp$12j$1 digitalmars.com?page=6#post-ka6t8a:241khj:241:40digitalmars.com -- /Jacob Carlborg
Dec 11 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-12-10 23:15, Walter Bright wrote:

 The syntax will be:

      (attributes)

 and:

      identifier

 although the latter isn't implemented yet.

Pull 1395. struct Foo1 {} Foo int x1; struct Foo2 (string bar) {} Foo!"asd" int x2; Foo!("asd") int x22; struct Foo3 (string bar) { int a; } Foo!"asd"(3) int x3; Foo!("asd")(3) int x32; https://github.com/D-Programming-Language/dmd/pull/1365 -- /Jacob Carlborg
Dec 11 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/10/2012 3:35 PM, Jonathan M Davis wrote:
 On Monday, December 10, 2012 13:50:47 Walter Bright wrote:
 Why? (It's being heavily used by some people.)

It hasn't even been properly worked out yet, and new features like that shouldn't be being introduced in the main branch. It's not at all ready for general consumption, and if it's in there, people are going to start using it and then complaining when their code breaks when we change it later. It's the sort of thing that should be on a separate branch and not in master. Even worse, if the new stable branch that we've been talking about includes this, then you'll have programmers programming with it for months before they get the updates with the design that we're actually going to end up with, meaning that that much more code will be written for that much longer with an incomplete feature, waiting to be broken when the feature is actually updated in the version of the compiler that they're using.

We've debated this feature at length in various threads. It's under heavy use by some people. It does not break any existing code. I don't see any unresolved issue that should delay its incorporation.
Dec 10 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/10/2012 8:01 PM, Kapps wrote:
 Right now, holding it off won't break any code not relying on an unreleased
 version of the compiler. Releasing it, then having to make changes will break
 code though. There were plenty of discussions about UDA stuff that never really
 got fully resolved. For example, whether only specific types should be allowed
 to be used as annotations. These things should have been fully decided before
 UDA's were implemented, because otherwise we may end up with an inferior
 approach for the sake of not breaking code, or breaking code because a feature
 was not fully fleshed out before being released.

I agree there was not a consensus reached on this issue. But I also feel all the arguments were fairly represented, and it was time to make a decision.
Dec 10 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/10/2012 8:15 PM, deadalnix wrote:
 On Tuesday, 11 December 2012 at 04:11:50 UTC, Walter Bright wrote:
 I agree there was not a consensus reached on this issue. But I also feel all
 the arguments were fairly represented, and it was time to make a decision.

Note that either the decision is to reserve attribution to special types, and it is rather safe as it is what is done in other languages, or it is to allow everything to be an attribute, and it should be field tested before going into the main release, because unless I'm mistaken, no language do that ATM, so we can't rely on previous experience on the subject.

Yes I understand that, and it is being extensively and heavily used since the day I posted it, and no problems have arisen. I also understand that you and I disagree on this issue, but at some point I've got to make a decision.
Dec 10 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/10/2012 8:21 PM, Walter Bright wrote:
 Yes I understand that, and it is being extensively and heavily used since the
 day I posted it, and no problems have arisen.

I should also add that the design was based on extensive discussions about it here last summer.
Dec 10 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-12-11 00:47, Walter Bright wrote:

 We've debated this feature at length in various threads. It's under
 heavy use by some people. It does not break any existing code. I don't
 see any unresolved issue that should delay its incorporation.

We don't want to have a half working feature, regardless if it breaks any other code or not. -- /Jacob Carlborg
Dec 10 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-12-10 22:50, Walter Bright wrote:

 Why? (It's being heavily used by some people.)

Then it's their problem is they using an unreleased version of DMD. -- /Jacob Carlborg
Dec 10 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 10 December 2012 at 21:50:47 UTC, Walter Bright wrote:
 Why? (It's being heavily used by some people.)

I'm *really* looking forward to UDAs in the next release. Even if the syntax changes in 2.62, I'd still like to have it in 2.61 just because there's so many things I can do with it.
Dec 10 2012
prev sibling next sibling parent "Rob T" <rob ucora.com> writes:
On Monday, 10 December 2012 at 21:57:58 UTC, Adam D. Ruppe wrote:
 On Monday, 10 December 2012 at 21:50:47 UTC, Walter Bright 
 wrote:
 Why? (It's being heavily used by some people.)

I'm *really* looking forward to UDAs in the next release. Even if the syntax changes in 2.62, I'd still like to have it in 2.61 just because there's so many things I can do with it.

This is why we desperately need a rock solid stable branch, but also a pre-release testing branch that is in a reasonably stable state that includes that latest fixes and features that are deemed to be "close to ready", and for any of that to work, there has to be a separate development branch for the inclusion of brand new features and other experimental work. --rt
Dec 10 2012
prev sibling next sibling parent "Max Samukha" <maxsamukha gmail.com> writes:
On Monday, 10 December 2012 at 22:15:09 UTC, Walter Bright wrote:
 On 12/10/2012 1:57 PM, Adam D. Ruppe wrote:
 On Monday, 10 December 2012 at 21:50:47 UTC, Walter Bright 
 wrote:
 Why? (It's being heavily used by some people.)

I'm *really* looking forward to UDAs in the next release. Even if the syntax changes in 2.62, I'd still like to have it in 2.61 just because there's so many things I can do with it.

The syntax will be: (attributes) and: identifier although the latter isn't implemented yet.

So identifier(args) and identifier!(args) will require parens?
Dec 10 2012
prev sibling next sibling parent "Max Samukha" <maxsamukha gmail.com> writes:
On Monday, 10 December 2012 at 22:56:45 UTC, Walter Bright wrote:
 On 12/10/2012 2:20 PM, Max Samukha wrote:
 On Monday, 10 December 2012 at 22:15:09 UTC, Walter Bright 
 wrote:
 On 12/10/2012 1:57 PM, Adam D. Ruppe wrote:
 On Monday, 10 December 2012 at 21:50:47 UTC, Walter Bright 
 wrote:
 Why? (It's being heavily used by some people.)

I'm *really* looking forward to UDAs in the next release. Even if the syntax changes in 2.62, I'd still like to have it in 2.61 just because there's so many things I can do with it.

The syntax will be: (attributes) and: identifier although the latter isn't implemented yet.

So identifier(args) and identifier!(args) will require parens?

Good question. I think it shouldn't.

Probably it should. Single parametrized attributes (in the form of templates or CTFE constructors) are very likely to occur as often (if not more often) as parameterless (as they do in C#, for example).
Dec 10 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, December 10, 2012 13:50:47 Walter Bright wrote:
 On 12/10/2012 12:04 PM, Jonathan M Davis wrote:
 Regardless, the UDA stuff can't be in the next release.

Why? (It's being heavily used by some people.)

It hasn't even been properly worked out yet, and new features like that shouldn't be being introduced in the main branch. It's not at all ready for general consumption, and if it's in there, people are going to start using it and then complaining when their code breaks when we change it later. It's the sort of thing that should be on a separate branch and not in master. Even worse, if the new stable branch that we've been talking about includes this, then you'll have programmers programming with it for months before they get the updates with the design that we're actually going to end up with, meaning that that much more code will be written for that much longer with an incomplete feature, waiting to be broken when the feature is actually updated in the version of the compiler that they're using. Andrei was already complaining about this was handled in the thread where they were introduced, and I expect that he'll agree that it shouldn't be in the release. It's not ready. - Jonathan M Davis
Dec 10 2012
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 10 December 2012 at 23:47:49 UTC, Walter Bright wrote:
 We've debated this feature at length in various threads. It's 
 under heavy use by some people. It does not break any existing 
 code. I don't see any unresolved issue that should delay its 
 incorporation.

We already have some features interacting in a bad way. Feature must be field tested in various codebase before being integrated into the main release, so design issue can be fixed without breaking code (or by having people who's aware that such breakage will happen because they are using experimental features).
Dec 10 2012
prev sibling next sibling parent "Kapps" <opantm2+spam gmail.com> writes:
On Monday, 10 December 2012 at 23:47:49 UTC, Walter Bright wrote:
 We've debated this feature at length in various threads. It's 
 under heavy use by some people. It does not break any existing 
 code. I don't see any unresolved issue that should delay its 
 incorporation.

Right now, holding it off won't break any code not relying on an unreleased version of the compiler. Releasing it, then having to make changes will break code though. There were plenty of discussions about UDA stuff that never really got fully resolved. For example, whether only specific types should be allowed to be used as annotations. These things should have been fully decided before UDA's were implemented, because otherwise we may end up with an inferior approach for the sake of not breaking code, or breaking code because a feature was not fully fleshed out before being released.
Dec 10 2012
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 11 December 2012 at 04:11:50 UTC, Walter Bright wrote:
 On 12/10/2012 8:01 PM, Kapps wrote:
 Right now, holding it off won't break any code not relying on 
 an unreleased
 version of the compiler. Releasing it, then having to make 
 changes will break
 code though. There were plenty of discussions about UDA stuff 
 that never really
 got fully resolved. For example, whether only specific types 
 should be allowed
 to be used as annotations. These things should have been fully 
 decided before
 UDA's were implemented, because otherwise we may end up with 
 an inferior
 approach for the sake of not breaking code, or breaking code 
 because a feature
 was not fully fleshed out before being released.

I agree there was not a consensus reached on this issue. But I also feel all the arguments were fairly represented, and it was time to make a decision.

Note that either the decision is to reserve attribution to special types, and it is rather safe as it is what is done in other languages, or it is to allow everything to be an attribute, and it should be field tested before going into the main release, because unless I'm mistaken, no language do that ATM, so we can't rely on previous experience on the subject.
Dec 10 2012
prev sibling next sibling parent "Max Samukha" <maxsamukha gmail.com> writes:
On Tuesday, 11 December 2012 at 09:10:30 UTC, Jacob Carlborg 
wrote:
 On 2012-12-11 00:19, Max Samukha wrote:

 Probably it should. Single parametrized attributes (in the 
 form of
 templates or CTFE constructors) are very likely to occur as 
 often (if
 not more often) as parameterless (as they do in C#, for 
 example).

I've just made a pull request, see: http://forum.dlang.org/thread/ka3amp$12j$1 digitalmars.com?page=6#post-ka6t8a:241khj:241:40digitalmars.com

Great! I'll try it out later.
Dec 11 2012
prev sibling next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 10 December 2012 00:33, Walter Bright <newshound2 digitalmars.com> wrote:
 It's time to do a release; to that end we should be working on tidying up
 the regressions.

 This will be the last official D1 release.

I foresee that this release will be the biggest pain in the ass to merge downstream into GDC. I wonder if David on LDC's side shares the same concern... -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Dec 11 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/11/2012 5:37 AM, Iain Buclaw wrote:
 I foresee that this release will be the biggest pain in the ass to
 merge downstream into GDC. I wonder if David on LDC's side shares the
 same concern...

Why?
Dec 11 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/11/2012 2:20 PM, Iain Buclaw wrote:
 Maybe it's just me, but so far this has been 5 months in development,
 and the thought of working on a larger set of changes just seems to be
 an impending daunt over my head. :o)

The bulk of the work was bashing on the back end to get it to generate Win64 code that would work with VS, which should not affect GDC.
Dec 11 2012
prev sibling parent Kai Nacke <kai redstar.de> writes:
On 12.12.2012 02:42, David Nadlinger wrote:
 On Tuesday, 11 December 2012 at 13:37:16 UTC, Iain Buclaw wrote:
 I foresee that this release will be the biggest pain in the ass to
 merge downstream into GDC. I wonder if David on LDC's side shares the
 same concern...

I have been busy with getting LDC ready for the next release lately, so I didn't have a closer look at the state of things with regard to merging yet. However, it seems like Kai has already put together a patch which merges the frontend as it was a few days ago (see https://github.com/ldc-developers/ldc/wiki/Building-and-hacking-LDC-on-Windows-using-MSVC), so maybe he has any comments on this? David

To merge the frontend I created a MSBUILD script which uses git to perform a 3-way merge. I commit the source of the previous dmd fe, create a ldc branch and commit the current fe source. Then I commit the current dmd fe and try to merge it into the ldc branch. The number of merge conflicts is then an indicator how difficult the merge is. With 2.061 I got only a few merge conflicts. For me it seems to be easier to merge then the previous release. Kai
Dec 15 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 11 December 2012 17:44, Walter Bright <newshound2 digitalmars.com> wrote:
 On 12/11/2012 5:37 AM, Iain Buclaw wrote:
 I foresee that this release will be the biggest pain in the ass to
 merge downstream into GDC. I wonder if David on LDC's side shares the
 same concern...

Why?

If the last release was anything to go by - I think it was 4 months in development - there were quite a lot of changes that stepped on the toes of the GNU frontend code that required a few unexpected changes. eg; introduction of struct Obj. Plus the shear size of changes makes it a delicate task to make sure that anything pulled in does not remove any GDC-specific changes in D Frontend. Maybe it's just me, but so far this has been 5 months in development, and the thought of working on a larger set of changes just seems to be an impending daunt over my head. :o) It shouldn't be though, it should just be as simple as a replacing the old files with the new and done. But that's something that should consider to work towards in the future. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Dec 11 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Tuesday, 11 December 2012 at 13:37:16 UTC, Iain Buclaw wrote:
 I foresee that this release will be the biggest pain in the ass 
 to
 merge downstream into GDC. I wonder if David on LDC's side 
 shares the
 same concern...

I have been busy with getting LDC ready for the next release lately, so I didn't have a closer look at the state of things with regard to merging yet. However, it seems like Kai has already put together a patch which merges the frontend as it was a few days ago (see https://github.com/ldc-developers/ldc/wiki/Building-and-hacking-LDC-on- indows-using-MSVC), so maybe he has any comments on this? David
Dec 11 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Monday, 10 December 2012 at 23:47:49 UTC, Walter Bright wrote:
 On 12/10/2012 3:35 PM, Jonathan M Davis wrote:
 On Monday, December 10, 2012 13:50:47 Walter Bright wrote:
 Why? (It's being heavily used by some people.)

It hasn't even been properly worked out yet, and new features like that shouldn't be being introduced in the main branch. It's not at all ready for general consumption, and if it's in there, people are going to start using it and then complaining when their code breaks when we change it later. It's the sort of thing that should be on a separate branch and not in master. Even worse, if the new stable branch that we've been talking about includes this, then you'll have programmers programming with it for months before they get the updates with the design that we're actually going to end up with, meaning that that much more code will be written for that much longer with an incomplete feature, waiting to be broken when the feature is actually updated in the version of the compiler that they're using.

We've debated this feature at length in various threads. It's under heavy use by some people. It does not break any existing code. I don't see any unresolved issue that should delay its incorporation.

It's still experimental and should be marked as such: it's just not ready for production. I can envision that in a few months, some people using it heavily will report that it's ugly and interacting badly with other features. You just can't decide that such a feature is ready for production without having a feedback after several months of usage by several users.
Dec 11 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Tuesday, 11 December 2012 at 04:36:36 UTC, Walter Bright wrote:
 On 12/10/2012 8:21 PM, Walter Bright wrote:
 Yes I understand that, and it is being extensively and heavily 
 used since the
 day I posted it, and no problems have arisen.

I should also add that the design was based on extensive discussions about it here last summer.

Discussions are not enough. Issues and usage patterns only appear after several months of experience by several users. We need several months of experience before actually gaining any insight and feedback on such a feature.
Dec 11 2012
prev sibling next sibling parent "Rob T" <rob ucora.com> writes:
On Wednesday, 12 December 2012 at 05:32:13 UTC, SomeDude wrote:
 On Tuesday, 11 December 2012 at 04:36:36 UTC, Walter Bright 
 wrote:
 On 12/10/2012 8:21 PM, Walter Bright wrote:
 Yes I understand that, and it is being extensively and 
 heavily used since the
 day I posted it, and no problems have arisen.

I should also add that the design was based on extensive discussions about it here last summer.

Discussions are not enough. Issues and usage patterns only appear after several months of experience by several users. We need several months of experience before actually gaining any insight and feedback on such a feature.

The root problem is that we have one branch for the unstable, testing, and stable code, and there's no possible way to make anyone happy with only that in place. The chaotic clash between stableness and unstableness will go away once we have a well thought out development and release process put in place, and it should make everyone happy because it can allow for breaking new changes to be introduced into an unstable branch without messing up the next pre-release version, and updates to pre-release won't mess up the current stable branch because it only gets updated with bug fixes. We're working on the new process here ... http://forum.dlang.org/thread/ka5rv5$2k60$1 digitalmars.com Please contribute your thoughts and time if you can, I think it'll be a very good investment for the future of D. Thanks! --rt
Dec 11 2012
prev sibling next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Monday, 10 December 2012 at 00:34:33 UTC, Walter Bright wrote:
 It's time to do a release; to that end we should be working on 
 tidying up the regressions.

 This will be the last official D1 release.

Just a heads up, GitHub has removed their Uploads feature[1]. Current uploads still work but this next release is going to need to either go back to the Digital Mars server like it was before or find a new home. I prefer the latter for speed reasons. Amazon S3 is fast and works well (it's what GitHub Uploads was backed by) and should be fairly affordable for the sizes we are talking about (I'd guess $3-4 per month). http://docs.amazonwebservices.com/AmazonS3/latest/gsg/GetStartedWithS3.html [1] https://github.com/blog/1302-goodbye-uploads
Dec 12 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-12-12 18:29, Brad Anderson wrote:

 Just a heads up, GitHub has removed their Uploads feature[1].

That sucks :( . But thanks for the heads up. -- /Jacob Carlborg
Dec 12 2012
prev sibling next sibling parent reply Jeff Nowakowski <jeff dilacero.org> writes:
On 12/12/2012 04:45 PM, Iain Buclaw wrote:
 Though one of the downsides would be that if I were to leave, so would the
site.

For the stability of the project, D needs more commodity-based services like Amazon S3, and less volunteer-hosted, ad hoc services administered by people in their spare time. If D can raise $30k for a one-time conference, raising the money to host project files should be a no-brainer.
Dec 13 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/13/2012 12:22 AM, Jeff Nowakowski wrote:
 On 12/12/2012 04:45 PM, Iain Buclaw wrote:
 Though one of the downsides would be that if I were to leave, so would the
site.

For the stability of the project, D needs more commodity-based services like Amazon S3, and less volunteer-hosted, ad hoc services administered by people in their spare time. If D can raise $30k for a one-time conference, raising the money to host project files should be a no-brainer.

I thought we had that with github, but then they disabled downloads.
Dec 13 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-12-13 10:01, Walter Bright wrote:

 I thought we had that with github, but then they disabled downloads.

Yeah, we _had_, they just removed it: https://github.com/blog/1302-goodbye-uploads -- /Jacob Carlborg
Dec 13 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/13/12 2:28 PM, Brad Roberts wrote:
 On Thu, 13 Dec 2012, Jacob Carlborg wrote:

 On 2012-12-13 10:01, Walter Bright wrote:

 I thought we had that with github, but then they disabled downloads.

Yeah, we _had_, they just removed it: https://github.com/blog/1302-goodbye-uploads -- /Jacob Carlborg

What they had was obviously non-maintainable in the long term. I'm not at all surprised it went away. It won't hurt us for long. I intend to have something to show by the end of the weekend using s3/cloudfront.

That's terrific, thanks Brad! Andrei
Dec 13 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/13/2012 11:33 AM, Andrei Alexandrescu wrote:
 On 12/13/12 2:28 PM, Brad Roberts wrote:
 On Thu, 13 Dec 2012, Jacob Carlborg wrote:

 On 2012-12-13 10:01, Walter Bright wrote:

 I thought we had that with github, but then they disabled downloads.

Yeah, we _had_, they just removed it: https://github.com/blog/1302-goodbye-uploads -- /Jacob Carlborg

What they had was obviously non-maintainable in the long term. I'm not at all surprised it went away. It won't hurt us for long. I intend to have something to show by the end of the weekend using s3/cloudfront.

That's terrific, thanks Brad!

I wholeheartedly concur!
Dec 13 2012
prev sibling parent Brad Roberts <braddr slice-2.puremagic.com> writes:
On Thu, 13 Dec 2012, Jacob Carlborg wrote:

 On 2012-12-13 10:01, Walter Bright wrote:
 
 I thought we had that with github, but then they disabled downloads.

Yeah, we _had_, they just removed it: https://github.com/blog/1302-goodbye-uploads -- /Jacob Carlborg

What they had was obviously non-maintainable in the long term. I'm not at all surprised it went away. It won't hurt us for long. I intend to have something to show by the end of the weekend using s3/cloudfront.
Dec 13 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 12 December 2012 17:29, Brad Anderson <eco gnuk.net> wrote:
 On Monday, 10 December 2012 at 00:34:33 UTC, Walter Bright wrote:
 It's time to do a release; to that end we should be working on tidying up
 the regressions.

 This will be the last official D1 release.

Just a heads up, GitHub has removed their Uploads feature[1]. Current uploads still work but this next release is going to need to either go back to the Digital Mars server like it was before or find a new home. I prefer the latter for speed reasons. Amazon S3 is fast and works well (it's what GitHub Uploads was backed by) and should be fairly affordable for the sizes we are talking about (I'd guess $3-4 per month). http://docs.amazonwebservices.com/AmazonS3/latest/gsg/GetStartedWithS3.html [1] https://github.com/blog/1302-goodbye-uploads

I can offer a server for that, hosted a datacentre in the UK. If I recall correctly, the net link are behind a 100GB link, testing the net speed, I get 250MB/s upload speed to Europe, only 20MB/s upload to America though. Regards, -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Dec 12 2012
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
On Wed, 12 Dec 2012, Iain Buclaw wrote:

 On 12 December 2012 17:29, Brad Anderson <eco gnuk.net> wrote:
 On Monday, 10 December 2012 at 00:34:33 UTC, Walter Bright wrote:
 It's time to do a release; to that end we should be working on tidying up
 the regressions.

 This will be the last official D1 release.

Just a heads up, GitHub has removed their Uploads feature[1]. Current uploads still work but this next release is going to need to either go back to the Digital Mars server like it was before or find a new home. I prefer the latter for speed reasons. Amazon S3 is fast and works well (it's what GitHub Uploads was backed by) and should be fairly affordable for the sizes we are talking about (I'd guess $3-4 per month). http://docs.amazonwebservices.com/AmazonS3/latest/gsg/GetStartedWithS3.html [1] https://github.com/blog/1302-goodbye-uploads

I can offer a server for that, hosted a datacentre in the UK. If I recall correctly, the net link are behind a 100GB link, testing the net speed, I get 250MB/s upload speed to Europe, only 20MB/s upload to America though. Regards, -- Iain Buclaw

Generous offer. I've been meaning to build packaging into the auto-tester for both release builds and more frequent (nightly or maybe even every cycle) builds. I was going to toss them into s3 with a cloudfront distribution in front of that. Sounds like that needs to go higher on the todo list given github's recent changes. The advantage of CloudFront is fast access all over the planet, though it has a cost associated with it. I'll bear that until it starts to hurt.
Dec 12 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 12 December 2012 21:10, Brad Roberts <braddr puremagic.com> wrote:
 On Wed, 12 Dec 2012, Iain Buclaw wrote:

 On 12 December 2012 17:29, Brad Anderson <eco gnuk.net> wrote:
 On Monday, 10 December 2012 at 00:34:33 UTC, Walter Bright wrote:
 It's time to do a release; to that end we should be working on tidying up
 the regressions.

 This will be the last official D1 release.

Just a heads up, GitHub has removed their Uploads feature[1]. Current uploads still work but this next release is going to need to either go back to the Digital Mars server like it was before or find a new home. I prefer the latter for speed reasons. Amazon S3 is fast and works well (it's what GitHub Uploads was backed by) and should be fairly affordable for the sizes we are talking about (I'd guess $3-4 per month). http://docs.amazonwebservices.com/AmazonS3/latest/gsg/GetStartedWithS3.html [1] https://github.com/blog/1302-goodbye-uploads

I can offer a server for that, hosted a datacentre in the UK. If I recall correctly, the net link are behind a 100GB link, testing the net speed, I get 250MB/s upload speed to Europe, only 20MB/s upload to America though. Regards, -- Iain Buclaw

Generous offer. I've been meaning to build packaging into the auto-tester for both release builds and more frequent (nightly or maybe even every cycle) builds. I was going to toss them into s3 with a cloudfront distribution in front of that. Sounds like that needs to go higher on the todo list given github's recent changes. The advantage of CloudFront is fast access all over the planet, though it has a cost associated with it. I'll bear that until it starts to hurt.

It's one of the perks of working in a UK-based cloud hosting company. I have been given the go ahead to build a server used as an auto-tester (initially intended specifically for GDC, though can throw in a DMD auto-tester too). Though one of the downsides would be that if I were to leave, so would the site. I also have another server host in the UK by Linode (this I pay for) - currently only used for gdcproject.org - this could be used as an EU based mirror for downloads. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Dec 12 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Wednesday, 12 December 2012 at 07:01:14 UTC, Rob T wrote:
 On Wednesday, 12 December 2012 at 05:32:13 UTC, SomeDude wrote:
 On Tuesday, 11 December 2012 at 04:36:36 UTC, Walter Bright 
 wrote:
 On 12/10/2012 8:21 PM, Walter Bright wrote:
 Yes I understand that, and it is being extensively and 
 heavily used since the
 day I posted it, and no problems have arisen.

I should also add that the design was based on extensive discussions about it here last summer.

Discussions are not enough. Issues and usage patterns only appear after several months of experience by several users. We need several months of experience before actually gaining any insight and feedback on such a feature.

The root problem is that we have one branch for the unstable, testing, and stable code, and there's no possible way to make anyone happy with only that in place. The chaotic clash between stableness and unstableness will go away once we have a well thought out development and release process put in place, and it should make everyone happy because it can allow for breaking new changes to be introduced into an unstable branch without messing up the next pre-release version, and updates to pre-release won't mess up the current stable branch because it only gets updated with bug fixes.

I think we all agree on this. Or else we should.
Dec 12 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 13 December 2012 08:22, Jeff Nowakowski <jeff dilacero.org> wrote:
 On 12/12/2012 04:45 PM, Iain Buclaw wrote:
 Though one of the downsides would be that if I were to leave, so would the
 site.

For the stability of the project, D needs more commodity-based services like Amazon S3, and less volunteer-hosted, ad hoc services administered by people in their spare time. If D can raise $30k for a one-time conference, raising the money to host project files should be a no-brainer.

As it is cloud-based in a way you don't need to know what platform it is running on, it can be moved from location to location with little or no downtime. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Dec 13 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Wednesday, 12 December 2012 at 20:55:52 UTC, Brad Roberts 
wrote:
 Generous offer.  I've been meaning to build packaging into the 
 auto-tester
 for both release builds and more frequent (nightly or maybe 
 even every
 cycle) builds.  I was going to toss them into s3 with a 
 cloudfront
 distribution in front of that.  Sounds like that needs to go 
 higher on the
 todo list given github's recent changes.

 The advantage of CloudFront is fast access all over the planet, 
 though it
 has a cost associated with it.  I'll bear that until it starts 
 to hurt.

+1. If we can get the files hosted on CloudFront, this would be more or less the optimal case – much, much easier than building our own »CDN« out of a few community-provided mirrors, and probably faster for most users as well. David
Dec 13 2012
prev sibling next sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Monday, 10 December 2012 at 00:34:33 UTC, Walter Bright wrote:
 It's time to do a release; to that end we should be working on 
 tidying up the regressions.

 This will be the last official D1 release.

Two things which I think we *must* address before the release, otherwise they will hurt us in the long run: - https://github.com/D-Programming-Language/dmd/pull/1287 (Make deprecations as warnings the default): Recently, an option to show deprecations as informational messages (i.e. not halting compilation) was added to DMD. Many people, including me, think that this should be the default behavior, but Walter seems to be against it for pretty much unspecified reasons. If we do not finish discussion on this before the release, but then decided to change the default behavior in the future, this will cause quite a bit more confusion as the "-di" switch will already have been released then. - Regarding UDAs: Releasing them in the current, not very well-tested state might not be the best idea, because we are effectively setting the design the stone, at least if we don't put a large »experimental« tag on them. However, this is not what I'm talking about here. Walter's current plan is to also keep the superseded bracket syntax around, making use of it only a warning: https://github.com/D-Programming-Language/dmd/commit/a04cf864b932061ad7b72e7cad8b16fabc6a825a This is a very, *very* questionable decision, as people won't even know that the syntax is deprecated if compiling without any flags, it adds a big maintenance burden (now the feature must go through the usual deprecation cycle), and there is no reason for keeping it around in the first place. No, backwards compatibility to an unreleased state of Git master is not a valid argument, especially if the feature suddenly appeared without prior notice. David
Dec 13 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-12-13 18:27, Iain Buclaw wrote:

 I am confused at this commit also.

Walter argues that people are already using it so it can't just be removed. I say, they're using an unreleased version of DMD, this is to be expected. -- /Jacob Carlborg
Dec 13 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/13/2012 12:46 PM, Jacob Carlborg wrote:
 On 2012-12-13 18:27, Iain Buclaw wrote:

 I am confused at this commit also.

Walter argues that people are already using it so it can't just be removed. I say, they're using an unreleased version of DMD, this is to be expected.

They have a large code base, and are using it heavily.
Dec 13 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/13/2012 1:44 PM, deadalnix wrote:
 You are engaging the whole community into something you dropped here by
surprise
 and then claiming that some people uses. We don't even know who they are ! How
 can we support your point ?

It's Remedy Games. It's a big deal for them, and their use of D is a big deal for us, big enough that we can bend our procedure for them. They were also under severe time pressure. They began using UDAs the same day I implemented them. Remedy could very well be the tipping point for D, and I'm not going to allow them to fail. It's also not a conflict of interest - what they want from D is really what we all want from it. I understand that some of you may be frustrated by my giving their needs priority, but I hope that the end result will be better for all of us than if I didn't, and that you'll indulge me with this.
Dec 13 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/13/2012 4:05 PM, deadalnix wrote:
 You have to understand that this isn't their need that is important here. They
 need stuff that we mostly all need, so I tend to agree. The fact is that you
 unilaterally decide to give that priority, when we are not even aware of them
or
 of their needs. And that is the problem.

Remedy only recently allowed me to talk about it.
 Isn't it preferable to help them to migrate to the new syntax rather than
 bringing everybody in the same boat ? The feature hasn't been released, so I'm
 pretty sure most D actor don't have a lot of them in their codebase, which make
 the support into the transition easy.

 Introducing new deprecated feature into a release seems completely backward to
 me, and reading other comment, it seems that I'm not the only one. We should
 consider other solutions before sticking to that one. And you have to work with
 D community on that one, or you'll loose it.

It was the D community that selected the (attribute) syntax, and the overall design was based on extensive public discussion threads here about it.
Dec 13 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-12-14 01:19, Walter Bright wrote:

 It was the D community that selected the  (attribute) syntax, and the
 overall design was based on extensive public discussion threads here
 about it.

And you still implemented the [attribute] syntax first. -- /Jacob Carlborg
Dec 13 2012
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 12/14/2012 08:42 AM, Jacob Carlborg wrote:
 On 2012-12-14 01:19, Walter Bright wrote:

 It was the D community that selected the  (attribute) syntax, and the
 overall design was based on extensive public discussion threads here
 about it.

And you still implemented the [attribute] syntax first.

It is my understanding that the public discussion deciding in favour of (attribute) was started after [attribute] had already been implemented.
Dec 14 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, December 14, 2012 09:34:50 PM Timon Gehr wrote:
 On 12/14/2012 08:42 AM, Jacob Carlborg wrote:
 On 2012-12-14 01:19, Walter Bright wrote:
 It was the D community that selected the  (attribute) syntax, and the
 overall design was based on extensive public discussion threads here
 about it.

And you still implemented the [attribute] syntax first.

It is my understanding that the public discussion deciding in favour of (attribute) was started after [attribute] had already been implemented.

Yes. But I believe that pretty much every other discussion on it prior to it actually being implemented discussed using parens and not brackets. - Jonathan M Davis
Dec 14 2012
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 14 December 2012 21:28, Jonathan M Davis <jmdavisProg gmx.com> wrote:
 On Friday, December 14, 2012 09:34:50 PM Timon Gehr wrote:
 On 12/14/2012 08:42 AM, Jacob Carlborg wrote:
 On 2012-12-14 01:19, Walter Bright wrote:
 It was the D community that selected the  (attribute) syntax, and the
 overall design was based on extensive public discussion threads here
 about it.

And you still implemented the [attribute] syntax first.

It is my understanding that the public discussion deciding in favour of (attribute) was started after [attribute] had already been implemented.

Yes. But I believe that pretty much every other discussion on it prior to it actually being implemented discussed using parens and not brackets. - Jonathan M Davis

Wasn't the last discussion on it over a year ago? (Prior to it actually being implemented). -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Dec 14 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/13/2012 4:17 PM, David Nadlinger wrote:
 1. How much work would it be for the guys at Remedy Games to convert their
 codebase from [] to  ()?

I don't know. All I know is it's a lot of code.
 2. What is your plan moving forward, i.e. how to you intend to handle
 deprecation/removal of the feature?

Warning, then deprecation, then removal. The usual.
 3. Why is the message you introduced a warning instead of a normal deprecation
 error?

Because skipping the warning phase has historically been too abrupt for people.
 For 1., I would guess at most something like half an hour for a large codebase
 where the feature is used pervasively (you just keep editing/compiling until
 there are no more syntax errors), which is why I can't quite understand the
fuzz
 you are making about keeping the feature. And even if they cannot switch right
 now, as the Remedy guys are obviously willing to use experimental compiler
 versions, can't they just use a patched version until they have made the
switch?

Like any major user of a language, they want confidence in our full support of them. Asking them to use a patched or branch version of the compiler does not inspire confidence.
 Let me also repeat the most important point: If we release 2.061 like this, DMD
 will silently accept the old syntax, so your decision will actually lead to
 *more* breakage when the feature is removed in the future.

The [ ] syntax was never documented and won't be, so I doubt there'll be any new use of it, nor does it interfere with anything else. What I'm doing is hardly unique in business history. When Boeing designed the 707, they showed the prototype to Pan Am, their biggest potential customer. Pan Am wanted a slightly wider fuselage. At enormous expense, Boeing threw out their tooling and built all new tooling and a new design, all just to make the sale to Pan Am. It paid off enormously for Boeing, because with Pan Am buying 707s, the other airlines all couldn't wait to buy them, too. When Westinghouse had AC and Edison had DC, they competed for the Niagra power project. Both knew that would be the lynchpin of their industry, and both did whatever it took to get that design win. Westinghouse got the contract, and that's why our electrical grid is 60 Hz AC. Ok, we're not Boeing or Westinghouse. But we have an opportunity to go big time, and I'm not going to let that get away from us.
Dec 13 2012
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/13/2012 4:55 PM, deadalnix wrote:
 You'll go nowhere without a community.

And we need major users, too. It's a balancing act. And I wish to point out, again, that the design was based on extensive discussion threads right here in the ng, and the design was modified based on feedback right here in the ng. So to say the community was uninvolved in this is incorrect, it is very much a community design. And, if you recall, I was initially opposed to UDAs and skeptical they'd be of any actual use :-)
Dec 13 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/13/2012 5:33 PM, kenji hara wrote:
 Yet not released feature is not visible for almost D users.
 What you are going to do in 2.061 is to add a warned feature suddenly.

 But, it is certainly no problem for almost D users (unless users use old  []
 syntax, compiler never warn). I think what you must to do is to cut the time
 limit of removing  [] syntax. X months after?  In version 2.0yy?
 You should say much better answer than *in the future*.

I think in the past we've been too hasty sometimes in removing things. I think a better approach will be to allow some time to elapse, and then ask in the ng if there will be any problems with moving to the next stage.
Dec 13 2012
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/13/12 8:55 PM, kenji hara wrote:
 I think we should have -future/-f switch and  future attribute.
 It is a rough idea, but seems a required compiler feature.

 Kenji Hara

That sounds interesting. Regarding attributes, a simple solution is to release it but without official documentation. We place the documentation in a /unstable/ directory of the website, distinct from the central mainstream documentation. People who already started or want to start using attributes understand there are instabilities associated with them. Existing code is unaffected, only certain programs that are technically invalid will actually compile and run. Works? Andrei
Dec 13 2012
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 12/23/2012 01:29 AM, Iain Buclaw wrote:
 On 23 December 2012 00:11, ixid <nuaccount gmail.com
 <mailto:nuaccount gmail.com>> wrote:
...


     Surely someone like Walter or yourself (I am not suggesting that
     it's your responsibility) could have written a reliable find and
     replace for the other attribute syntax, fixed Remedy's codebase and
     allowed everyone to move on?



 Yes, but using sed to find and replace code is fraught with dangers and
 should be avoided with a large stick.

 --
 Iain Buclaw

 *(p < e ? p++ : p) = (c & 0x0f) + '0';

I guess he meant a tool based on the compiler front end.
Dec 22 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, December 14, 2012 01:17:08 David Nadlinger wrote:
 For 1., I would guess at most something like half an hour for a
 large codebase where the feature is used pervasively (you just
 keep editing/compiling until there are no more syntax errors),
 which is why I can't quite understand the fuzz you are making
 about keeping the feature. And even if they cannot switch right
 now, as the Remedy guys are obviously willing to use experimental
 compiler versions, can't they just use a patched version until
 they have made the switch?

I would think that they could just use the version that they're using now until they've had time to make the change (which I wouldn't think would take all that long, though it wouldn't surprise me if it took them a few hours rather than half an hour if their code base is large). I can only see that being an issue if they absolutely must have some other fix that's been checked in since that change. Regardless, I think that this needs to be fixed before the actual release. - Jonathan M Davis
Dec 13 2012
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/13/2012 5:10 PM, H. S. Teoh wrote:
 Remedy adopting D

Saying that would be premature and incorrect at the moment. We still have to ensure that Remedy wins with D. This is an ongoing thing.
Dec 13 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-12-14 01:17, David Nadlinger wrote:

 1. How much work would it be for the guys at Remedy Games to convert
 their codebase from [] to  ()?

Basically none. Just do a global search-and-replace with regular expression. Search for \[(.+)\] replace with ($1). It won't cover 100% percent but it will work pretty well. -- /Jacob Carlborg
Dec 13 2012
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/13/12 6:02 PM, Denis Koroskin wrote:
 On Thu, 13 Dec 2012 13:37:07 -0800, Walter Bright
 <newshound2 digitalmars.com> wrote:

 On 12/13/2012 12:46 PM, Jacob Carlborg wrote:
 On 2012-12-13 18:27, Iain Buclaw wrote:

 I am confused at this commit also.

Walter argues that people are already using it so it can't just be removed. I say, they're using an unreleased version of DMD, this is to be expected.

They have a large code base, and are using it heavily.

Why must the rest of the world suffer just because someone decided to use an experimental feature?

Just talked to Walter and I think it's safe to drop this, although I clearly agree with the principle. We have a strategic potential user who could make a large difference in terms of corporate D adoption. We've been advised to not divulge much information so far because they only want to announce after they've committed and in a specific setting. Clearly that shouldn't mean the community's views and needs should be neglected! However, given our commitment to better process in the future, we hope to get agreement on letting this one rushed feature be. I count on your understanding. Thanks, Andrei
Dec 13 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-12-14 04:30, Jesse Phillips wrote:

 The process must be defined before we can use it and UDA has already
 missed that boat. I'm in agreement with the way Andrei has said it, we
 need to let this slide.

Sure, I can agree in this case. But we need to stop putting out new release until we have the new process in place. Otherwise we will have this problem all over again. We already talked about a new release process three releases ago. -- /Jacob Carlborg
Dec 13 2012
prev sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
12/14/2012 7:30 AM, Jesse Phillips пишет:
 On Thursday, 13 December 2012 at 23:41:32 UTC, RenatoUtsch wrote:
 Please, lets not release something not thoroughly tested when we are
 in the middle of the new development process discussion, we are trying
 to avoid exactly this kind of thing.

The process must be defined before we can use it and UDA has already missed that boat. I'm in agreement with the way Andrei has said it, we need to let this slide.
 Even if the feature is not introducing backwards incompatible changes,
 this will cause problems when we discover, in the future, that we made
 some bad decision and won't be able to change it anymore.

Hopefully we are defining the process that we can handle these changes. We'll never have enough testing to not make this mistake. So let us go make this process for Walter to follow and neg him later. (You don't throw people in jail when what they did was criminalized a year later)

Something I can agree with. -- Dmitry Olshansky
Dec 14 2012
prev sibling next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 13 December 2012 16:57, David Nadlinger <see klickverbot.at> wrote:
 On Monday, 10 December 2012 at 00:34:33 UTC, Walter Bright wrote:
 It's time to do a release; to that end we should be working on tidying u=


 the regressions.

 This will be the last official D1 release.

Two things which I think we *must* address before the release, otherwise they will hurt us in the long run: - https://github.com/D-Programming-Language/dmd/pull/1287 (Make deprecations as warnings the default): Recently, an option to show deprecations as informational messages (i.e. not halting compilation) was added to DMD. Many people, including me, think that this should be the default behavior, but Walter seems to be against it for pretty much unspecified reasons. If we do not finish discussion on this before the release, but then decided to change the default behavior in the future, t=

 will cause quite a bit more confusion as the "-di" switch will already ha=

 been released then.


  - Regarding UDAs: Releasing them in the current, not very well-tested st=

 might not be the best idea, because we are effectively setting the design
 the stone, at least if we don't put a large =BBexperimental=AB tag on the=

 However, this is not what I'm talking about here.

 Walter's current plan is to also keep the superseded bracket syntax aroun=

 making use of it only a warning:
 https://github.com/D-Programming-Language/dmd/commit/a04cf864b932061ad7b7=


I am confused at this commit also. --=20 Iain Buclaw *(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Dec 13 2012
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Dec 15, 2012 at 06:35:33PM +0100, RenatoUtsch wrote:
 On Saturday, 15 December 2012 at 16:16:11 UTC, SomeDude wrote:

Yes, but what H.S. Theoh wrote about the desperate need of process
is still true and correct. Like many others here, I think it's the
biggest problem with D right now for its adoption. I for one will
never consider using D for my main line of work without a true
STABLE branch: a branch you can rely on. And yet I'm pretty sold
to the language, but when your project is at stake, what you need
is security. And the current development scheme doesn't provide
that.

Yeah, but if people doesn't help to define a new process, no process will ever be defined. We are trying to do something like that, any support or ideas will be helpful. The community needs to help to define this, and Walter already said that he will agree on what the community defines. See: http://wiki.dlang.org/Release_Process http://forum.dlang.org/thread/ka5rv5$2k60$1 digitalmars.com

I'd also like to add that if anyone has any ideas to improve or refine the current proposed process, they should add their suggestions to the talk page: http://wiki.dlang.org/Talk:Release_Process That way, the ideas won't get lost in ether after the forum threads die off, and it keeps everything in one place instead of sprinkled throughout multiple places in ancient forum threads. T -- When solving a problem, take care that you do not become part of the problem.
Dec 15 2012
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 13 December 2012 at 16:57:10 UTC, David Nadlinger 
wrote:
 On Monday, 10 December 2012 at 00:34:33 UTC, Walter Bright 
 wrote:
 It's time to do a release; to that end we should be working on 
 tidying up the regressions.

 This will be the last official D1 release.

Two things which I think we *must* address before the release, otherwise they will hurt us in the long run: - https://github.com/D-Programming-Language/dmd/pull/1287 (Make deprecations as warnings the default): Recently, an option to show deprecations as informational messages (i.e. not halting compilation) was added to DMD. Many people, including me, think that this should be the default behavior, but Walter seems to be against it for pretty much unspecified reasons. If we do not finish discussion on this before the release, but then decided to change the default behavior in the future, this will cause quite a bit more confusion as the "-di" switch will already have been released then. - Regarding UDAs: Releasing them in the current, not very well-tested state might not be the best idea, because we are effectively setting the design the stone, at least if we don't put a large »experimental« tag on them. However, this is not what I'm talking about here. Walter's current plan is to also keep the superseded bracket syntax around, making use of it only a warning: https://github.com/D-Programming-Language/dmd/commit/a04cf864b932061ad7b72e7cad8b16fabc6a825a This is a very, *very* questionable decision, as people won't even know that the syntax is deprecated if compiling without any flags, it adds a big maintenance burden (now the feature must go through the usual deprecation cycle), and there is no reason for keeping it around in the first place. No, backwards compatibility to an unreleased state of Git master is not a valid argument, especially if the feature suddenly appeared without prior notice.

+1 !
Dec 13 2012
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 13 Dec 2012 00:22:55 -0800, Jeff Nowakowski <jeff dilacero.org>  
wrote:

 On 12/12/2012 04:45 PM, Iain Buclaw wrote:
 Though one of the downsides would be that if I were to leave, so would  
 the site.

For the stability of the project, D needs more commodity-based services like Amazon S3, and less volunteer-hosted, ad hoc services administered by people in their spare time. If D can raise $30k for a one-time conference, raising the money to host project files should be a no-brainer.

Why not just use BitTorrent?
Dec 13 2012
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 13 December 2012 at 21:37:07 UTC, Walter Bright 
wrote:
 On 12/13/2012 12:46 PM, Jacob Carlborg wrote:
 On 2012-12-13 18:27, Iain Buclaw wrote:

 I am confused at this commit also.

Walter argues that people are already using it so it can't just be removed. I say, they're using an unreleased version of DMD, this is to be expected.

They have a large code base, and are using it heavily.

This was an unreleased feature. It was supposed to change and people using it must have known that. You are engaging the whole community into something you dropped here by surprise and then claiming that some people uses. We don't even know who they are ! How can we support your point ?
Dec 13 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 13 December 2012 21:37, Walter Bright <newshound2 digitalmars.com> wrote:
 On 12/13/2012 12:46 PM, Jacob Carlborg wrote:
 On 2012-12-13 18:27, Iain Buclaw wrote:

 I am confused at this commit also.

Walter argues that people are already using it so it can't just be removed. I say, they're using an unreleased version of DMD, this is to be expected.

They have a large code base, and are using it heavily.

People shouldn't be using development compilers in production code then. :o) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Dec 13 2012
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 13 Dec 2012 13:37:07 -0800, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 12/13/2012 12:46 PM, Jacob Carlborg wrote:
 On 2012-12-13 18:27, Iain Buclaw wrote:

 I am confused at this commit also.

Walter argues that people are already using it so it can't just be removed. I say, they're using an unreleased version of DMD, this is to be expected.

They have a large code base, and are using it heavily.

Why must the rest of the world suffer just because someone decided to use an experimental feature?
Dec 13 2012
prev sibling next sibling parent "RenatoUtsch" <renatoutsch gmail.com> writes:
On Thursday, 13 December 2012 at 21:37:07 UTC, Walter Bright 
wrote:
 On 12/13/2012 12:46 PM, Jacob Carlborg wrote:
 On 2012-12-13 18:27, Iain Buclaw wrote:

 I am confused at this commit also.

Walter argues that people are already using it so it can't just be removed. I say, they're using an unreleased version of DMD, this is to be expected.

They have a large code base, and are using it heavily.

If they used a development compiler to write their code, they should be able to continue doing that. This feature needs testing before being rock solid and good to release. Please, lets not release something not thoroughly tested when we are in the middle of the new development process discussion, we are trying to avoid exactly this kind of thing. Even if the feature is not introducing backwards incompatible changes, this will cause problems when we discover, in the future, that we made some bad decision and won't be able to change it anymore.
Dec 13 2012
prev sibling next sibling parent "RenatoUtsch" <renatoutsch gmail.com> writes:
On Thursday, 13 December 2012 at 23:47:56 UTC, Walter Bright 
wrote:
 On 12/13/2012 1:44 PM, deadalnix wrote:
 You are engaging the whole community into something you 
 dropped here by surprise
 and then claiming that some people uses. We don't even know 
 who they are ! How
 can we support your point ?

It's Remedy Games. It's a big deal for them, and their use of D is a big deal for us, big enough that we can bend our procedure for them. They were also under severe time pressure. They began using UDAs the same day I implemented them. Remedy could very well be the tipping point for D, and I'm not going to allow them to fail. It's also not a conflict of interest - what they want from D is really what we all want from it. I understand that some of you may be frustrated by my giving their needs priority, but I hope that the end result will be better for all of us than if I didn't, and that you'll indulge me with this.

Maybe this is a special occasion. To have such a big enterprise starting to use D, maybe there are more pros than cons.
Dec 13 2012
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 13 December 2012 at 23:47:56 UTC, Walter Bright 
wrote:
 It's Remedy Games. It's a big deal for them, and their use of D 
 is a big deal for us, big enough that we can bend our procedure 
 for them. They were also under severe time pressure. They began 
 using UDAs the same day I implemented them. Remedy could very 
 well be the tipping point for D, and I'm not going to allow 
 them to fail.

 It's also not a conflict of interest - what they want from D is 
 really what we all want from it.

 I understand that some of you may be frustrated by my giving 
 their needs priority, but I hope that the end result will be 
 better for all of us than if I didn't, and that you'll indulge 
 me with this.

You have to understand that this isn't their need that is important here. They need stuff that we mostly all need, so I tend to agree. The fact is that you unilaterally decide to give that priority, when we are not even aware of them or of their needs. And that is the problem. I understand that this game is a big deal for D and I'm all for supporting that effort. But, it can't be done against the community, or you'll alienate everybody here. We all here are trying to support D in different ways, but if we are not aware of the goals, it simply will not work. You will ends up with a fork continuing that way, and I think phobos vs Tango for D1 was already enough. Isn't it preferable to help them to migrate to the new syntax rather than bringing everybody in the same boat ? The feature hasn't been released, so I'm pretty sure most D actor don't have a lot of them in their codebase, which make the support into the transition easy. Introducing new deprecated feature into a release seems completely backward to me, and reading other comment, it seems that I'm not the only one. We should consider other solutions before sticking to that one. And you have to work with D community on that one, or you'll loose it.
Dec 13 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 13 December 2012 at 23:47:56 UTC, Walter Bright 
wrote:
 They began using UDAs the same day I implemented them.

I intend to start using them the day 2.061 comes out... the UDA feature is going to be incredibly useful for me too, and the implementation you've made is substantially identical to what I've asked for and discussed here in the past, so I expect it will work very well.
Dec 13 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Thursday, 13 December 2012 at 23:47:56 UTC, Walter Bright 
wrote:
 I understand that some of you may be frustrated by my giving 
 their needs priority, […]

It's *not* your choice of priorities which strikes me as odd, it's that the situations seems like you made an objectively bad technical decision for no good reason, and refuse to back off after other people have made you aware of the consequences. In order to make your reasoning easier to understand for other people, could you maybe answer the following questions, setting aside all the other previously mentioned points (supporting an unreleased version, etc.) for the moment? 1. How much work would it be for the guys at Remedy Games to convert their codebase from [] to ()? 2. What is your plan moving forward, i.e. how to you intend to handle deprecation/removal of the feature? 3. Why is the message you introduced a warning instead of a normal deprecation error? ——— For 1., I would guess at most something like half an hour for a large codebase where the feature is used pervasively (you just keep editing/compiling until there are no more syntax errors), which is why I can't quite understand the fuzz you are making about keeping the feature. And even if they cannot switch right now, as the Remedy guys are obviously willing to use experimental compiler versions, can't they just use a patched version until they have made the switch? I'm pretty much in the dark about 2. and 3., but let me note that the questions don't even arise if we just remove the syntax and call it a day. Let me also repeat the most important point: If we release 2.061 like this, DMD will silently accept the old syntax, so your decision will actually lead to *more* breakage when the feature is removed in the future. David
Dec 13 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Friday, 14 December 2012 at 00:42:58 UTC, Walter Bright wrote:
 For 1., I would guess at most something like half an hour for 
 a large codebase
 where the feature is used pervasively (you just keep 
 editing/compiling until
 there are no more syntax errors), which is why I can't quite 
 understand the fuzz
 you are making about keeping the feature. And even if they 
 cannot switch right
 now, as the Remedy guys are obviously willing to use 
 experimental compiler
 versions, can't they just use a patched version until they 
 have made the switch?

Like any major user of a language, they want confidence in our full support of them. Asking them to use a patched or branch version of the compiler does not inspire confidence.

This is WHAT THEY ARE DOING ALREADY.
Dec 13 2012
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 14 December 2012 at 00:42:58 UTC, Walter Bright wrote:
 Like any major user of a language, they want confidence in our 
 full support of them. Asking them to use a patched or branch 
 version of the compiler does not inspire confidence.

But nobody agreed here on supporting that ! It never was released !
 What I'm doing is hardly unique in business history. When 
 Boeing designed the 707, they showed the prototype to Pan Am, 
 their biggest potential customer. Pan Am wanted a slightly 
 wider fuselage. At enormous expense, Boeing threw out their 
 tooling and built all new tooling and a new design, all just to 
 make the sale to Pan Am. It paid off enormously for Boeing, 
 because with Pan Am buying 707s, the other airlines all 
 couldn't wait to buy them, too.

I'm pretty sure Boeing employee were informed and payed for that work. Here you have a community that is not informed and work on D on their free time.
 When Westinghouse had AC and Edison had DC, they competed for 
 the Niagra power project. Both knew that would be the lynchpin 
 of their industry, and both did whatever it took to get that 
 design win. Westinghouse got the contract, and that's why our 
 electrical grid is 60 Hz AC.

Considering the physics constraints, DC isn't even an option. Having the contract at the time would have simply delayed electricity deployment like we know now.
 Ok, we're not Boeing or Westinghouse. But we have an 
 opportunity to go big time, and I'm not going to let that get 
 away from us.

You'll go nowhere without a community.
Dec 13 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Dec 14, 2012 at 01:05:21AM +0100, deadalnix wrote:
 On Thursday, 13 December 2012 at 23:47:56 UTC, Walter Bright wrote:
It's Remedy Games. It's a big deal for them, and their use of D is
a big deal for us, big enough that we can bend our procedure for
them. They were also under severe time pressure. They began using
UDAs the same day I implemented them. Remedy could very well be
the tipping point for D, and I'm not going to allow them to fail.

It's also not a conflict of interest - what they want from D is
really what we all want from it.

I understand that some of you may be frustrated by my giving their
needs priority, but I hope that the end result will be better for
all of us than if I didn't, and that you'll indulge me with this.

You have to understand that this isn't their need that is important here. They need stuff that we mostly all need, so I tend to agree. The fact is that you unilaterally decide to give that priority, when we are not even aware of them or of their needs. And that is the problem. I understand that this game is a big deal for D and I'm all for supporting that effort. But, it can't be done against the community, or you'll alienate everybody here. We all here are trying to support D in different ways, but if we are not aware of the goals, it simply will not work. You will ends up with a fork continuing that way, and I think phobos vs Tango for D1 was already enough. Isn't it preferable to help them to migrate to the new syntax rather than bringing everybody in the same boat ? The feature hasn't been released, so I'm pretty sure most D actor don't have a lot of them in their codebase, which make the support into the transition easy. Introducing new deprecated feature into a release seems completely backward to me, and reading other comment, it seems that I'm not the only one. We should consider other solutions before sticking to that one. And you have to work with D community on that one, or you'll loose it.

This just underscores our desperate need to start implementing a sane release process, as proposed by the ongoing discussion in the PROCESS thread. And now is about the most critical time for us to start doing this. We're on the verge of possibly hitting it big, and so big changes in the community are likely to be on the horizon. To deal with the influx of users that will very likely flood in when the news about Remedy adopting D goes out, we better get our act together NOW and start using a sane release process. Otherwise, D's potentially big break in terms of adoption may turn out to break D, possibly fatally. The current proposal is being drafted up on the wiki: http://wiki.dlang.org/Release_Process It would be very helpful if the core developers (esp. Andrei, who is apparently supposed to head this up) gave some input as to whether the proposal is workable, and/or what needs to be fixed or changed in order for make it workable. I don't think it's an overstatement to say that we desperately need to get this worked out, the sooner the better. It had better be implemented by the time the influx of users comes, otherwise D may never get rid of the bad reputation of releases being badly managed (no matter what the actual situation is). T -- The best way to destroy a cause is to defend it poorly.
Dec 13 2012
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--e0cb4efe288a333dd404d0c60475
Content-Type: text/plain; charset=UTF-8

Yet not released feature is not visible for almost D users.
What you are going to do in 2.061 is to add a warned feature suddenly.

But, it is certainly no problem for almost D users (unless users use old
 [] syntax, compiler never warn). I think what you must to do is to cut the
time limit of removing  [] syntax. X months after?  In version 2.0yy?
You should say much better answer than *in the future*.

Kenji Hara

2012/12/14 Walter Bright <newshound2 digitalmars.com>

 On 12/13/2012 4:17 PM, David Nadlinger wrote:

 1. How much work would it be for the guys at Remedy Games to convert their
 codebase from [] to  ()?

I don't know. All I know is it's a lot of code. 2. What is your plan moving forward, i.e. how to you intend to handle
 deprecation/removal of the feature?

Warning, then deprecation, then removal. The usual. 3. Why is the message you introduced a warning instead of a normal
 deprecation
 error?

Because skipping the warning phase has historically been too abrupt for people. For 1., I would guess at most something like half an hour for a large
 codebase
 where the feature is used pervasively (you just keep editing/compiling
 until
 there are no more syntax errors), which is why I can't quite understand
 the fuzz
 you are making about keeping the feature. And even if they cannot switch
 right
 now, as the Remedy guys are obviously willing to use experimental compiler
 versions, can't they just use a patched version until they have made the
 switch?

Like any major user of a language, they want confidence in our full support of them. Asking them to use a patched or branch version of the compiler does not inspire confidence. Let me also repeat the most important point: If we release 2.061 like
 this, DMD
 will silently accept the old syntax, so your decision will actually lead
 to
 *more* breakage when the feature is removed in the future.

The [ ] syntax was never documented and won't be, so I doubt there'll be any new use of it, nor does it interfere with anything else. What I'm doing is hardly unique in business history. When Boeing designed the 707, they showed the prototype to Pan Am, their biggest potential customer. Pan Am wanted a slightly wider fuselage. At enormous expense, Boeing threw out their tooling and built all new tooling and a new design, all just to make the sale to Pan Am. It paid off enormously for Boeing, because with Pan Am buying 707s, the other airlines all couldn't wait to buy them, too. When Westinghouse had AC and Edison had DC, they competed for the Niagra power project. Both knew that would be the lynchpin of their industry, and both did whatever it took to get that design win. Westinghouse got the contract, and that's why our electrical grid is 60 Hz AC. Ok, we're not Boeing or Westinghouse. But we have an opportunity to go big time, and I'm not going to let that get away from us.

--e0cb4efe288a333dd404d0c60475 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_extra"><div>Yet not released feature is not visible for= almost D users.=C2=A0</div><div>What you are going to do in 2.061 is to ad= d a warned feature suddenly.</div><div><br></div><div>But, it is certainly = no problem for almost D users (unless users use old [] syntax, compiler ne= ver warn). I think what you must to do is to cut the time limit of removing= [] syntax. X months after? =C2=A0In version 2.0yy?=C2=A0</div> <div>You should say much better answer than *in the future*.</div><div><br>= </div><div>Kenji Hara</div><div><br></div><div class=3D"gmail_quote">2012/1= 2/14 Walter Bright <span dir=3D"ltr">&lt;<a href=3D"mailto:newshound2 digit= almars.com" target=3D"_blank">newshound2 digitalmars.com</a>&gt;</span><br> <blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;= margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color= :rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=3D"i= m"> On 12/13/2012 4:17 PM, David Nadlinger wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;= margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color= :rgb(204,204,204);border-left-style:solid;padding-left:1ex"> 1. How much work would it be for the guys at Remedy Games to convert their<= br> codebase from [] to ()?<br> </blockquote> <br></div> I don&#39;t know. All I know is it&#39;s a lot of code.<div class=3D"im"><b= r> <br> <br> <blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;= margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color= :rgb(204,204,204);border-left-style:solid;padding-left:1ex"> 2. What is your plan moving forward, i.e. how to you intend to handle<br> deprecation/removal of the feature?<br> </blockquote> <br></div> Warning, then deprecation, then removal. The usual.<div class=3D"im"><br> <br> <br> <blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;= margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color= :rgb(204,204,204);border-left-style:solid;padding-left:1ex"> 3. Why is the message you introduced a warning instead of a normal deprecat= ion<br> error?<br> </blockquote> <br></div> Because skipping the warning phase has historically been too abrupt for peo= ple.<div class=3D"im"><br> <br> <br> <blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;= margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color= :rgb(204,204,204);border-left-style:solid;padding-left:1ex"> For 1., I would guess at most something like half an hour for a large codeb= ase<br> where the feature is used pervasively (you just keep editing/compiling unti= l<br> there are no more syntax errors), which is why I can&#39;t quite understand= the fuzz<br> you are making about keeping the feature. And even if they cannot switch ri= ght<br> now, as the Remedy guys are obviously willing to use experimental compiler<= br> versions, can&#39;t they just use a patched version until they have made th= e switch?<br> </blockquote> <br></div> Like any major user of a language, they want confidence in our full support= of them. Asking them to use a patched or branch version of the compiler do= es not inspire confidence.<div class=3D"im"><br> <br> <br> <blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;= margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color= :rgb(204,204,204);border-left-style:solid;padding-left:1ex"> Let me also repeat the most important point: If we release 2.061 like this,= DMD<br> will silently accept the old syntax, so your decision will actually lead to= <br> *more* breakage when the feature is removed in the future.<br> </blockquote> <br></div> The [ ] syntax was never documented and won&#39;t be, so I doubt there&#39;= ll be any new use of it, nor does it interfere with anything else.<br> <br> <br> What I&#39;m doing is hardly unique in business history. When Boeing design= ed the 707, they showed the prototype to Pan Am, their biggest potential cu= stomer. Pan Am wanted a slightly wider fuselage. At enormous expense, Boein= g threw out their tooling and built all new tooling and a new design, all j= ust to make the sale to Pan Am. It paid off enormously for Boeing, because = with Pan Am buying 707s, the other airlines all couldn&#39;t wait to buy th= em, too.<br> <br> When Westinghouse had AC and Edison had DC, they competed for the Niagra po= wer project. Both knew that would be the lynchpin of their industry, and bo= th did whatever it took to get that design win. Westinghouse got the contra= ct, and that&#39;s why our electrical grid is 60 Hz AC.<br> <br> Ok, we&#39;re not Boeing or Westinghouse. But we have an opportunity to go = big time, and I&#39;m not going to let that get away from us.<br> </blockquote></div><br></div> --e0cb4efe288a333dd404d0c60475--
Dec 13 2012
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--e0cb4efe288ad830cf04d0c653db
Content-Type: text/plain; charset=UTF-8

I think we should have -future/-f switch and  future attribute.
It is a rough idea, but seems a required compiler feature.

Kenji Hara

2012/12/14 Walter Bright <newshound2 digitalmars.com>

 On 12/13/2012 5:33 PM, kenji hara wrote:

 Yet not released feature is not visible for almost D users.
 What you are going to do in 2.061 is to add a warned feature suddenly.

 But, it is certainly no problem for almost D users (unless users use old
  []
 syntax, compiler never warn). I think what you must to do is to cut the
 time
 limit of removing  [] syntax. X months after?  In version 2.0yy?
 You should say much better answer than *in the future*.

I think in the past we've been too hasty sometimes in removing things. I think a better approach will be to allow some time to elapse, and then ask in the ng if there will be any problems with moving to the next stage.

--e0cb4efe288ad830cf04d0c653db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div><div>I think we should have -future/-f switch and future attribute.</= div><div>It is a rough idea, but seems a required compiler feature.</div></= div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Kenji H= ara<br> <br><div class=3D"gmail_quote">2012/12/14 Walter Bright <span dir=3D"ltr">&= lt;<a href=3D"mailto:newshound2 digitalmars.com" target=3D"_blank">newshoun= d2 digitalmars.com</a>&gt;</span><br><blockquote class=3D"gmail_quote" styl= e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 12/13/2012 5:33 PM, kenji hara wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Yet not released feature is not visible for almost D users.<br> What you are going to do in 2.061 is to add a warned feature suddenly.<br> <br> But, it is certainly no problem for almost D users (unless users use old [= ]<br> syntax, compiler never warn). I think what you must to do is to cut the tim= e<br> limit of removing [] syntax. X months after? =C2=A0In version 2.0yy?<br> You should say much better answer than *in the future*.<br> </blockquote> <br></div> I think in the past we&#39;ve been too hasty sometimes in removing things. = I think a better approach will be to allow some time to elapse, and then as= k in the ng if there will be any problems with moving to the next stage.<br=

<br> </blockquote></div><br></div> --e0cb4efe288ad830cf04d0c653db--
Dec 13 2012
prev sibling next sibling parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Thursday, 13 December 2012 at 23:41:32 UTC, RenatoUtsch wrote:
 Please, lets not release something not thoroughly tested when 
 we are in the middle of the new development process discussion, 
 we are trying to avoid exactly this kind of thing.

The process must be defined before we can use it and UDA has already missed that boat. I'm in agreement with the way Andrei has said it, we need to let this slide.
 Even if the feature is not introducing backwards incompatible 
 changes, this will cause problems when we discover, in the 
 future, that we made some bad decision and won't be able to 
 change it anymore.

Hopefully we are defining the process that we can handle these changes. We'll never have enough testing to not make this mistake. So let us go make this process for Walter to follow and neg him later. (You don't throw people in jail when what they did was criminalized a year later)
Dec 13 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, December 13, 2012 22:19:18 Andrei Alexandrescu wrote:
 On 12/13/12 8:55 PM, kenji hara wrote:
 I think we should have -future/-f switch and  future attribute.
 It is a rough idea, but seems a required compiler feature.
 
 Kenji Hara

That sounds interesting.

I believe that python has something similar.
 Regarding attributes, a simple solution is to release it but without
 official documentation. We place the documentation in a /unstable/
 directory of the website, distinct from the central mainstream
 documentation.
 
 People who already started or want to start using attributes understand
 there are instabilities associated with them. Existing code is
 unaffected, only certain programs that are technically invalid will
 actually compile and run.
 
 Works?

Yes. And attributes may not actually need much more work, but adding new, essentially untested features into the language and releasing them doesn't jive well with the recent push to stabilize and avoid breaking any code, because such features will frequently need changes which will break code. Hopefully, the adjustments to the release process that are being discussed will fix this sort of problem long term, but it comes across like Walter is willing to throw new features in but then generally refuses to change things which break code, which risks us being stuck with features that aren't quite what they could be or should be. The situation with UDAs definitely highlights the need to adjust our release process. And if Remedy really needs special stuff which isn't necessarily ready for primetime, maybe he should create a branch specifically for them rather than doing it all in master. - Jonathan M Davis
Dec 13 2012
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 14 December 2012 at 01:37:22 UTC, Walter Bright wrote:
 On 12/13/2012 4:55 PM, deadalnix wrote:
 You'll go nowhere without a community.

And we need major users, too.

Indeed ! That why I'm all for supporting such user, and I'm pretty most people that are unhappy with the situation will agree. The way it is done is problematic, because the community is kept out. Choice are made that nobody can understand, because nobody have the knowledge necessary to understand.
 It's a balancing act. And I wish to point out, again, that the 
 design was based on extensive discussion threads right here in 
 the ng, and the design was modified based on feedback right 
 here in the ng. So to say the community was uninvolved in this 
 is incorrect, it is very much a community design.

Yes, and that is great. However, discussion can't really replace field testing. And we are a bit short on that one.It seems we don't have much choice right now :/
 And, if you recall, I was initially opposed to UDAs and 
 skeptical they'd be of any actual use :-)

Ho, this is really useful, and I'm really happy that you changed your mind on that.
Dec 13 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Dec 14, 2012 at 04:39:49AM +0100, Jonathan M Davis wrote:
[...]
 And if Remedy really needs special stuff which isn't necessarily ready
 for primetime, maybe he should create a branch specifically for them
 rather than doing it all in master.

Again, this highlights the need for a staging branch instead of just going from master directly to releases. T -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot
Dec 13 2012
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 14 December 2012 at 03:19:18 UTC, Andrei Alexandrescu 
wrote:
 Regarding attributes, a simple solution is to release it but 
 without official documentation. We place the documentation in a 
 /unstable/ directory of the website, distinct from the central 
 mainstream documentation.

 People who already started or want to start using attributes 
 understand there are instabilities associated with them. 
 Existing code is unaffected, only certain programs that are 
 technically invalid will actually compile and run.

 Works?

Can we have a feedback from this game dev company on how hard it is to migrate from one syntax to another ?
Dec 13 2012
prev sibling next sibling parent "Rob T" <rob ucora.com> writes:
On Friday, 14 December 2012 at 07:58:25 UTC, deadalnix wrote:
 Can we have a feedback from this game dev company on how hard 
 it is to migrate from one syntax to another ?

Actually this is the best approach IMO, but maybe Walter thinks it's not worth bringing up at this point because it may give an indication of instability even though we're trying to achieve the exact opposite effect and prevent instability from happening. --rt
Dec 14 2012
prev sibling next sibling parent reply "F i L" <witte2008 gmail.com> writes:
Sorry if I missed this, but with User Defined Attributes be part 
of 2.61? Or is that still not ready?
Dec 14 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/14/2012 6:26 PM, F i L wrote:
 Sorry if I missed this, but with User Defined Attributes be part of 2.61?

Yes.
Dec 14 2012
prev sibling next sibling parent "F i L" <witte2008 gmail.com> writes:
On Saturday, 15 December 2012 at 06:17:13 UTC, Walter Bright 
wrote:
 On 12/14/2012 6:26 PM, F i L wrote:
 Sorry if I missed this, but with User Defined Attributes be 
 part of 2.61?

Yes.

Awesome! Can't wait :)
Dec 15 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Friday, 14 December 2012 at 01:26:35 UTC, Walter Bright wrote:
 On 12/13/2012 5:10 PM, H. S. Teoh wrote:
 Remedy adopting D

Saying that would be premature and incorrect at the moment. We still have to ensure that Remedy wins with D. This is an ongoing thing.

Yes, but what H.S. Theoh wrote about the desperate need of process is still true and correct. Like many others here, I think it's the biggest problem with D right now for its adoption. I for one will never consider using D for my main line of work without a true STABLE branch: a branch you can rely on. And yet I'm pretty sold to the language, but when your project is at stake, what you need is security. And the current development scheme doesn't provide that.
Dec 15 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Friday, 14 December 2012 at 00:42:58 UTC, Walter Bright wrote:
 On 12/13/2012 4:17 PM, David Nadlinger wrote:

 Like any major user of a language, they want confidence in our 
 full support of them. Asking them to use a patched or branch 
 version of the compiler does not inspire confidence.

Maybe, but not having a full development process is NOT how you inspire confidence, quite the contrary. And in all fairness, they are a bit crazy to rely on features that are still considered experimental by the community. You should probably tell them to rely on proven features instead. That is by far the best way for them to succeed.
Dec 15 2012
prev sibling next sibling parent "RenatoUtsch" <renatoutsch gmail.com> writes:
On Saturday, 15 December 2012 at 16:16:11 UTC, SomeDude wrote:
 On Friday, 14 December 2012 at 01:26:35 UTC, Walter Bright 
 wrote:
 On 12/13/2012 5:10 PM, H. S. Teoh wrote:
 Remedy adopting D

Saying that would be premature and incorrect at the moment. We still have to ensure that Remedy wins with D. This is an ongoing thing.

Yes, but what H.S. Theoh wrote about the desperate need of process is still true and correct. Like many others here, I think it's the biggest problem with D right now for its adoption. I for one will never consider using D for my main line of work without a true STABLE branch: a branch you can rely on. And yet I'm pretty sold to the language, but when your project is at stake, what you need is security. And the current development scheme doesn't provide that.

Yeah, but if people doesn't help to define a new process, no process will ever be defined. We are trying to do something like that, any support or ideas will be helpful. The community needs to help to define this, and Walter already said that he will agree on what the community defines. See: http://wiki.dlang.org/Release_Process http://forum.dlang.org/thread/ka5rv5$2k60$1 digitalmars.com
Dec 15 2012
prev sibling next sibling parent "Leandro Lucarella" <leandro.lucarella sociomantic.com> writes:
On Friday, 14 December 2012 at 00:42:58 UTC, Walter Bright wrote:
 On 12/13/2012 4:17 PM, David Nadlinger wrote:
 1. How much work would it be for the guys at Remedy Games to 
 convert their
 codebase from [] to  ()?

I don't know. All I know is it's a lot of code.

You should ask. It's really crazy to ask the WHOLE community to take the bullet for some company using an experimental unreleased version of the compiler without even knowing if there is a good reason why they can't just fix their code. And in any case, this is theirs problem, they should be using a special version of the compiler (the one that accepts broken code), not all the rest! This is just completely crazy...
 3. Why is the message you introduced a warning instead of a 
 normal deprecation
 error?

Because skipping the warning phase has historically been too abrupt for people.

Oh, lord. And then you can't see why deprecation as warnings should have existed in the first place and why it shouldn't be the default...
 versions, can't they just use a patched version until they 
 have made the switch?

Like any major user of a language, they want confidence in our full support of them. Asking them to use a patched or branch version of the compiler does not inspire confidence.

Yeah, introducing broken unconsulted features to the language and then wanting to keep backwards compatibility for them does inspire a lot of confidence. Seriously Walter, you're doing it all backwards...
 What I'm doing is hardly unique in business history. When 
 Boeing designed the 707, they showed the prototype to Pan Am,

And no, your nice stories about Boing doesn't help here, get over it, you're dealing with an opensource project now, not with an internal project of an aeronaval industry.
 Ok, we're not Boeing or Westinghouse. But we have an 
 opportunity to go big time, and I'm not going to let that get 
 away from us.

This is extremely lame unless you present a good case for Remedy Games. Just saying "they have a lot of code" isn't good enough.
Dec 22 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--047d7b2ed6b968322804d17970f7
Content-Type: text/plain; charset=ISO-8859-1

On 22 December 2012 19:32, Leandro Lucarella <
leandro.lucarella sociomantic.com> wrote:

 On Friday, 14 December 2012 at 00:42:58 UTC, Walter Bright wrote:

 On 12/13/2012 4:17 PM, David Nadlinger wrote:

 1. How much work would it be for the guys at Remedy Games to convert
 their
 codebase from [] to  ()?

I don't know. All I know is it's a lot of code.

You should ask. It's really crazy to ask the WHOLE community to take the bullet for some company using an experimental unreleased version of the compiler without even knowing if there is a good reason why they can't just fix their code. And in any case, this is theirs problem, they should be using a special version of the compiler (the one that accepts broken code), not all the rest! This is just completely crazy...

This. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --047d7b2ed6b968322804d17970f7 Content-Type: text/html; charset=ISO-8859-1 <div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 22 December 2012 19:32, Leandro Lucarella <span dir="ltr">&lt;<a href="mailto:leandro.lucarella sociomantic.com" target="_blank">leandro.lucarella sociomantic.com</a>&gt;</span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Friday, 14 December 2012 at 00:42:58 UTC, Walter Bright wrote:<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"> On 12/13/2012 4:17 PM, David Nadlinger wrote:<br> </div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 1. How much work would it be for the guys at Remedy Games to convert their<br> codebase from [] to ()?<br> </blockquote> <br></div><div class="im"> I don&#39;t know. All I know is it&#39;s a lot of code.<br> </div></blockquote> <br> You should ask. It&#39;s really crazy to ask the WHOLE community to take the bullet for some company using an experimental unreleased version of the compiler without even knowing if there is a good reason why they can&#39;t just fix their code.<br> <br> And in any case, this is theirs problem, they should be using a special version of the compiler (the one that accepts broken code), not all the rest!<br> <br> This is just completely crazy...<div class="im"></div></blockquote></div><br><br></div><div class="gmail_extra">This.<br></div><div class="gmail_extra"><br clear="all"><br>-- <br>Iain Buclaw<br><br>*(p &lt; e ? p++ : p) = (c &amp; 0x0f) + &#39;0&#39;; </div></div> --047d7b2ed6b968322804d17970f7--
Dec 22 2012
prev sibling next sibling parent "ixid" <nuaccount gmail.com> writes:
On Saturday, 22 December 2012 at 23:37:03 UTC, Iain Buclaw wrote:
 On 22 December 2012 19:32, Leandro Lucarella <
 leandro.lucarella sociomantic.com> wrote:

 On Friday, 14 December 2012 at 00:42:58 UTC, Walter Bright 
 wrote:

 On 12/13/2012 4:17 PM, David Nadlinger wrote:

 1. How much work would it be for the guys at Remedy Games to 
 convert
 their
 codebase from [] to  ()?

I don't know. All I know is it's a lot of code.

You should ask. It's really crazy to ask the WHOLE community to take the bullet for some company using an experimental unreleased version of the compiler without even knowing if there is a good reason why they can't just fix their code. And in any case, this is theirs problem, they should be using a special version of the compiler (the one that accepts broken code), not all the rest! This is just completely crazy...

This.

Surely someone like Walter or yourself (I am not suggesting that it's your responsibility) could have written a reliable find and replace for the other attribute syntax, fixed Remedy's codebase and allowed everyone to move on?
Dec 22 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--14dae9d253b45f766e04d17a2b00
Content-Type: text/plain; charset=ISO-8859-1

On 23 December 2012 00:11, ixid <nuaccount gmail.com> wrote:

 On Saturday, 22 December 2012 at 23:37:03 UTC, Iain Buclaw wrote:

 On 22 December 2012 19:32, Leandro Lucarella <
 leandro.lucarella sociomantic.**com <leandro.lucarella sociomantic.com>>
 wrote:

  On Friday, 14 December 2012 at 00:42:58 UTC, Walter Bright wrote:
  On 12/13/2012 4:17 PM, David Nadlinger wrote:
  1. How much work would it be for the guys at Remedy Games to convert
 their
 codebase from [] to  ()?


bullet for some company using an experimental unreleased version of the compiler without even knowing if there is a good reason why they can't just fix their code. And in any case, this is theirs problem, they should be using a special version of the compiler (the one that accepts broken code), not all the rest! This is just completely crazy...

This.

Surely someone like Walter or yourself (I am not suggesting that it's your responsibility) could have written a reliable find and replace for the other attribute syntax, fixed Remedy's codebase and allowed everyone to move on?

Yes, but using sed to find and replace code is fraught with dangers and should be avoided with a large stick. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --14dae9d253b45f766e04d17a2b00 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2= 3 December 2012 00:11, ixid <span dir=3D"ltr">&lt;<a href=3D"mailto:nuaccou= nt gmail.com" target=3D"_blank">nuaccount gmail.com</a>&gt;</span> wrote:<b= r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:= 1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Saturday, 22 December 2012 at 23:37:03 UTC, Iain Bucla= w wrote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> On 22 December 2012 19:32, Leandro Lucarella &lt;<br> <a href=3D"mailto:leandro.lucarella sociomantic.com" target=3D"_blank">lean= dro.lucarella sociomantic.<u></u>com</a>&gt; wrote:<br> <br> </div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Friday, 14 December 2012 at 00:42:58 UTC, Walter Bright wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 12/13/2012 4:17 PM, David Nadlinger wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> 1. How much work would it be for the guys at Remedy Games to convert<br> their<br> codebase from [] to ()?<br> <br> </blockquote> <br> I don&#39;t know. All I know is it&#39;s a lot of code.<br> <br> </blockquote> <br> You should ask. It&#39;s really crazy to ask the WHOLE community to take th= e<br> bullet for some company using an experimental unreleased version of the<br> compiler without even knowing if there is a good reason why they can&#39;t = just<br> fix their code.<br> <br> And in any case, this is theirs problem, they should be using a special<br> version of the compiler (the one that accepts broken code), not all the<br> rest!<br> <br> This is just completely crazy...<br> <br> </blockquote> <br> <br></div> This.<br> </blockquote> <br> Surely someone like Walter or yourself (I am not suggesting that it&#39;s y= our responsibility) could have written a reliable find and replace for the = other attribute syntax, fixed Remedy&#39;s codebase and allowed everyone to= move on?<br> </blockquote></div><br><br></div><div class=3D"gmail_extra">Yes, but using = sed to find and replace code is fraught with dangers and should be avoided = with a large stick.<br clear=3D"all"></div><div class=3D"gmail_extra"><br>-= - <br> Iain Buclaw<br><br>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;; </div></div> --14dae9d253b45f766e04d17a2b00--
Dec 22 2012
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, 2012-12-22 at 20:32 +0100, Leandro Lucarella wrote:
 On Friday, 14 December 2012 at 00:42:58 UTC, Walter Bright wrote:
 On 12/13/2012 4:17 PM, David Nadlinger wrote:
 1. How much work would it be for the guys at Remedy Games to=20
 convert their
 codebase from [] to  ()?

I don't know. All I know is it's a lot of code.

You should ask. It's really crazy to ask the WHOLE community to=20 take the bullet for some company using an experimental unreleased=20 version of the compiler without even knowing if there is a good=20 reason why they can't just fix their code. =20 And in any case, this is theirs problem, they should be using a=20 special version of the compiler (the one that accepts broken=20 code), not all the rest! =20 This is just completely crazy...

Is it really being suggested that the undefined needs of a single organization that neither owns the language and code, nor pays the salaries of the committers, determine the evolution of a FOSS languages? --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Dec 23 2012
prev sibling parent "Leandro Lucarella" <leandro.lucarella sociomantic.com> writes:
On Friday, 14 December 2012 at 03:40:05 UTC, Jonathan M Davis 
wrote:
 On Thursday, December 13, 2012 22:19:18 Andrei Alexandrescu 
 wrote:
 On 12/13/12 8:55 PM, kenji hara wrote:
 I think we should have -future/-f switch and  future 
 attribute.
 It is a rough idea, but seems a required compiler feature.
 
 Kenji Hara

That sounds interesting.

I believe that python has something similar.

It does, but in Python they are only for breaking changes (for example when a new keyword is added, first you have to use form __future__import feature). Is kind of the reverse of deprecated. Also __future__ in Python is not really for experimental features, is for final ones, and present only to easy the migration (again, same as deprecated). If the idea is to enable experimental features, I would name this -experimental rather than -future, which makes much clearer that you're on your own if you use that flag.
 Regarding attributes, a simple solution is to release it but 
 without
 official documentation. We place the documentation in a 
 /unstable/
 directory of the website, distinct from the central mainstream
 documentation.
 
 People who already started or want to start using attributes 
 understand
 there are instabilities associated with them. Existing code is
 unaffected, only certain programs that are technically invalid 
 will
 actually compile and run.
 
 Works?


Only if you don't set this new experimental features in stone if some company have the crazy idea of start using it ;-)
 Yes. And attributes may not actually need much more work, but 
 adding new,
 essentially untested features into the language and releasing 
 them doesn't
 jive well with the recent push to stabilize and avoid breaking 
 any code,
 because such features will frequently need changes which will 
 break code.
 Hopefully, the adjustments to the release process that are 
 being discussed
 will fix this sort of problem long term, but it comes across 
 like Walter is
 willing to throw new features in but then generally refuses to 
 change things
 which break code, which risks us being stuck with features that 
 aren't quite
 what they could be or should be. The situation with UDAs 
 definitely highlights
 the need to adjust our release process.

Yes, to be honest, I don't think adding experimental features to what is supposed to be a stable compiler is a great idea. I think the best option is to add an experimental branch and add new features there. Having a nightly snapshot build of this experimental branch should be enough to encourage people to play with it making extremely clear that there are no warranties about the stability of that compiler, or on the continuation of new features there.
Dec 24 2012