January 13, 2012
On 1/12/2012 9:54 AM, Walter Bright wrote:
> On 1/11/2012 11:16 PM, Jacob Carlborg wrote:
>> That's the whole point. It's not clear what the actual specification IS. Is it
>> DMD, dlang.org or TDPL?
>>
>
> It's the "Language Reference" section on dlang.org.
There's a reason this page isn't titled /"C++ Language Specification"/: http://msdn.microsoft.com/en-us/library/3bstk3k5.aspx
January 13, 2012
On 1/12/2012 1:55 PM, Peter Alexander wrote:
>> It's the "Language Reference" section on dlang.org.
> Yes, but there's differences between the language reference and what DMD
> implements. Sometimes the language reference is right, sometimes DMD is right.
> The point is, there's no way for us to know. Only you can decide what is right.

For each difference, somebody has to make a decision which is right. That doesn't mean the Language Reference is not the D specification. It can have errors in it like anything else.

The idea is to identify those discrepancies and get them fixed.

> One example off the top of my head (there are many more):
>
>  From the Lexical page on dlang.org
>
> q{ @ } // error, @ is not a valid D token
>
> But DMD accepts this.

Yes, and now your pull request on that has been pulled. Thanks! That issue is now resolved. On to the next one.

> You've said to post bugs, but these don't receive any attention. For example,
> here's two bugs about the lack of documentation on .stringof, one from 2009 and
> one from early 2011:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=3007
> http://d.puremagic.com/issues/show_bug.cgi?id=5404
>
> Neither of which have received any comments or clarifications.

I'm sorry about that, but I'm running as fast as I can, along with the help of a number of prolific contributors. As you can see by the changelog, there are a zillion issues that do get resolved every month.


> We need a real, up to date, and detailed language specification! Leave the
> implementation to us.

The only way to do it is to identify the issues one by one. I don't know of any other way.

(And a number of people have submitted improvements to the spec, some of them quite extensive, like Stewart Gordon's, which have been incorporated.)
January 13, 2012
On 13/01/2012 06:08, Walter Bright wrote:
> I'm sorry about that, but I'm running as fast as I can, along with the
> help of a number of prolific contributors. As you can see by the
> changelog, there are a zillion issues that do get resolved every month.

Would it be useful if the pull auto tester set up its own git repository you could pull from? You'd do something to mark pull requests which look good, then the pull tester could queue them up to be merged, and merge as many as it can while still passing the testsuite... Then you can pull from there and get more requests tried and tested.

This is slightly advantageous as you don't have to spend time waiting to see if the test suite passes for each pull request, you can set them off before you go to bed and pull lots in the morning (the ones that worked).

Of course this requires some work to get it working in the first place...

-- 
Robert
http://octarineparrot.com/
January 13, 2012
On 1/13/12 12:08 AM, Walter Bright wrote:
>> You've said to post bugs, but these don't receive any attention. For
>> example,
>> here's two bugs about the lack of documentation on .stringof, one from
>> 2009 and
>> one from early 2011:
>>
>> http://d.puremagic.com/issues/show_bug.cgi?id=3007
>> http://d.puremagic.com/issues/show_bug.cgi?id=5404
>>
>> Neither of which have received any comments or clarifications.
>
> I'm sorry about that, but I'm running as fast as I can, along with the
> help of a number of prolific contributors. As you can see by the
> changelog, there are a zillion issues that do get resolved every month.

One important metric we currently neglect is the date of the oldest bug or pull request. If we work on improving that with each release, we give a submitter confidence that their bug will be resolved in reasonable time. A simple policy like "address the oldest 3 bugzilla entries in each release" would be very healthy.


Andrei

January 13, 2012
On 13-01-2012 16:05, Andrei Alexandrescu wrote:
> On 1/13/12 12:08 AM, Walter Bright wrote:
>>> You've said to post bugs, but these don't receive any attention. For
>>> example,
>>> here's two bugs about the lack of documentation on .stringof, one from
>>> 2009 and
>>> one from early 2011:
>>>
>>> http://d.puremagic.com/issues/show_bug.cgi?id=3007
>>> http://d.puremagic.com/issues/show_bug.cgi?id=5404
>>>
>>> Neither of which have received any comments or clarifications.
>>
>> I'm sorry about that, but I'm running as fast as I can, along with the
>> help of a number of prolific contributors. As you can see by the
>> changelog, there are a zillion issues that do get resolved every month.
>
> One important metric we currently neglect is the date of the oldest bug
> or pull request. If we work on improving that with each release, we give
> a submitter confidence that their bug will be resolved in reasonable
> time. A simple policy like "address the oldest 3 bugzilla entries in
> each release" would be very healthy.
>
>
> Andrei
>

The voting system also needs to be paid more attention to. It seems largely ignored.

-- 
- Alex
January 13, 2012
>
> One important metric we currently neglect is the date of the oldest bug or pull request. If we work on improving that with each release, we give a submitter confidence that their bug will be resolved in reasonable time. A simple policy like "address the oldest 3 bugzilla entries in each release" would be very healthy.
>
>
> Andrei

I agree 100%. Many developers of "open" software projects make a big mistake by ignoring users' feedbacks, and then wonder why people suddenly stop reporting problems, and even more importantly - why they stopped sending patches.

Well-done!
January 13, 2012
On 2012-01-13 16:05, Andrei Alexandrescu wrote:
> On 1/13/12 12:08 AM, Walter Bright wrote:
>>> You've said to post bugs, but these don't receive any attention. For
>>> example,
>>> here's two bugs about the lack of documentation on .stringof, one from
>>> 2009 and
>>> one from early 2011:
>>>
>>> http://d.puremagic.com/issues/show_bug.cgi?id=3007
>>> http://d.puremagic.com/issues/show_bug.cgi?id=5404
>>>
>>> Neither of which have received any comments or clarifications.
>>
>> I'm sorry about that, but I'm running as fast as I can, along with the
>> help of a number of prolific contributors. As you can see by the
>> changelog, there are a zillion issues that do get resolved every month.
>
> One important metric we currently neglect is the date of the oldest bug
> or pull request. If we work on improving that with each release, we give
> a submitter confidence that their bug will be resolved in reasonable
> time. A simple policy like "address the oldest 3 bugzilla entries in
> each release" would be very healthy.
>
>
> Andrei
>

I completely agree.

-- 
/Jacob Carlborg
January 13, 2012
On 1/13/2012 6:01 AM, Robert Clipsham wrote:
> Would it be useful if the pull auto tester set up its own git repository you
> could pull from? You'd do something to mark pull requests which look good, then
> the pull tester could queue them up to be merged, and merge as many as it can
> while still passing the testsuite... Then you can pull from there and get more
> requests tried and tested.
>
> This is slightly advantageous as you don't have to spend time waiting to see if
> the test suite passes for each pull request, you can set them off before you go
> to bed and pull lots in the morning (the ones that worked).
>
> Of course this requires some work to get it working in the first place...

Brad has already implemented this.
January 13, 2012
On 13/01/12 3:05 PM, Andrei Alexandrescu wrote:
> On 1/13/12 12:08 AM, Walter Bright wrote:
>>> You've said to post bugs, but these don't receive any attention. For
>>> example,
>>> here's two bugs about the lack of documentation on .stringof, one from
>>> 2009 and
>>> one from early 2011:
>>>
>>> http://d.puremagic.com/issues/show_bug.cgi?id=3007
>>> http://d.puremagic.com/issues/show_bug.cgi?id=5404
>>>
>>> Neither of which have received any comments or clarifications.
>>
>> I'm sorry about that, but I'm running as fast as I can, along with the
>> help of a number of prolific contributors. As you can see by the
>> changelog, there are a zillion issues that do get resolved every month.
>
> One important metric we currently neglect is the date of the oldest bug
> or pull request. If we work on improving that with each release, we give
> a submitter confidence that their bug will be resolved in reasonable
> time. A simple policy like "address the oldest 3 bugzilla entries in
> each release" would be very healthy.

Yes, this would be very good, although I suspect we would quickly hit roadblock bugs, i.e. ones that require a massive amount of work (e.g. 64-bit Windows support) or those that require fundamental changes to the language and require extra consideration (e.g. const postblit).

January 14, 2012
On 1/13/12 1:16 PM, Peter Alexander wrote:
> On 13/01/12 3:05 PM, Andrei Alexandrescu wrote:
>> On 1/13/12 12:08 AM, Walter Bright wrote:
>>>> You've said to post bugs, but these don't receive any attention. For
>>>> example,
>>>> here's two bugs about the lack of documentation on .stringof, one from
>>>> 2009 and
>>>> one from early 2011:
>>>>
>>>> http://d.puremagic.com/issues/show_bug.cgi?id=3007
>>>> http://d.puremagic.com/issues/show_bug.cgi?id=5404
>>>>
>>>> Neither of which have received any comments or clarifications.
>>>
>>> I'm sorry about that, but I'm running as fast as I can, along with the
>>> help of a number of prolific contributors. As you can see by the
>>> changelog, there are a zillion issues that do get resolved every month.
>>
>> One important metric we currently neglect is the date of the oldest bug
>> or pull request. If we work on improving that with each release, we give
>> a submitter confidence that their bug will be resolved in reasonable
>> time. A simple policy like "address the oldest 3 bugzilla entries in
>> each release" would be very healthy.
>
> Yes, this would be very good, although I suspect we would quickly hit
> roadblock bugs, i.e. ones that require a massive amount of work (e.g.
> 64-bit Windows support) or those that require fundamental changes to the
> language and require extra consideration (e.g. const postblit).

I understand. Such issues are not appropriate for bugzilla and should be best filed as language feature requests and directions to pursue. We need to make progress in managing the age of the oldest bug.

IMHO, fixing const postblit (and the last mile of const) an immediate issue, followed by shared and threads. In light of that, working on simd now appears even more like a waste of time.


Andrei