www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Numbering compiler error messages?

reply Johannes Pfau <nospam example.com> writes:


How about adding a small 'error-message ID' like DPL00042 to every
compiler message? This makes it easier to search for information about
the error. If tools want to handle certain compiler errors then
they can grep for the message-ID instead of the complete message.

I thought of adding a wiki page, wiki.dlang.org/Compiler_Messages to
keep a list of all messages. It's then possible to add examples,
detailed information how to resolve an error and links to further
information (e.g. changelog entry for error/warning/deprecated message)
to that page.

I could file a pull request which does this for all existing error
messages, but it requires contributors to follow a small protocol
for future error messages as we need to make sure we do not assign one
ID to different messages:

If you want to introduce a new error message:
Before even opening a pull request, 
* go to  wiki.dlang.org/Compiler_Messages
* pick next free ID 
* add it to the page with status pending
* Once stuff is merged update the description/status on the wiki page

As an example how this could work, search for CS1002.
So do we want this?
Mar 28 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/28/2014 1:23 AM, Johannes Pfau wrote:

 As an example how this could work, search for CS1002.
 So do we want this?


I've done this before. Short answer, it's a pain and doesn't really help.

Searching is easy, just type in the message that was displayed, sans the 
variable part. I do it all the time.
Mar 28 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:


 I've done this before. Short answer, it's a pain and doesn't 
 really help.


Since last time we have discussed this topic I have a better 
answer:

It's a psychological thing: numbering things push people to count 
them and write down a piece of information (like a wiki page) for 
each number. Currently there is no complete dictionary of D 
errors/warnings/dips. This advantage alone seems enough to me to 
justify numbering them.

Bye,
bearophile
Mar 28 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/28/2014 2:09 AM, bearophile wrote:

 Walter Bright:


 I've done this before. Short answer, it's a pain and doesn't really help.


 Since last time we have discussed this topic I have a better answer:

 It's a psychological thing: numbering things push people to count them and
write
 down a piece of information (like a wiki page) for each number. Currently there
 is no complete dictionary of D errors/warnings/dips. This advantage alone seems
 enough to me to justify numbering them.


As I've said, I've done this before. Those lists get just as out of date and 
unmaintained whether they are numbered or not.
Mar 28 2014
prev sibling next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Friday, 28 March 2014 at 09:04:00 UTC, Walter Bright wrote:

 On 3/28/2014 1:23 AM, Johannes Pfau wrote:

 As an example how this could work, search for CS1002.
 So do we want this?


 I've done this before. Short answer, it's a pain and doesn't 
 really help.

 Searching is easy, just type in the message that was displayed, 
 sans the variable part. I do it all the time.


I think we could maybe find a middle ground? Not every error 
needs numbering, but having the more common ones "named and 
tagged and explained" could always help?

I'm thinking things like:
- expression has no effect in...
- cannot default initialize...
- dangling else...
- empty if/for/while statement...

It would really benefit the newer users that hit the error, to 
have a direct link explaining how things work in regards to that.

It doesn't have to be a number. A simple (shortened) link to the 
wiki could also work. Or simply a formalized error name "Invalid 
default initialization Error: Custom error message here"

A good argument in favor of that is that *you* would merely add 
the link in the compiler, and the community could document and 
explain the error.

Well, I'm just throwing that out there.
Mar 28 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/28/2014 2:23 AM, monarch_dodra wrote:

 Well, I'm just throwing that out there.


I've thought many times that an error message should be a clickable link. But 
until console displays support clickable text, it's just a fantasy.
Mar 28 2014
next sibling parent "w0rp" <devw0rp gmail.com> writes:
On Friday, 28 March 2014 at 18:09:00 UTC, Walter Bright wrote:

 On 3/28/2014 2:23 AM, monarch_dodra wrote:

 Well, I'm just throwing that out there.


 I've thought many times that an error message should be a 
 clickable link. But until console displays support clickable 
 text, it's just a fantasy.


You could output a URL. Some terminals support magically turning 
URLs into links.
Mar 28 2014
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-03-28 19:09, Walter Bright wrote:


 I've thought many times that an error message should be a clickable
 link. But until console displays support clickable text, it's just a
 fantasy.


There are other output forms, like IDE's and text editors that support 
links.

-- 
/Jacob Carlborg
Mar 30 2014
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 28.03.2014 19:09, schrieb Walter Bright:

 On 3/28/2014 2:23 AM, monarch_dodra wrote:

 Well, I'm just throwing that out there.


 I've thought many times that an error message should be a clickable
 link. But until console displays support clickable text, it's just a
 fantasy.


Actually on GNU/Linux systems many do.
Mar 30 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/30/2014 4:04 AM, Paulo Pinto wrote:

 Am 28.03.2014 19:09, schrieb Walter Bright:

 On 3/28/2014 2:23 AM, monarch_dodra wrote:

 Well, I'm just throwing that out there.


 I've thought many times that an error message should be a clickable
 link. But until console displays support clickable text, it's just a
 fantasy.


 Actually on GNU/Linux systems many do.


I just tried it on Ubuntu and - you're right! Pretty awesome.

Can the URL be hidden behind text, like you'd do with html:

  <a href="dconf.org">D Conf!</a>

so the user sees the text rather than the link?
Mar 30 2014
next sibling parent "w0rp" <devw0rp gmail.com> writes:
On Sunday, 30 March 2014 at 19:23:43 UTC, Walter Bright wrote:

 On 3/30/2014 4:04 AM, Paulo Pinto wrote:

 Am 28.03.2014 19:09, schrieb Walter Bright:

 On 3/28/2014 2:23 AM, monarch_dodra wrote:

 Well, I'm just throwing that out there.


 I've thought many times that an error message should be a 
 clickable
 link. But until console displays support clickable text, it's 
 just a
 fantasy.


 Actually on GNU/Linux systems many do.


 I just tried it on Ubuntu and - you're right! Pretty awesome.

 Can the URL be hidden behind text, like you'd do with html:

  <a href="dconf.org">D Conf!</a>

 so the user sees the text rather than the link?


You can't do that, but you can output the URL and let the
terminal figure out that it should make it clickable at least,
which is what you just tried.
Mar 30 2014
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 30 Mar 2014 15:23:44 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:


 On 3/30/2014 4:04 AM, Paulo Pinto wrote:

 Am 28.03.2014 19:09, schrieb Walter Bright:

 On 3/28/2014 2:23 AM, monarch_dodra wrote:

 Well, I'm just throwing that out there.


 I've thought many times that an error message should be a clickable
 link. But until console displays support clickable text, it's just a
 fantasy.


 Actually on GNU/Linux systems many do.


 I just tried it on Ubuntu and - you're right! Pretty awesome.


Yes, I think a url, even if not clickable, is way more useful than an  
arbitrary error id. It takes not much effort to copy/paste a URL into a  
browser.

We can make this easy:

Compiler outputs a URL like this: http://derror.org/2.065/filename.c/l123

Using a function that takes __FILE__ and __LINE__

Then, include a special comment just before the error output that will be  
parsed by a post-processor, and link that url to the comment (either in  
github, or on a nice web page).

Example:

const char *errurl(const char *file = __FILE__, int line = __LINE__); //  
does this work in C++? I can't remember!

// <ERRMSG> A variable cannot be re-defined inside a new scope. See  
http://dlang.org/...
error("is shadowing declaration %s%s", s->toPrettyChars(), errurl());

errurl could be configured to print a URL or nothing via a command line  
option.

Bonus: those who know the error url format know exactly where to go in the  
code to see where it was printed from.

-Steve
Mar 31 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/31/2014 5:10 AM, Steven Schveighoffer wrote:

 We can make this easy:


The trouble with outputting URLs is that they will be significant visual noise 
to the user.

Yeah, I know, another compiler switch :-)
Mar 31 2014
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 31 Mar 2014 13:02:48 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:


 On 3/31/2014 5:10 AM, Steven Schveighoffer wrote:

 We can make this easy:


 The trouble with outputting URLs is that they will be significant visual  
 noise to the user.

 Yeah, I know, another compiler switch :-)


Yeah, so?

-Steve
Mar 31 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-03-31 19:02, Walter Bright wrote:


 The trouble with outputting URLs is that they will be significant visual
 noise to the user.


It would be great for those IDE's and text editors that use HTML as 
output format.

-- 
/Jacob Carlborg
Mar 31 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:


 I've done this before.


The ecosystem changes (internet, wikis, IDEs, appear), and 
programmers too change (many learn JavaScript as first language, 
etc). So what's important is if a feature is good today. Past 
experience is useful, but only up to a point.



 it's a pain


What is the pain caused by those numbers?

Bye,
bearophile
Mar 28 2014
parent "Asman01" <jckj33 gmail.com> writes:
On Friday, 28 March 2014 at 11:15:36 UTC, bearophile wrote:

 Walter Bright:


 I've done this before.


 The ecosystem changes (internet, wikis, IDEs, appear), and 
 programmers too change (many learn JavaScript as first 
 language, etc). So what's important is if a feature is good 
 today. Past experience is useful, but only up to a point.



 it's a pain


 What is the pain caused by those numbers?

 Bye,
 bearophile


I think he's speaking about mantain the table with the errors 
messages and errors code and I did a program that used a similar 
approach. It was written in C so maping this values is too 
expansive and tedious.

Instead of

error("undefined variable %s", id->name);

you need to:

error(ERR_UNDEF_VAR, get_error_msg_string(ERR_UNDEF_VAR), 
ERR_UNDEF_VAR, id->name);

the error string should contains also error message itself but 
the formatting too. Formatting are used in functions which do 
accept a variadic arguments if you do some update in the string 
and forget to add respective argument or change the order of your 
enum member and it mismatch to error_msgs_strings table index you 
just will print garbage/wrong error message and or number/crash 
program.

const char *error_msgs_strings[] = {
   "error code: %d undefined variable %s",
   "...",
};

Also, I was using linear error codes in this example and you're 
not looking for this, isn't? I don't know much application which 
does somethng like this. In this case, a simple 
error_msgs_strings[ERR_UNDEF_VAR] will not work and you need to 
create a hashtable. To print a single error code you need to do a 
search now just like it does for every identifier in the program. 
It isn't too bad since compile errors aren't too often necessary 
to do like a search for a identifier in the string table. But it 
depending how large is your table of error messages and if you 
are using an approach that isn't exit in the first error message, 
it will make the edit-and-compile cycle too slow.
Mar 28 2014
prev sibling parent =?UTF-8?Q?Tobias=20M=C3=BCller?= <troplin bluewin.ch> writes:
Walter Bright <newshound2 digitalmars.com> wrote:

 On 3/28/2014 1:23 AM, Johannes Pfau wrote:

 As an example how this could work, search for CS1002.
 So do we want this?


 
 I've done this before. Short answer, it's a pain and doesn't really help.
 
 Searching is easy, just type in the message that was displayed, sans the
 variable part. I do it all the time.


I think some sort of short identifier for warnings and errors would be
beneficial. It does not have to be a number.

Advantages not already mentioned:
- Messages can change/improve over time, the ID remains the same.
- Enable/disable warnings by ID.

And this would again enable tools to disable a warning e.g. by
right-clicking on the actual message.

I imagine there are more similar tasks that can be done with only the ID
without actually knowing the meaning of the warning.
Like turning warnings into errors if you don't like the usecase of
disabling warnings.

Since you are already considering URLs in the messages, you need some kind
of ID anyway, otherwise you couldn't build an URL.

Tobi
Mar 31 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Johannes Pfau:


 How about adding a small 'error-message ID' like DPL00042 to 
 every compiler message? This makes it easier to search for 
 information about the error.


I still think it's a good idea for D. It was proposed time ago.

It has two advantages:
- Make it easier to find info about an error. The info can 
explain the bug, show clear examples of the mistake, and how to 
fix it.
- Give some discipline, order and systematicness to the world of 
D errors/warnings.

Bye,
bearophile
Mar 28 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/28/2014 2:05 AM, bearophile wrote:

 Johannes Pfau:


 How about adding a small 'error-message ID' like DPL00042 to every compiler
 message? This makes it easier to search for information about the error.


 I still think it's a good idea for D. It was proposed time ago.

 It has two advantages:
 - Make it easier to find info about an error.


No, it doesn't. Really. Grep does a fantastic job of that.



 - Give some discipline, order and systematicness to the world of D
errors/warnings.


Been there, done that, doesn't work.

The ID's also make error messages look just plain ugly, as well as causing 
premature line wrapping, further uglifying the display.
Mar 28 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-03-28 19:15, Walter Bright wrote:


 The ID's also make error messages look just plain ugly, as well as
 causing premature line wrapping, further uglifying the display.


There can of course be a flag that is required to be used to output the 
ID of the error message.

-- 
/Jacob Carlborg
Mar 30 2014
prev sibling next sibling parent reply "Andrea Fontana" <nospam example.com> writes:
On Friday, 28 March 2014 at 08:25:05 UTC, Johannes Pfau wrote:



 How about adding a small 'error-message ID' like DPL00042 to 
 every
 compiler message? This makes it easier to search for 
 information about
 the error. If tools want to handle certain compiler errors then
 they can grep for the message-ID instead of the complete 
 message.

 I thought of adding a wiki page, 
 wiki.dlang.org/Compiler_Messages to
 keep a list of all messages. It's then possible to add examples,
 detailed information how to resolve an error and links to 
 further
 information (e.g. changelog entry for error/warning/deprecated 
 message)
 to that page.

 I could file a pull request which does this for all existing 
 error
 messages, but it requires contributors to follow a small 
 protocol
 for future error messages as we need to make sure we do not 
 assign one
 ID to different messages:

 If you want to introduce a new error message:
 Before even opening a pull request,
 * go to  wiki.dlang.org/Compiler_Messages
 * pick next free ID
 * add it to the page with status pending
 * Once stuff is merged update the description/status on the 
 wiki page

 As an example how this could work, search for CS1002.
 So do we want this?


There's another advantage. If you want to change error message 
(or add localization like in visual c++) you still can found what 
the error means.

It should be easier for IDE to parse and give suggestions or 
redirect to an help page to solve the problem.
Mar 28 2014
next sibling parent "Joakim" <joakim airpost.net> writes:
On Friday, 28 March 2014 at 09:37:52 UTC, Andrea Fontana wrote:

 There's another advantage. If you want to change error message 
 (or add localization like in visual c++) you still can found 
 what the error means.


This is the only decent reason given for numbering and, 
considering dmd's not localized yet, is far from being a need.  
I'm all for putting better explanations of error messages 
somewhere online, but Walter's right that keyword search is a 
better interface these days and numbering is unnecessary overhead.


 It should be easier for IDE to parse and give suggestions or 
 redirect to an help page to solve the problem.


If there are such help pages for error messages, there's 
basically no advantage to numbering over string matching for the 
error messages and an additional cost of keeping track of all the 
numbers.
Mar 28 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/28/2014 2:37 AM, Andrea Fontana wrote:

 There's another advantage. If you want to change error message (or add
 localization like in visual c++) you still can found what the error means.


Completely worthless:

1. Programmers program in English. Yes, I've asked many international shops 
about this. They want error messages in English.

2. The internationalized messages are *terrible* because you need a person who 
is fluent in that language, and in compilers, to write them. That just doesn't 
work out too well in practice.

3. Every time you add/change an error message to the compiler, then you have to 
go back to (2) and try to deal with that. Never works, or you get crappy 
translations, meaning (1) the foreign programmers again prefer the English
messages.

I.e. been there, done that. Translated messages are great for a lot of apps,
but 
not for programming tools.



 It should be easier for IDE to parse and give suggestions or redirect to an
help
 page to solve the problem.


The IDE doesn't have to parse them. All it has to do is do a substring search. 
The IDE developer would have to provide the patterns to search for, but that 
isn't any harder than creating an indexed table.
Mar 28 2014
next sibling parent reply "Kapps" <opantm2+spam gmail.com> writes:
On Friday, 28 March 2014 at 18:24:21 UTC, Walter Bright wrote:

 The IDE doesn't have to parse them. All it has to do is do a 
 substring search. The IDE developer would have to provide the 
 patterns to search for, but that isn't any harder than creating 
 an indexed table.


Error messages can and frequently are improved and thus are not 
usable by tools. Error codes remain constant and thus are usable 
by tools.

IDE support would also allow things like pressing F1 on an error 
in the error list to be taken to something like wiki/ERR005 which 
may show an explanation of the error or an example of how to fix 
it or such. I'm not sure how useful this particular use case is 
though.

In an ideal world errors would be able to be outputted (using a 
compiler flag) in a program readable way (i.e., JSON or the like, 
with a code representing the error and data for that particular 
error, such as { code: ERR003, description: "variable 'foo' is 
unused", variable: "foo", file: "foo.d", line: 32 }, then your 
IDE could offer to remove the variable for you immediately, as 
well as other nice things like that. But without tool support I 
feel error codes aren't too useful, and in order to provide 
enough context to make tools useful you'd have to parse the error 
message in the first place which immediately makes it not 
practical and defeats the benefit of error codes.
Mar 28 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/28/2014 3:33 PM, Kapps wrote:

 you'd have to parse the error message in the first place which immediately
makes it
 not practical and defeats the benefit of error codes.


It's not necessary to parse the error message. Just do a strstr() on it, that's 
enough to uniquely identify all of them.
Mar 29 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-03-28 23:33, Kapps wrote:


 But without tool support I feel error codes aren't too useful, and in
 order to provide enough context to make tools useful you'd have to parse
 the error message in the first place which immediately makes it not
 practical and defeats the benefit of error codes.


We won't get tool support until there are ID's for error message. It's 
the chicken-and-egg problem.

-- 
/Jacob Carlborg
Mar 30 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/30/2014 4:03 AM, Jacob Carlborg wrote:

 We won't get tool support until there are ID's for error message.


I've pointed out how to do this without ID's several times.
Mar 30 2014
parent Jacob Carlborg <doob me.com> writes:
On 30/03/14 21:16, Walter Bright wrote:


 I've pointed out how to do this without ID's several times.


Are you willing to make the error messages public API? That would go 
through the same stages of deprecation when they need to change?

-- 
/Jacob Carlborg
Mar 30 2014
prev sibling parent reply "Andrea Fontana" <nospam example.com> writes:
On Friday, 28 March 2014 at 18:24:21 UTC, Walter Bright wrote:

 On 3/28/2014 2:37 AM, Andrea Fontana wrote:

 There's another advantage. If you want to change error message 
 (or add
 localization like in visual c++) you still can found what the 
 error means.


 Completely worthless:

 1. Programmers program in English. Yes, I've asked many 
 international shops about this. They want error messages in 
 English.


Good to know. I don't like l10n of messages but many app simply 
use os default language. I hope it doesn't happen then.


 2. The internationalized messages are *terrible* because you 
 need a person who is fluent in that language, and in compilers, 
 to write them. That just doesn't work out too well in practice.
 3. Every time you add/change an error message to the compiler, 
 then you have to go back to (2) and try to deal with that. 
 Never works, or you get crappy translations, meaning (1) the 
 foreign programmers again prefer the English messages.
 I.e. been there, done that. Translated messages are great for a 
 lot of apps, but not for programming tools.


I agree with you about english and programming. My point was to 
show you that there are cases where error codes are useful. 
(however it's not that difficult to translate a message in your 
own native language)


 It should be easier for IDE to parse and give suggestions or 
 redirect to an help
 page to solve the problem.


 The IDE doesn't have to parse them. All it has to do is do a 
 substring search. The IDE developer would have to provide the 
 patterns to search for, but that isn't any harder than creating 
 an indexed table.


I disagree here.

1) If you want to google for error, you have to strip extra info 
(line, symbols, etc)

2) It happens that you search for an error and you find error 
from another compiler.

3) Error messages can be wrong or not well-written (they can 
contains typos). If you change their description to make them 
clear you have to change the pattern.
And if you want to change the format of error messages (let's 
say: add line/column/demangling symbols/giving hints/...) you'll 
probably brake ide parsers. It's quite different if IDE just 
needs to read the first word of line or first match "DPL[0-9]{5}".

4) Don't know if this is a case, but two errors can have similar 
descriptions and googling for an error could drive user to the 
wrong one

5) Why a central map "string code" => "error message" should be 
harder to mantain than a lot of messages putted around the source 
code?
Mar 31 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/31/2014 12:47 AM, Andrea Fontana wrote:

 I disagree here.

 1) If you want to google for error, you have to strip extra info (line,
symbols,
 etc)


Copy-paste with a mouse. The same thing you'd do for a message id number.



 2) It happens that you search for an error and you find error from another
 compiler.


I explained to bearophile in this thread how to do site-specific searches with 
google.



 3) Error messages can be wrong or not well-written (they can contains typos).
If
 you change their description to make them clear you have to change the pattern.
 And if you want to change the format of error messages (let's say: add
 line/column/demangling symbols/giving hints/...) you'll probably brake ide
 parsers. It's quite different if IDE just needs to read the first word of line
 or first match "DPL[0-9]{5}".


Come on, this is not rocket science.



 4) Don't know if this is a case, but two errors can have similar descriptions
 and googling for an error could drive user to the wrong one


Yes, and you can mistype the message number, too.



 5) Why a central map "string code" => "error message" should be harder to
 mantain than a lot of messages putted around the source code?


Because not having a map is easier to maintain than having one.
Mar 31 2014
prev sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Friday, 28 March 2014 at 08:25:05 UTC, Johannes Pfau wrote:



 How about adding a small 'error-message ID' like DPL00042 to 
 every
 compiler message? This makes it easier to search for 
 information about
 the error. If tools want to handle certain compiler errors then
 they can grep for the message-ID instead of the complete 
 message.

 I thought of adding a wiki page, 
 wiki.dlang.org/Compiler_Messages to
 keep a list of all messages. It's then possible to add examples,
 detailed information how to resolve an error and links to 
 further
 information (e.g. changelog entry for error/warning/deprecated 
 message)
 to that page.

 I could file a pull request which does this for all existing 
 error
 messages, but it requires contributors to follow a small 
 protocol
 for future error messages as we need to make sure we do not 
 assign one
 ID to different messages:

 If you want to introduce a new error message:
 Before even opening a pull request,
 * go to  wiki.dlang.org/Compiler_Messages
 * pick next free ID
 * add it to the page with status pending
 * Once stuff is merged update the description/status on the 
 wiki page

 As an example how this could work, search for CS1002.
 So do we want this?


I'm a big fan of CXXXX and LNKXXXX from Visual C++ personally but 
have never brought it up because I know Walter doesn't care for 
them. The quality of error messages in D is a weakness in my 
opinion though so anything to help with that is good in my book.

Thinking aloud here, maybe since DMD is switching to D instead of 
managing IDs they could just be a short hash of the base error 
message. Then a simple program could scan DMD's source and spot 
them all and print out a list which could be compared to the wiki 
list.

Something like this: http://dpaste.dzfl.pl/f552c718e935 (which 
triggers a bug in DMD unfortunately and DMD couldn't use phobos 
anyway).
Mar 28 2014
next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Friday, 28 March 2014 at 17:28:13 UTC, Brad Anderson wrote:

 Something like this: http://dpaste.dzfl.pl/f552c718e935 (which 
 triggers a bug in DMD unfortunately and DMD couldn't use phobos 
 anyway).


Done at runtime so it works at least: 
http://dpaste.dzfl.pl/d3aae13a039c
Mar 28 2014
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Friday, 28 March 2014 at 17:28:13 UTC, Brad Anderson wrote:

 (which triggers a bug in DMD unfortunately and DMD couldn't use 
 phobos anyway).


Already reported: 
https://d.puremagic.com/issues/show_bug.cgi?id=11535
Mar 28 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/28/2014 10:28 AM, Brad Anderson wrote:

 I'm a big fan of CXXXX and LNKXXXX from Visual C++ personally but have never
 brought it up because I know Walter doesn't care for them. The quality of error
 messages in D is a weakness in my opinion though so anything to help with that
 is good in my book.


The quality of error messages is always a problem, but numbers won't fix that. 
(Been there, done that, too. Numbering doesn't clarify things.) What we have 
been doing is, when lousy messages are identified, a PR is often produced to 
improve it. That's how these things get better, one message at a time.
Mar 28 2014
parent reply "Brad Anderson" <eco gnuk.net> writes:
On Friday, 28 March 2014 at 18:28:17 UTC, Walter Bright wrote:

 On 3/28/2014 10:28 AM, Brad Anderson wrote:

 I'm a big fan of CXXXX and LNKXXXX from Visual C++ personally 
 but have never
 brought it up because I know Walter doesn't care for them. The 
 quality of error
 messages in D is a weakness in my opinion though so anything 
 to help with that
 is good in my book.


 The quality of error messages is always a problem, but numbers 
 won't fix that. (Been there, done that, too. Numbering doesn't 
 clarify things.)


I think we'll just have to agree to disagree on that point. I've 
found VC++ error numbers invaluable whenever I confront a 
confusing error. There are often examples of what cause the error 
and how to fix it.


 What we have been doing is, when lousy messages are identified, 
 a PR is often produced to improve it. That's how these things 
 get better, one message at a time.


Yeah, that is true (even if error numbers were adopted).

The error message I've always hated the most is "does not match 
any function template declaration" but error numbers wouldn't 
help with that one because the error is obvious but what exactly 
caused it isn't. I kind of wrote out an idea for one way it could 
be improved awhile back (basically just reformatting the message 
so you can point an arrow at the failing template constraint).

http://forum.dlang.org/thread/mailman.240.1389276481.15871.digitalmars-d puremagic.com?page=4#post-vpglmlxqhiipeyrjfwzx:40forum.dlang.org

It's dated though because CyberShadow has since added column 
numbers and using that would be prefered, I think. Just 
underlining failing template constraint would do wonders. 
Combined with colored output and deciphering this error message 
would be almost pleasant.
Mar 28 2014
next sibling parent reply Martin Nowak <code dawg.eu> writes:
On 03/28/2014 09:32 PM, Brad Anderson wrote:

 The quality of error messages is always a problem, but numbers won't
 fix that. (Been there, done that, too. Numbering doesn't clarify things.)


 I think we'll just have to agree to disagree on that point. I've found
 VC++ error numbers invaluable whenever I confront a confusing error.
 There are often examples of what cause the error and how to fix it.


Well, invest the time saved on maintaining numbers to improve the error 
message thus making it less confusing.
Mar 28 2014
parent reply "Brad Anderson" <eco gnuk.net> writes:
On Saturday, 29 March 2014 at 00:27:36 UTC, Martin Nowak wrote:

 On 03/28/2014 09:32 PM, Brad Anderson wrote:

 The quality of error messages is always a problem, but 
 numbers won't
 fix that. (Been there, done that, too. Numbering doesn't 
 clarify things.)


 I think we'll just have to agree to disagree on that point. 
 I've found
 VC++ error numbers invaluable whenever I confront a confusing 
 error.
 There are often examples of what cause the error and how to 
 fix it.


 Well, invest the time saved on maintaining numbers to improve 
 the error message thus making it less confusing.


I think those are two different problems though. Better error
messages are certainly a good thing that everyone agrees with.
Error numbers solve the problem of keeping error messages brief
while giving the user a way to lookup more information about it.

For example, in VC++ if you get "C2001 newline in constant" you
can just lookup C2001
http://msdn.microsoft.com/en-us/library/4x3c2e37.aspx and there
is a long description of exactly why this error occurs along with
examples of code that can cause the bug and code that fixes the
bug. You aren't going to include all of that in an error message.
Experienced programmers see "newline in constant" and immediately
know the mistake from experience but an new programmer might see
that and think it has something to do with the "const char*"
portion of the line. If you click around other errors in the MSDN
link you'll see they do this for pretty much every error.

I'm convinced it's not worth it for every error but for some of
the more confusing ones that require a longer explanation than
would fit on the command line comfortably it'd be nice to have
somewhere on the wiki that can be linked for people to read more
about it.
Mar 29 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/29/2014 11:02 AM, Brad Anderson wrote:

 For example, in VC++ if you get "C2001 newline in constant" you
 can just lookup C2001
 http://msdn.microsoft.com/en-us/library/4x3c2e37.aspx


Or you could look up "newline in constant".

My point is there's nothing magical about using a number instead. It simply
does 
not enable new features that aren't already there.
Mar 29 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:


 On 3/29/2014 11:02 AM, Brad Anderson wrote:

 For example, in VC++ if you get "C2001 newline in constant" you
 can just lookup C2001
 http://msdn.microsoft.com/en-us/library/4x3c2e37.aspx


 Or you could look up "newline in constant".


If I search this:
C2001 newline in constant

I see the Microsoft page as first Google result:
http://msdn.microsoft.com/en-us/library/4x3c2e37.aspx

If I search this:
newline in constant

The desired Microsoft page is not in the first page of ten 
results given by Google. The third link it to a not correct page:
http://support.microsoft.com/kb/827420

(And still, I have not seen addressed the psychological point I 
have explained in a precedent post).

Bye,
bearophile
Mar 29 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/29/2014 12:07 PM, bearophile wrote:

 Walter Bright:


 On 3/29/2014 11:02 AM, Brad Anderson wrote:

 For example, in VC++ if you get "C2001 newline in constant" you
 can just lookup C2001
 http://msdn.microsoft.com/en-us/library/4x3c2e37.aspx


 Or you could look up "newline in constant".


 If I search this:
 C2001 newline in constant

 I see the Microsoft page as first Google result:
 http://msdn.microsoft.com/en-us/library/4x3c2e37.aspx

 If I search this:
 newline in constant

 The desired Microsoft page is not in the first page of ten results given by
 Google. The third link it to a not correct page:
 http://support.microsoft.com/kb/827420


Or you could:

   visual studio 2013 error newline in constant

or:

   msdn error newline in constant

or even better:

   "newline in constant" site:microsoft.com

This is pretty basic google-fu



 (And still, I have not seen addressed the psychological point I have explained
 in a precedent post).


I did, specifically.
Mar 29 2014
parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:


 (And still, I have not seen addressed the psychological point 
 I have explained in a precedent post).


 I did, specifically.


Sorry, I didn't see it.

Bye,
bearophile
Mar 29 2014
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Mar 29, 2014 at 12:00:51PM -0700, Walter Bright wrote:

 On 3/29/2014 11:02 AM, Brad Anderson wrote:

For example, in VC++ if you get "C2001 newline in constant" you
can just lookup C2001
http://msdn.microsoft.com/en-us/library/4x3c2e37.aspx


 
 Or you could look up "newline in constant".
 
 My point is there's nothing magical about using a number instead. It
 simply does not enable new features that aren't already there.


I think there's merit in using an error number. It allows easier
programmatic processing, for example. An IDE might want to detect
certain error numbers and give some more specific user feedback or
suggest possible fixes.

While you *could* do the same with just a string lookup, that's unstable
because presumably, compiler error messages would be improved every now
and then, and you don't want a simple rephrasing of the error to require
updating every single IDE and other tool just to match the new wording
of the same error.

Also, not every error needs a separate number; some parts of the
compiler may generate different error messages for what is essentially
the same underlying problem (this may depend on the specific evaluation
order of the erroneous input, for example). By assigning a single error
number for both messages, you can aid automated processing tools like
IDEs to treat a variety of messages as a single logical problem that can
be uniformly handled.

To do the same using string lookups will require unnecessary additional
effort on the part of the IDE/tool implementor. (And it would break as
soon as a PR that improves compiler error messages gets pulled.)


T

-- 
VI = Visual Irritation
Mar 29 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/29/2014 1:11 PM, H. S. Teoh wrote:

 I think there's merit in using an error number. It allows easier
 programmatic processing, for example.


     strstr(s,"C2001")

is not any easier than:

     strstr(s, "newline in constant")



 An IDE might want to detect
 certain error numbers and give some more specific user feedback or
 suggest possible fixes.


Sure. But numbers are hardly necessary for that.



 While you *could* do the same with just a string lookup,


And it's trivial to do so. No extra work at all. See strstr() above.



 that's unstable
 because presumably, compiler error messages would be improved every now
 and then, and you don't want a simple rephrasing of the error to require
 updating every single IDE and other tool just to match the new wording
 of the same error.


Sorry, even with numbers, you gotta go fix the strings everywhere. After all, 
the user would be quite confused if he saw different error messages under 
"C2001" in the documentation than coming from his compiler.

And besides, this DRY problem was solved decades ago. Have a common file from 
which all message texts are drawn.



 Also, not every error needs a separate number; some parts of the
 compiler may generate different error messages for what is essentially
 the same underlying problem (this may depend on the specific evaluation
 order of the erroneous input, for example). By assigning a single error
 number for both messages, you can aid automated processing tools like
 IDEs to treat a variety of messages as a single logical problem that can
 be uniformly handled.


I suggest a simple solution:

    if (A || B) { ... common handler code ... }



 To do the same using string lookups will require unnecessary additional
 effort on the part of the IDE/tool implementor. (And it would break as
 soon as a PR that improves compiler error messages gets pulled.)


I've done error numbers before. It is not less effort - it's more - and it's 
ugly visual noise to the user as well. It's a 1980's solution, forced more or 
less because memory was incredibly tight and I/O was incredibly slow.
Mar 29 2014
prev sibling parent reply Kenji Hara <k.hara.pg gmail.com> writes:
I agree with Walter here. Maintaining error numbers for all errors would
require not little cost for compiler code and documentations, AND it will
slow down compiler improvements for more better diagnostic messages so we
would need to keep backward compatibility of error numbers.

I'll refuse to maintain error number feature.

Kenji Hara

2014-03-30 5:11 GMT+09:00 H. S. Teoh <hsteoh quickfur.ath.cx>:


 On Sat, Mar 29, 2014 at 12:00:51PM -0700, Walter Bright wrote:

 On 3/29/2014 11:02 AM, Brad Anderson wrote:

For example, in VC++ if you get "C2001 newline in constant" you
can just lookup C2001
http://msdn.microsoft.com/en-us/library/4x3c2e37.aspx


 Or you could look up "newline in constant".

 My point is there's nothing magical about using a number instead. It
 simply does not enable new features that aren't already there.


 I think there's merit in using an error number. It allows easier
 programmatic processing, for example. An IDE might want to detect
 certain error numbers and give some more specific user feedback or
 suggest possible fixes.

 While you *could* do the same with just a string lookup, that's unstable
 because presumably, compiler error messages would be improved every now
 and then, and you don't want a simple rephrasing of the error to require
 updating every single IDE and other tool just to match the new wording
 of the same error.

 Also, not every error needs a separate number; some parts of the
 compiler may generate different error messages for what is essentially
 the same underlying problem (this may depend on the specific evaluation
 order of the erroneous input, for example). By assigning a single error
 number for both messages, you can aid automated processing tools like
 IDEs to treat a variety of messages as a single logical problem that can
 be uniformly handled.

 To do the same using string lookups will require unnecessary additional
 effort on the part of the IDE/tool implementor. (And it would break as
 soon as a PR that improves compiler error messages gets pulled.)


 T

 --
 VI = Visual Irritation
Mar 29 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/29/2014 8:50 PM, Kenji Hara wrote:

 I'll refuse to maintain error number feature.


:-)
Mar 29 2014
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Sunday, 30 March 2014 at 05:12:35 UTC, Walter Bright wrote:

 On 3/29/2014 8:50 PM, Kenji Hara wrote:

 I'll refuse to maintain error number feature.


 :-)


Well, I think would be a "nice plus". If we have it, "yay!", but 
if we don't, I won't miss it.

Given Walter and Kenji's (and the rest of DMD's) limited 
manpower, I completely support their decision to not deploy this.

I think we should focus on improvements that *really* make a 
change.
Mar 30 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/30/2014 3:53 AM, monarch_dodra wrote:

 I think we should focus on improvements that *really* make a change.


Yup.
Mar 30 2014
prev sibling parent =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
 I think we should focus on improvements that *really* make a 
 change.


I've been missing from time to time the ability to sort my 
messages on *type* rather than file or line together with an IDE 
that present these in a tree (GUI) view where each warning 
message type node can be expanded or compressed. At least for big 
projects written in C/C++ where people have accidentally turned 
off important warning messages and then some other guy have found 
out that we need to turn it on (again) this would be a useful 
feature. This mainly because it's easier to fix a set of similar 
warnings at the same time as the solutions often are more closely 
related than warnings of different kind related solely by line 
locality.

Now, of course, D isn't C/C++ and D programs don't generated as 
my garbage output as C/C++ does when compiled...but still could 
become handy in very large D projects.
Mar 30 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/28/2014 1:32 PM, Brad Anderson wrote:

 I think we'll just have to agree to disagree on that point. I've found VC++
 error numbers invaluable whenever I confront a confusing error. There are often
 examples of what cause the error and how to fix it.


And why doesn't grepping on the text of the error message work?

BTW, I often encounter perplexing messages from Linux, and I just plug the text 
into google.
Mar 29 2014
next sibling parent reply "w0rp" <devw0rp gmail.com> writes:
I agree with Walter about error numbers being a bad idea. 
Especially when people prefer the numbers over a description. 
MySQL has really turned me off the idea of error numbers. When I 
get an error about MySQL syntax, the message actually reads like 
this.

"Error near <snippet> <line number> <column number> ... <error 
number>"

It never tells you what kind of syntax error you made, or 
*exactly* where it actually happened (The line and column numbers 
are misleading.). You just get a message "well it broke" and an 
error number which might as well be the result of a hash 
function. As a result, I hardly ever look up the error number, 
and I just make a guess as to what I did wrong. It's usually 
faster to guess.

It's kind of like the effect bug IDs can have on commit 
messagses, which I mentioned in another thread. If you put some 
ID you can search for in a message, some people have a tendency 
to rely on the ID and forget about providing a descriptive 
message as well.

I think a better approach is to just describe the error better. 
When I use DMD I get some pretty good results already for errors. 
We just need to patch messages which may be confusing at the 
moment into being more descriptive.
Mar 29 2014
parent reply "froglegs" <nono yahoo.com> writes:
On Saturday, 29 March 2014 at 15:37:05 UTC, w0rp wrote:

 I agree with Walter about error numbers being a bad idea. 
 Especially when people prefer the numbers over a description. 
 MySQL has really turned me off the idea of error numbers. When 
 I get an error about MySQL syntax, the message actually reads 
 like this.

 "Error near <snippet> <line number> <column number> ... <error 
 number>"

 It never tells you what kind of syntax error you made, or 
 *exactly* where it actually happened (The line and column 
 numbers are misleading.). You just get a message "well it 
 broke" and an error number which might as well be the result of 
 a hash function. As a result, I hardly ever look up the error 
 number, and I just make a guess as to what I did wrong. It's 
 usually faster to guess.

 It's kind of like the effect bug IDs can have on commit 
 messagses, which I mentioned in another thread. If you put some 
 ID you can search for in a message, some people have a tendency 
 to rely on the ID and forget about providing a descriptive 
 message as well.

 I think a better approach is to just describe the error better. 
 When I use DMD I get some pretty good results already for 
 errors. We just need to patch messages which may be confusing 
 at the moment into being more descriptive.


   The way Visual C++ does it is that you get *both* and error
number and an error message.  Having the error number is very
useful for googling(yes the complete message will give you hits,

quickly referring to a given error.
Mar 29 2014
next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Saturday, 29 March 2014 at 17:12:45 UTC, froglegs wrote:

 On Saturday, 29 March 2014 at 15:37:05 UTC, w0rp wrote:

 I agree with Walter about error numbers being a bad idea. 
 Especially when people prefer the numbers over a description. 
 MySQL has really turned me off the idea of error numbers. When 
 I get an error about MySQL syntax, the message actually reads 
 like this.

 "Error near <snippet> <line number> <column number> ... <error 
 number>"

 It never tells you what kind of syntax error you made, or 
 *exactly* where it actually happened (The line and column 
 numbers are misleading.). You just get a message "well it 
 broke" and an error number which might as well be the result 
 of a hash function. As a result, I hardly ever look up the 
 error number, and I just make a guess as to what I did wrong. 
 It's usually faster to guess.

 It's kind of like the effect bug IDs can have on commit 
 messagses, which I mentioned in another thread. If you put 
 some ID you can search for in a message, some people have a 
 tendency to rely on the ID and forget about providing a 
 descriptive message as well.

 I think a better approach is to just describe the error 
 better. When I use DMD I get some pretty good results already 
 for errors. We just need to patch messages which may be 
 confusing at the moment into being more descriptive.


   The way Visual C++ does it is that you get *both* and error
 number and an error message.  Having the error number is very
 useful for googling(yes the complete message will give you hits,

 quickly referring to a given error.


Yeah, exactly. You wouldn't lose the short error descriptions.
That'd be absurd.
Mar 29 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/29/2014 10:12 AM, froglegs wrote:

 Having the error number is very
 useful for googling(yes the complete message will give you hits,



More hits? How is that possible?
Mar 29 2014
parent reply Matt Soucy <msoucy csh.rit.edu> writes:
On 03/29/2014 02:53 PM, Walter Bright wrote:

 On 3/29/2014 10:12 AM, froglegs wrote:

 Having the error number is very
 useful for googling(yes the complete message will give you hits,



 
 More hits? How is that possible?
 
 
 


For starters, having a URL such as http://dlang.org/error/D123 is
instantly recognizable, so when users see a DXYZ error code before and
remember that they ended up on http://dlang.org/error/DXYZ, they'll be
more likely to remember. (I'm looking at you, MSDN pages with
impossible-to-remember URLs) This way, the user will eventually just
skip the search engine altogether and just go directly to the error's page.

-- 
Matt Soucy
http://msoucy.me/
Mar 30 2014
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Matt Soucy"  wrote in message news:lh8nkd$mst$1 digitalmars.com...


 For starters, having a URL such as http://dlang.org/error/D123 is
 instantly recognizable, so when users see a DXYZ error code before and
 remember that they ended up on http://dlang.org/error/DXYZ, they'll be
 more likely to remember. (I'm looking at you, MSDN pages with
 impossible-to-remember URLs) This way, the user will eventually just
 skip the search engine altogether and just go directly to the error's 
 page.


Building a compiler for people who can't google is like building a race 
track for people who can't drive.
Mar 30 2014
prev sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Saturday, 29 March 2014 at 07:34:21 UTC, Walter Bright wrote:

 On 3/28/2014 1:32 PM, Brad Anderson wrote:

 I think we'll just have to agree to disagree on that point. 
 I've found VC++
 error numbers invaluable whenever I confront a confusing 
 error. There are often
 examples of what cause the error and how to fix it.


 And why doesn't grepping on the text of the error message work?


grepping what? Surely you don't mean the dmd source code.


 BTW, I often encounter perplexing messages from Linux, and I 
 just plug the text into google.


Yeah, that's precisely how I solve a large portion of my problems
(both while programming and with life in general). I guess the
important point isn't to have error numbers necessarily but to
have one place where people can read more about an error and
share helpful information about an error. When you google dmd
error messages you'll often get ancient D1 forum posts that don't
necessarily apply anymore and you have to weed through a half
dozen different posts before you find some answers.

Perhaps a good compromise would be for errors that are complex
and can't easily be explained in the terse error message there
could be a url on the end that takes the user to a page on the
site or wiki where they can read more. Then only a subset of
errors, the ones that are particularly tricky, must be maintained.
Mar 29 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/29/2014 10:45 AM, Brad Anderson wrote:

 On Saturday, 29 March 2014 at 07:34:21 UTC, Walter Bright wrote:

 On 3/28/2014 1:32 PM, Brad Anderson wrote:

 I think we'll just have to agree to disagree on that point. I've found VC++
 error numbers invaluable whenever I confront a confusing error. There are often
 examples of what cause the error and how to fix it.


 And why doesn't grepping on the text of the error message work?


 grepping what? Surely you don't mean the dmd source code.


Grepping whatever data you are searching for an explanation in.



 When you google dmd
 error messages you'll often get ancient D1 forum posts that don't
 necessarily apply anymore and you have to weed through a half
 dozen different posts before you find some answers.


That wouldn't change with error numbers. What you can do is limit the search to 
the spec. And, having a page with "error messages explained" can be created and 
then use search within that page - this is exactly as effective as having a
page 
with "error numbers explained".



 Perhaps a good compromise would be for errors that are complex
 and can't easily be explained in the terse error message there
 could be a url on the end that takes the user to a page on the
 site or wiki where they can read more.


As mentioned earlier, I'd love to do urls, but,

1. user visible urls are terribly ugly to emit to the console
2. consoles don't support clickable urls
3. consoles don't support hypertext links
Mar 29 2014