I'm going through bugzilla in increasing ID order looking for tasks to bootcamp, and am finding a bunch of old bugs that haven't been looked at in a long time.

It would be really great to get rid of some of these old issues and generally put some order in our bugzilla. If some are just enhancements that given the current direction of D will never happen (as is the case with the proposed syntax "static else if" as an alternative/replacement for "else static if") please let me know and I'll look into closing them.

We've been liberal about putting things in bugzilla. Well, at some time we also need to look at them - it's not a write-only database like in that joke :o).

For example, https://issues.dlang.org/show_bug.cgi?id=1448 should be addressable. Either we should provide a translation function for outputting things and recommend it, or document that codepages that D runs on Windows etc - there's got to be a solution. It's not an NP-complete problem. Can somebody fluent in Windows codepages take a look?


Thanks,

Andrei

> For example, https://issues.dlang.org/show_bug.cgi?id=1448 should be addressable. Either we should provide a translation function for outputting things and recommend it, or document that codepages that D runs on Windows etc - there's got to be a

What is IMHO needed to fix this bug, is to add to stdio an automatic translation to console codepage (when reading/writing from/to console window). Actual translation functions are in Phobos already (std.windows.charset).

On Friday, 14 October 2016 at 00:38:48 UTC, Andrei Alexandrescu wrote:
> For example, https://issues.dlang.org/show_bug.cgi?id=1448 should be addressable.

The bug is in the DigitalMars C runtime.

See also my comment on issue 2742:

https://issues.dlang.org/show_bug.cgi?id=2742#c14

On 10/13/2016 10:40 PM, Vladimir Panteleev wrote:
> https://issues.dlang.org/show_bug.cgi?id=2742#c14

When I start a command prompt in Windows, I run the command:

    chcp 65001

which sets it to Unicode.

I've been doing a bit of triaging when I got time, trying to get rid of old bugs / duplicated.

It's usually easy to confirm a bug if there's a minimal code example, in which case you can just close it. The enhancement requests, however, nobody but a bunch of people in the core team can get rid of them, because they require a decision to be made. So unless there was a discussion where you or Walter agreed on it (like for deprecating comma operator or implicit string concatenation), they just sit there forever.

Eventually, with the new DIP process, we could gradually get rid of them by pointing the author to the DIP repo, then let him/her close the bug as he ACK the notification, or do it after a certain time. What do you think ?

2016-10-14 2:38 GMT+02:00 Andrei Alexandrescu via Digitalmars-d < digitalmars-d@puremagic.com>:

> I'm going through bugzilla in increasing ID order looking for tasks to bootcamp, and am finding a bunch of old bugs that haven't been looked at in a long time.
>
> It would be really great to get rid of some of these old issues and generally put some order in our bugzilla. If some are just enhancements that given the current direction of D will never happen (as is the case with the proposed syntax "static else if" as an alternative/replacement for "else static if") please let me know and I'll look into closing them.
>
> We've been liberal about putting things in bugzilla. Well, at some time we also need to look at them - it's not a write-only database like in that joke :o).
>
> For example, https://issues.dlang.org/show_bug.cgi?id=1448 should be addressable. Either we should provide a translation function for outputting things and recommend it, or document that codepages that D runs on Windows etc - there's got to be a solution. It's not an NP-complete problem. Can somebody fluent in Windows codepages take a look?
>
>
> Thanks,
>
> Andrei
>

On 10/14/2016 01:40 AM, Vladimir Panteleev wrote:
> On Friday, 14 October 2016 at 00:38:48 UTC, Andrei Alexandrescu wrote:
>> For example, https://issues.dlang.org/show_bug.cgi?id=1448 should be
>> addressable.
>
> The bug is in the DigitalMars C runtime.
>
> See also my comment on issue 2742:
>
> https://issues.dlang.org/show_bug.cgi?id=2742#c14

Great. Vladimir, could you please convert the insights into this thread into institutional memory i.e. put them in a PR for the documentation? Thanks!! -- Andrei

On 10/14/2016 05:12 AM, Mathias Lang via Digitalmars-d wrote:
> I've been doing a bit of triaging when I got time, trying to get rid of
> old bugs / duplicated.
>
> It's usually easy to confirm a bug if there's a minimal code example, in
> which case you can just close it. The enhancement requests, however,
> nobody but a bunch of people in the core team can get rid of them,
> because they require a decision to be made. So unless there was a
> discussion where you or Walter agreed on it (like for deprecating comma
> operator or implicit string concatenation), they just sit there forever.
>
> Eventually, with the new DIP process, we could gradually get rid of them
> by pointing the author to the DIP repo, then let him/her close the bug
> as he ACK the notification, or do it after a certain time. What do you
> think ?

Yes, I've already closed a few enhancement requests (such as overhauling the syntax of templates) suggesting they are pursued as DIPs. I'll do more of that in the future, for now I'm focused on bootcamping select issues. If you could lend a hand, please to! -- Andrei

On 10/14/2016 07:17 AM, Andrei Alexandrescu wrote:
> On 10/14/2016 05:12 AM, Mathias Lang via Digitalmars-d wrote:
>> I've been doing a bit of triaging when I got time, trying to get rid of
>> old bugs / duplicated.
>>
>> It's usually easy to confirm a bug if there's a minimal code example, in
>> which case you can just close it. The enhancement requests, however,
>> nobody but a bunch of people in the core team can get rid of them,
>> because they require a decision to be made. So unless there was a
>> discussion where you or Walter agreed on it (like for deprecating comma
>> operator or implicit string concatenation), they just sit there forever.
>>
>> Eventually, with the new DIP process, we could gradually get rid of them
>> by pointing the author to the DIP repo, then let him/her close the bug
>> as he ACK the notification, or do it after a certain time. What do you
>> think ?
>
> Yes, I've already closed a few enhancement requests (such as overhauling
> the syntax of templates) suggesting they are pursued as DIPs. I'll do
> more of that in the future, for now I'm focused on bootcamping select
> issues. If you could lend a hand, please to! -- Andrei

s/please to/please do/

On Friday, 14 October 2016 at 11:12:34 UTC, Andrei Alexandrescu wrote:
> On 10/14/2016 01:40 AM, Vladimir Panteleev wrote:
>> On Friday, 14 October 2016 at 00:38:48 UTC, Andrei Alexandrescu wrote:
>>> For example, https://issues.dlang.org/show_bug.cgi?id=1448 should be
>>> addressable.
>>
>> The bug is in the DigitalMars C runtime.
>>
>> See also my comment on issue 2742:
>>
>> https://issues.dlang.org/show_bug.cgi?id=2742#c14
>
> Great. Vladimir, could you please convert the insights into this thread into institutional memory i.e. put them in a PR for the documentation? Thanks!! -- Andrei

Documentation for what?

I'm not sure we should be documenting bugs in C standard library implementation internals.

It's better to just fix the bug (but only a few people can do that).

> I'm not sure we should be documenting bugs in C standard library implementation internals.

Users just don't expect broken console output. There should be a note in writeln docs.