May 30, 2013
On Thursday, May 30, 2013 20:39:47 Mafi wrote:
> On Thursday, 30 May 2013 at 18:09:22 UTC, Jonathan M Davis wrote:
> > On Thursday, May 30, 2013 20:00:24 Mafi wrote:
> >> What a great release! Great work!
> >> 
> >> I really like the new langugage changes. One change caught my attention: #10 "The Template This Parameter now changes the member function qualifier". Does this mean that const/immutable ranges can implement a useful opSlice? Like
> >> 
> >> struct MyRange!T {
> >> T[] data;
> >> 
> >> MyRange!(ElementType!data) opSlice(this T)() {
> >> return MyRange(data);
> >> }
> >> }
> >> 
> >> So that given the other range primitves this will work:
> >> 
> >> const myConstRange = MyRange([5, 6, 7, 8]);
> >> foreach(x; myConstRange) {}
> >> 
> >> Could this be made work with 2.063?
> > 
> > No, because you still have the fundamental problem that
> > MyRange!T and MyRange!
> > (const T) are different types which potentially have no
> > relation to one another
> > aside from the fact that they were generated by the same
> > template. In the
> > general case, you can't just convert MyRange!T to
> > MyRange!(const T). It only
> > works with arrays because the compiler understands them.
> > 
> > - Jonathan M Davis
> 
> Well I'm aware of the fact that MyRange!T and MyRange!const(T)
> could be unrelated types. But they're not and the author the
> range provided a conversion function and called it opSlice().
> Foreach shouldn't care if they're related or not, it should just
> call opSlice().

You still need a way to convert MyRange!T to MyRange!(const T). opSlice won't
do that magically for you. It'll just have to do that internally. And to be
truly useful, you need to be able to go from const(MyRange!T) to
MyRange!(const T). You need tail-const:

http://d.puremagic.com/issues/show_bug.cgi?id=5377

I don't see how this enhancement could possibly have any effect on any of that. At best, it eliminates some code duplication.

- Jonathan M Davis
May 30, 2013
Awesome job to all contributors, it's looking much better, and yes the change log with examples is a very noticeable part of the improvement.

I noted some comments about the server being under too much load. Any thought put into adding an official torrent for downloads? That may help ease up on the server load for next release announcement.

--rt
May 30, 2013
W dniu 30.05.2013 19:16, Simen Kjaeraas pisze:
> On 2013-05-30, 17:16, Andrei Alexandrescu wrote:
>
>> For the full story, mosey to the redesigned changelog:
>>
>> http://dlang.org/changelog.html
>
> Kudos to Andrej for this. *This* is how a great changelog looks.

This is a very pleasant surprise to see such detailed changelog!
May 30, 2013
On 5/30/13, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> Hello,

We seem to have a regression affecting the zipped release: http://d.puremagic.com/issues/show_bug.cgi?id=10215

But I can't recreate this in git-head. It must have been a specific commit the release is based on that introduced this behavior. I don't know how it went through the autotester unnoticed, this is a pretty major bug.
May 30, 2013
On Thursday, 30 May 2013 at 22:04:07 UTC, Andrej Mitrovic wrote:
> On 5/30/13, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>> Hello,
>
> We seem to have a regression affecting the zipped release:
> http://d.puremagic.com/issues/show_bug.cgi?id=10215
>
> But I can't recreate this in git-head. It must have been a specific
> commit the release is based on that introduced this behavior. I don't
> know how it went through the autotester unnoticed, this is a pretty
> major bug.

Prior to issuing a release like this, it should instead be made public as a "stable release candidate" with full installer on the downloads page for review by anyone. After the bugs are worked out and some time has elapsed, the stable RC is simply declared "stable final" and re-released as such with the usual big announcement.

--rt
May 31, 2013
On Thursday, 30 May 2013 at 22:04:07 UTC, Andrej Mitrovic wrote:
> On 5/30/13, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>> Hello,
>
> We seem to have a regression affecting the zipped release:
> http://d.puremagic.com/issues/show_bug.cgi?id=10215
>
> But I can't recreate this in git-head. It must have been a specific
> commit the release is based on that introduced this behavior. I don't
> know how it went through the autotester unnoticed, this is a pretty
> major bug.

Perfect chance to try out the new release process. Patch 2.063 and release 2.063.1.
May 31, 2013
On Fri, 31 May 2013 00:41:08 +0200
"Rob T" <alanb@ucora.com> wrote:

> On Thursday, 30 May 2013 at 22:04:07 UTC, Andrej Mitrovic wrote:
> > On 5/30/13, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> >> Hello,
> >
> > We seem to have a regression affecting the zipped release: http://d.puremagic.com/issues/show_bug.cgi?id=10215
> >
> > But I can't recreate this in git-head. It must have been a
> > specific
> > commit the release is based on that introduced this behavior. I
> > don't
> > know how it went through the autotester unnoticed, this is a
> > pretty
> > major bug.
> 
> Prior to issuing a release like this, it should instead be made public as a "stable release candidate" with full installer on the downloads page for review by anyone. After the bugs are worked out and some time has elapsed, the stable RC is simply declared "stable final" and re-released as such with the usual big announcement.
> 

That's more-or-less what already happens, the only difference is that (to my knowledge) there's no link to it on the downloads page.

Although, we probably could use more time between "all known regressions in beta fixed" and the actual release. Usually it's just the next day.

May 31, 2013
On Friday, 31 May 2013 at 01:36:15 UTC, Nick Sabalausky wrote:
>> 
>
> That's more-or-less what already happens, the only difference is that
> (to my knowledge) there's no link to it on the downloads page.
>
> Although, we probably could use more time between "all known regressions
> in beta fixed" and the actual release. Usually it's just the next day.

Yes, but because there's no link on the main page and no installer, the RC's are effectively closed to the public because only people in the know will go through the trouble to get the RC's and install them.

I'm only talking about when the next release gets very to release should something like this be done. It'll make installing a new release far less risky business when it goes final. It'll improve confidence in the final product and further reduce or completely eliminate nasty surprises.

IMO doing this will have a similar positive effect like as we've seen with the improved release log.

--rt
May 31, 2013
On Fri, 31 May 2013 03:50:51 +0200
"Rob T" <alanb@ucora.com> wrote:
> Yes, but because there's no link on the main page and no installer, the RC's are effectively closed to the public because only people in the know will go through the trouble to get the RC's and install them.
> 
> I'm only talking about when the next release gets very to release should something like this be done. It'll make installing a new release far less risky business when it goes final. It'll improve confidence in the final product and further reduce or completely eliminate nasty surprises.
> 
> IMO doing this will have a similar positive effect like as we've seen with the improved release log.
> 
> --rt

Yea, greater visibility for the betas could probably still help.

Walter has started announcing them here on D.announce, which is good, but you're right, links on the main page and installers might also help.

May 31, 2013
On Thursday, 30 May 2013 at 22:41:08 UTC, Rob T wrote:=
> Prior to issuing a release like this, it should instead be made public as a "stable release candidate" with full installer on the downloads page for review by anyone. After the bugs are worked out and some time has elapsed, the stable RC is simply declared "stable final" and re-released as such with the usual big announcement.
>
> --rt

I disagree. Anything made public is treated as a release. It does not matter how to you call it. And new release scheme with minor version numbers has been adopted recently, so there are no issues in fixing those regression and updating release with v2.063.2 tag now - essentially will do the same stuff.