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

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

Sorry if I missed this, but with User Defined Attributes be part of 2.61? Or is that still not ready?

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.

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

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.

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.

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

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.

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