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 reply =?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
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 "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.


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 

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 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 reply 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
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
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 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 reply "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
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 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
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 "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
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 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
next sibling 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 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 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 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=




g

 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=


hy  =


 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=


en  =


 a fatal regression was introduced and templates became unusable becaus=


e  =


 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 =


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" an=


d  =


 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=


nd  =


 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 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 "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
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 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 "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
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 reply "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 

example).
Dec 10 2012
parent reply 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



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
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

 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 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 "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
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 "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 reply "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
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 "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
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 reply 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
parent reply "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
parent reply "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
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 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 "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 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 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 reply 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
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 reply "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
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 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 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 reply 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
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 parent reply 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
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
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 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 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
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 "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 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
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=




p

 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=


his

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


ve

 been released then.


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


ate

 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=


m.

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

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


d,

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


2e7cad8b16fabc6a825a


I am confused at this commit also.

--=20
Iain Buclaw

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



 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 "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



  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  "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 reply "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



 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



  parent reply 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



 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  parent reply "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



  parent reply 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



  parent reply "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



  parent reply "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



  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  "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  parent reply "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



 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  "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 reply "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



  parent reply 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



  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 reply kenji hara <k.hara.pg gmail.com>  writes:


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.





 Dec 13 2012



  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 reply kenji hara <k.hara.pg gmail.com>  writes:


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.





 Dec 13 2012



  parent reply 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



 next sibling parent reply "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



  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



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  parent reply "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



  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  "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  parent reply "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



 next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com>  writes:


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';



 Dec 22 2012



  parent reply "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



  parent reply Iain Buclaw <ibuclaw ubuntu.com>  writes:


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  ()?


 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?



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';



 Dec 22 2012



  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  parent  Russel Winder <russel winder.org.uk>  writes:


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.


=20
 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 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  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  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 reply "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



  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  parent reply "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



  parent reply "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



 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  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  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 reply 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



  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