digitalmars.D - Time for 2.067

Walter Bright (2/2) Jan 30 2015 Time to button this up and release it. Remaining regressions:

Rikki Cattermole (3/5) Jan 30 2015 Can I please have another review of my PR?
AndyC (5/7) Jan 30 2015 How about this one: https://issues.dlang.org/show_bug.cgi?id=7762

Walter Bright (3/10) Jan 30 2015 It's resolves as "worksforme". If someone reports that it is still causi...
zeljkog (13/24) Jan 31 2015 It is related to new rules with -property flag.

H. S. Teoh via Digitalmars-d (14/17) Jan 30 2015 Have we reached a final decision about what exactly groupBy should

Andrei Alexandrescu (9/21) Jan 30 2015 Sorry, I thought that was in the bag. Keep current semantics, call it

Andrei Alexandrescu (2/3) Jan 30 2015 s/binary/unary/
"Ulrich =?UTF-8?B?S8O8dHRsZXIi?= <kuettler gmail.com> (20/23) Feb 02 2015 I might miss some information on this, so please forgive my naive

Andrei Alexandrescu (12/31) Feb 04 2015 Probably we need to change that because aggregate should integrate

"Ulrich =?UTF-8?B?S8O8dHRsZXIi?= <kuettler gmail.com> (47/91) Feb 05 2015 I understand and agree. My suggestion aims to avoid this

Vladimir Panteleev (15/17) Jan 30 2015 The recent website overhaul broke a few documentation-related

Martin Nowak (4/7) Feb 15 2015 https://github.com/D-Programming-Language/installer/blob/4d57e861a2b1576...

Martin Nowak (3/5) Jan 30 2015 Please let's finish the GC work for 2.067, will take about 1-1.5

Andrei Alexandrescu (3/9) Jan 30 2015 Can we commit to having stuff done by Feb 15 for a release on Mar 1? --

Martin Nowak (2/4) Jan 31 2015 Sounds good, work on regressions should start soon and we should

Dicebot (2/4) Feb 01 2015 You are not going to do a release branch?
Puneet Goel (8/12) Feb 04 2015 Martin

Walter Bright <newshound2 digitalmars.com> writes:

Time to button this up and release it. Remaining regressions:

https://issues.dlang.org/buglist.cgi?bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&list_id=192294&query_format=advanced

Jan 30 2015

Rikki Cattermole <alphaglosined gmail.com> writes:

On 31/01/2015 11:05 a.m., Walter Bright wrote:
 Time to button this up and release it. Remaining regressions:

 https://issues.dlang.org/buglist.cgi?bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&list_id=192294&query_format=advanced

Can I please have another review of my PR?

https://github.com/D-Programming-Language/dmd/pull/3921

Jan 30 2015

"AndyC" <andy squeakycode.net> writes:

On Friday, 30 January 2015 at 22:06:34 UTC, Walter Bright wrote:
 Time to button this up and release it. Remaining regressions:

 https://issues.dlang.org/buglist.cgi?bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&list_id=192294&query_format=advanced

How about this one: https://issues.dlang.org/show_bug.cgi?id=7762

Not sure if its supposed to compile, but it was reported master 
wouldn't.

-Andy

Jan 30 2015

Walter Bright <newshound2 digitalmars.com> writes:

On 1/30/2015 2:24 PM, AndyC wrote:
 On Friday, 30 January 2015 at 22:06:34 UTC, Walter Bright wrote:
 Time to button this up and release it. Remaining regressions:

 https://issues.dlang.org/buglist.cgi?bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&list_id=192294&query_format=advanced

 How about this one: https://issues.dlang.org/show_bug.cgi?id=7762

 Not sure if its supposed to compile, but it was reported master wouldn't.

It's resolves as "worksforme". If someone reports that it is still causing 
problems, it should be reopened.

Jan 30 2015

zeljkog <zeljkog home.com> writes:

On 30.01.15 23:24, AndyC wrote:
 On Friday, 30 January 2015 at 22:06:34 UTC, Walter Bright wrote:
 Time to button this up and release it. Remaining regressions:

 https://issues.dlang.org/buglist.cgi?bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&list_id=192294&q
ery_format=advanced 

 
 How about this one: https://issues.dlang.org/show_bug.cgi?id=7762
 
 Not sure if its supposed to compile, but it was reported master wouldn't.
 
 -Andy

It is related to new rules with -property flag.

import std.stdio;

int f(int a){
    return a + 10;
}

void main() {
    auto x = 20;
    writeln(x.f);
}

This compiles with 2.66.1, but with master:
Error: not a property x.f

There are such things in Phobos (std\functional and ?).

Jan 31 2015

"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:

On Fri, Jan 30, 2015 at 02:05:52PM -0800, Walter Bright via Digitalmars-d wrote:
 Time to button this up and release it. Remaining regressions:
 
 https://issues.dlang.org/buglist.cgi?bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&list_id=192294&query_format=advanced

Have we reached a final decision about what exactly groupBy should
return? (Or whether it should even be called 'groupBy'?) Last I heard,
there wasn't a firm decision. We should not release with an undecided-on
API, because that will make it much harder to change later (we will need
to go through a full deprecation cycle, and possibly waste the name
'groupBy'). If we can't decide before release, we might have to revert
groupBy for the time being.

There's also the [$] issue: are we keeping it or dumping it?

There may be one or two other issues that we need to iron out before
release, but they just slipped my mind now.


T

-- 
Shin: (n.) A device for finding furniture in the dark.

Jan 30 2015

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 1/30/15 2:35 PM, H. S. Teoh via Digitalmars-d wrote:
 On Fri, Jan 30, 2015 at 02:05:52PM -0800, Walter Bright via Digitalmars-d
wrote:
 Time to button this up and release it. Remaining regressions:

 https://issues.dlang.org/buglist.cgi?bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&list_id=192294&query_format=advanced

 Have we reached a final decision about what exactly groupBy should
 return? (Or whether it should even be called 'groupBy'?) Last I heard,
 there wasn't a firm decision. We should not release with an undecided-on
 API, because that will make it much harder to change later (we will need
 to go through a full deprecation cycle, and possibly waste the name
 'groupBy'). If we can't decide before release, we might have to revert
 groupBy for the time being.

Sorry, I thought that was in the bag. Keep current semantics, call it 
chunkBy. Add the key to each group when the predicate is binary. Make 
sure aggregate() works nice with chunkBy().

Stuff that can wait: grouping and aggregation for SortedRange.

 There's also the [$] issue: are we keeping it or dumping it?

I think we can at least delay it until (a) the partial deduction is 
clearly defined, and (b) we figure whether a library solution is enough. 
I need more signal from our brass please.


Andrei

Jan 30 2015

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 1/30/15 3:17 PM, Andrei Alexandrescu wrote:
 Add the key to each group when the predicate is binary.

s/binary/unary/

Jan 30 2015

"Ulrich =?UTF-8?B?S8O8dHRsZXIi?= <kuettler gmail.com> writes:

On Friday, 30 January 2015 at 23:17:09 UTC, Andrei Alexandrescu 
wrote:
 Sorry, I thought that was in the bag. Keep current semantics, 
 call it chunkBy. Add the key to each group when the predicate 
 is unary. Make sure aggregate() works nice with chunkBy().

I might miss some information on this, so please forgive my naive 
question. Your requirements seem to be contradictory to me.

1. aggregate expects a range of ranges
2. you ask chunkBy to return something that is not a range of 
ranges
3. you ask chunkBy to play along nicely with aggregate

There are certainly ways to make this work. Adding a special 
version of aggregate comes to mind. However, I fail to see the 
rational behind this.

To me the beauty of range is the composibility of "simple" 
constructs to create complex behavior. The current chunkBy does 
not need to be changed to "add the key to each group when the 
predicate is unary":

  r.map!(pred, "a")
   .chunkBy!("a[0]")
   .map!(inner => tuple(inner.front[0], inner.map!"a[1]"));

So I'd like to know why the above is inferior to a rework of the 
chunkBy's implementation. Maybe this is a question for D.learn.

Feb 02 2015

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 2/2/15 2:42 PM, "Ulrich =?UTF-8?B?S8O8dHRsZXIi?= 
<kuettler gmail.com>" wrote:
 On Friday, 30 January 2015 at 23:17:09 UTC, Andrei Alexandrescu wrote:
 Sorry, I thought that was in the bag. Keep current semantics, call it
 chunkBy. Add the key to each group when the predicate is unary. Make
 sure aggregate() works nice with chunkBy().

 I might miss some information on this, so please forgive my naive
 question. Your requirements seem to be contradictory to me.

 1. aggregate expects a range of ranges

Probably we need to change that because aggregate should integrate 
seamlessly with chunkBy.

 2. you ask chunkBy to return something that is not a range of ranges

Yah.

 3. you ask chunkBy to play along nicely with aggregate

Yah.

 There are certainly ways to make this work. Adding a special version of
 aggregate comes to mind. However, I fail to see the rational behind this.

Rationale as discussed is that the key value for each group is useful 
information. Returning a range of ranges would waste that information 
forcing e.g. its recomputation.

 To me the beauty of range is the composibility of "simple" constructs to
 create complex behavior. The current chunkBy does not need to be changed
 to "add the key to each group when the predicate is unary":

   r.map!(pred, "a")
    .chunkBy!("a[0]")
    .map!(inner => tuple(inner.front[0], inner.map!"a[1]"));

 So I'd like to know why the above is inferior to a rework of the
 chunkBy's implementation. Maybe this is a question for D.learn.

Wouldn't that force recomputation if a more complex expression replaced 
a[0]?


Andrei

Feb 04 2015

"Ulrich =?UTF-8?B?S8O8dHRsZXIi?= <kuettler gmail.com> writes:

On Thursday, 5 February 2015 at 03:00:53 UTC, Andrei Alexandrescu 
wrote:
 On 2/2/15 2:42 PM, "Ulrich =?UTF-8?B?S8O8dHRsZXIi?= 
 <kuettler gmail.com>" wrote:
 On Friday, 30 January 2015 at 23:17:09 UTC, Andrei 
 Alexandrescu wrote:
 Sorry, I thought that was in the bag. Keep current semantics, 
 call it
 chunkBy. Add the key to each group when the predicate is 
 unary. Make
 sure aggregate() works nice with chunkBy().

 I might miss some information on this, so please forgive my 
 naive
 question. Your requirements seem to be contradictory to me.

 1. aggregate expects a range of ranges

 Probably we need to change that because aggregate should 
 integrate seamlessly with chunkBy.

 2. you ask chunkBy to return something that is not a range of 
 ranges

 Yah.

 3. you ask chunkBy to play along nicely with aggregate

 Yah.

 There are certainly ways to make this work. Adding a special 
 version of
 aggregate comes to mind. However, I fail to see the rational 
 behind this.

 Rationale as discussed is that the key value for each group is 
 useful information. Returning a range of ranges would waste 
 that information forcing e.g. its recomputation.

I understand and agree. My suggestion aims to avoid this 
particular waste. See below.

 To me the beauty of range is the composibility of "simple" 
 constructs to
 create complex behavior. The current chunkBy does not need to 
 be changed
 to "add the key to each group when the predicate is unary":

  r.map!(pred, "a")
   .chunkBy!("a[0]")
   .map!(inner => tuple(inner.front[0], inner.map!"a[1]"));

 So I'd like to know why the above is inferior to a rework of 
 the
 chunkBy's implementation. Maybe this is a question for D.learn.

 Wouldn't that force recomputation if a more complex expression 
 replaced a[0]?

I do not think you ever want to replace a[0] here. In the code 
above the (original) predicate to chunkBy is pred. The idea is to 
evaluate the predicate outside of chunkBy. Create a range of 
tuples from the original range, chunk the range of tuples and 
construct the desired result from the chunked range of tuples.

// create a range of `tuple(pred(a), a)`
r.map!(pred, "a")

// chunk the range of tuples based of the first tuple element
// this results in a range of ranges of tuples
    .chunkBy!("a[0]")

// convert the inner ranges of tuples to a tuple of the predicate 
applied and the appropriate range
    .map!(inner => tuple(inner.front[0], inner.map!"a[1]"));

The construction of a range of tuples is not for free. On the 
bright side:

* you only do it when you need it
* if your predicate is that heavy, you might want to precompute 
it anyway
* a modified chunkBy is not exactly free either (and you pay the 
price even if you do not need the key value)

Now I learned that map is very lazy and applies the function 
inside front(). Thus, the above might actually result in multiple 
evaluations of the predicate. Luckily, there is the new cache 
function:

auto chunkByStar(alias pred, Range)(Range r)
{
return r.map!(pred, "a")
    .cache
    .chunkBy!("a[0]")
    .map!(inner => tuple(inner.front[0], inner.map!"a[1]"));
}

My point here is, we can construct a version of chunkBy that does 
not waste the key value with modest means. With great power comes 
great flexibility. I wanted to sneak this in as an example, 
because it is not clear what eventual users might actually need.

On the other hand there is no limit to the special cases we could 
add. aggregate might not be the only function to work with 
chunkBy. And even an aggregate function that takes a tuple of a 
range and something else and only uses the range seems wrong to 
me, given expressive the power D has. The transformation of the 
range is just on map away:

chunkByStar!(...)(r).map!"a[1]".aggregate!max

Then again, I might be missing something huge here.

Feb 05 2015

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

On Friday, 30 January 2015 at 22:06:34 UTC, Walter Bright wrote:
 Time to button this up and release it. Remaining regressions:

 https://issues.dlang.org/buglist.cgi?bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&list_id=192294&query_format=advanced

The recent website overhaul broke a few documentation-related 
things.

CHM generation is currently broken. Fix:
https://github.com/D-Programming-Language/dlang.org/pull/873

I don't know how the .html files that are included in dmd.zip are 
generated. Please try and see if it works for you. If not, I can 
look into it if you open-source your process.

There is also the issue that links to e.g. std_algorithm.html 
will be broken, because that module no longer exists. Currently, 
the Makefiles generate std_algorithm_package.html, which will 
likely cause old links to point to stale versions of the 
std.algorithm (the module)'s documentation. I think 
std.algorithm.package documentation should be written to 
std_algorithm.html, or some sort of redirect be set up.

Jan 30 2015

"Martin Nowak" <code dawg.eu> writes:

On Saturday, 31 January 2015 at 02:22:59 UTC, Vladimir Panteleev 
wrote:
 I don't know how the .html files that are included in dmd.zip 
 are generated. Please try and see if it works for you. If not, 
 I can look into it if you open-source your process.

https://github.com/D-Programming-Language/installer/blob/4d57e861a2b15767f5e004b74a4578205dc03e3e/create_dmd_release/create_dmd_release.d#L784

Not sure if anyone is actually using those HTML files.

Feb 15 2015

"Martin Nowak" <code dawg.eu> writes:

On Friday, 30 January 2015 at 22:06:34 UTC, Walter Bright wrote:
 Time to button this up and release it. Remaining regressions:

 https://issues.dlang.org/buglist.cgi?bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&list_id=192294&query_format=advanced

Please let's finish the GC work for 2.067, will take about 1-1.5 
week.

Jan 30 2015

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 1/30/15 6:39 PM, Martin Nowak wrote:
 On Friday, 30 January 2015 at 22:06:34 UTC, Walter Bright wrote:
 Time to button this up and release it. Remaining regressions:

 https://issues.dlang.org/buglist.cgi?bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&list_id=192294&query_format=advanced

 Please let's finish the GC work for 2.067, will take about 1-1.5 week.

Can we commit to having stuff done by Feb 15 for a release on Mar 1? -- 
Andrei

Jan 30 2015

"Martin Nowak" <code dawg.eu> writes:

 Can we commit to having stuff done by Feb 15 for a release on 
 Mar 1? -- Andrei

Sounds good, work on regressions should start soon and we should 
no longer add features.

Jan 31 2015

"Dicebot" <public dicebot.lv> writes:

On Saturday, 31 January 2015 at 09:14:14 UTC, Martin Nowak wrote:
 Sounds good, work on regressions should start soon and we 
 should no longer add features.

You are not going to do a release branch?

Feb 01 2015

"Puneet Goel" <puneet nospam.com> writes:

On Saturday, 31 January 2015 at 09:14:14 UTC, Martin Nowak wrote:
 Can we commit to having stuff done by Feb 15 for a release on 
 Mar 1? -- Andrei

 Sounds good, work on regressions should start soon and we 
 should no longer add features.

Martin

Can you take a look at 
https://issues.dlang.org/show_bug.cgi?id=14126 ?
Not sure if this regression is related to recent changes in the 
GC. But if it is, it might be prudent to postpone merging in the 
changes into 2.067.

- Puneet

Feb 04 2015

D Programming

C/C++ Programming

Other

digitalmars.D - Time for 2.067