View mode: basic / threaded / horizontal-split · Log in · Help
December 14, 2012
Re: Moving towards D2 2.061 (and D1 1.076)
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
December 15, 2012
Re: Moving towards D2 2.061 (and D1 1.076)
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';
December 15, 2012
Re: Moving towards D2 2.061 (and D1 1.076)
Sorry if I missed this, but with User Defined Attributes be part 
of 2.61? Or is that still not ready?
December 15, 2012
Re: Moving towards D2 2.061 (and D1 1.076)
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.
December 15, 2012
Re: Moving towards D2 2.061 (and D1 1.076)
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 :)
December 15, 2012
Re: Moving towards D2 2.061 (and D1 1.076)
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.
December 15, 2012
Re: Moving towards D2 2.061 (and D1 1.076)
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.
December 15, 2012
Re: Moving towards D2 2.061 (and D1 1.076)
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
December 15, 2012
Re: Moving towards D2 2.061 (and D1 1.076)
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.
December 15, 2012
Re: Moving towards D2 2.061 (and D1 1.076)
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
9 10 11 12 13 14
Top | Discussion index | About this forum | D home