* Re: Updated GCC vs Clang diagnostics @ 2012-04-12 21:50 Manuel López-Ibáñez 2012-04-12 21:54 ` Gabriel Dos Reis 0 siblings, 1 reply; 35+ messages in thread From: Manuel López-Ibáñez @ 2012-04-12 21:50 UTC (permalink / raw) To: Jonathan Wakely; +Cc: gcc Mailing List Hi Jonathan, I think the wiki page is a great idea! Thanks for doing this. I am planning to open PRs for all the issues where GCC is worse. I think it would be nice to have even more examples where GCC is better. Examples where GCC is worse can be added to http://gcc.gnu.org/wiki/Better_Diagnostics About automatic macro expansion, actually Clang does not expand macros, they simply track macro locations. GCC can do this right now with -ftrack-macro-expansion, which hopefully will be enabled by default in GCC 4.8 thanks to Dodji's work. And I have a very simple patch that shows the caret for those macro expansions, so the output is the same (except colors and ranges). Then, there are three obvious differences between GCC's and Clang's diagnostics shown int that page: color, ranges and fix-it hints. * The diagnostics support to print a range given two locations is trivial to implement. However, modifying the location machinery so it tracks ranges seems much more complex (and deciding which range to choose in each diagnostic is a lot of work, because there are a lot of diagnostics). * Implementing color is trivial and there are reference implementations in GNU grep and GNU make. It would be much more reliable than parsing the output of GCC. Specially with caret diagnostics. * Fix-it hints would also be quite trivial to implement, but it would be a lot of work to decide which diagnostics should use it, and how. Of course, the major question is: Are the decision makers in GCC interested on any of this? Would some reviewer reject patches implementing them? Are there any conditions attached to the implementation that would be good to know beforehand? Cheers, Manuel. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-12 21:50 Updated GCC vs Clang diagnostics Manuel López-Ibáñez @ 2012-04-12 21:54 ` Gabriel Dos Reis 2012-04-12 22:05 ` Manuel López-Ibáñez 0 siblings, 1 reply; 35+ messages in thread From: Gabriel Dos Reis @ 2012-04-12 21:54 UTC (permalink / raw) To: Manuel López-Ibáñez; +Cc: Jonathan Wakely, gcc Mailing List On Thu, Apr 12, 2012 at 4:49 PM, Manuel López-Ibáñez <lopezibanez@gmail.com> wrote: > Hi Jonathan, >[....] > Of course, the major question is: Are the decision makers in GCC > interested on any of this? > > Would some reviewer reject patches implementing them? I suspect decisions will be based on the implementations themselves. > Are there any conditions attached to the implementation that would be > good to know beforehand? The devils are in the details. -- Gaby ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-12 21:54 ` Gabriel Dos Reis @ 2012-04-12 22:05 ` Manuel López-Ibáñez 2012-04-12 22:18 ` Lawrence Crowl 2012-04-12 22:18 ` Gabriel Dos Reis 0 siblings, 2 replies; 35+ messages in thread From: Manuel López-Ibáñez @ 2012-04-12 22:05 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: Jonathan Wakely, gcc Mailing List On 12 April 2012 23:54, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote: > On Thu, Apr 12, 2012 at 4:49 PM, Manuel López-Ibáñez > <lopezibanez@gmail.com> wrote: >> Hi Jonathan, >>[....] >> Of course, the major question is: Are the decision makers in GCC >> interested on any of this? >> >> Would some reviewer reject patches implementing them? > > I suspect decisions will be based on the implementations themselves. > So given your ideal implementation, if the user-visible result was exactly like the one in Clang, will you be happy with any of the three things: ranges, color and fix-it hints? Or you will prefer to never have some of them or to have them disabled by default? Or to have them, but in a different (user-visible) manner? Cheers, Manuel. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-12 22:05 ` Manuel López-Ibáñez @ 2012-04-12 22:18 ` Lawrence Crowl 2012-04-13 5:12 ` Ian Lance Taylor 2012-04-12 22:18 ` Gabriel Dos Reis 1 sibling, 1 reply; 35+ messages in thread From: Lawrence Crowl @ 2012-04-12 22:18 UTC (permalink / raw) To: Manuel López-Ibáñez Cc: Gabriel Dos Reis, Jonathan Wakely, gcc Mailing List On 4/12/12, Manuel López-Ibáñez <lopezibanez@gmail.com> wrote: > So given your ideal implementation, if the user-visible result > was exactly like the one in Clang, will you be happy with any of > the three things: ranges, color and fix-it hints? There are many issues with color. Does your reader have any color deficiencies? Does your software address them? Does the system software render colors well? Is color contrast sufficient? Is greyscale contrast sufficient? Color is low on my list of desirables. > Or you will prefer to never have some of them or to have them > disabled by default? The first thing I do is turn off colors in /bin/ls because there are actually too few readable color combinations to be very usable. So, I want to have the ability to turn warning colors off. > Or to have them, but in a different (user-visible) manner? This question is hard to answer because I don't know all manners. -- Lawrence Crowl ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-12 22:18 ` Lawrence Crowl @ 2012-04-13 5:12 ` Ian Lance Taylor 2012-04-13 5:58 ` Gabriel Dos Reis ` (2 more replies) 0 siblings, 3 replies; 35+ messages in thread From: Ian Lance Taylor @ 2012-04-13 5:12 UTC (permalink / raw) To: Lawrence Crowl Cc: Manuel López-Ibáñez, Gabriel Dos Reis, Jonathan Wakely, gcc Mailing List Lawrence Crowl <crowl@google.com> writes: > On 4/12/12, Manuel López-Ibáñez <lopezibanez@gmail.com> wrote: >> So given your ideal implementation, if the user-visible result >> was exactly like the one in Clang, will you be happy with any of >> the three things: ranges, color and fix-it hints? > > There are many issues with color. Does your reader have any > color deficiencies? Does your software address them? Does the > system software render colors well? Is color contrast sufficient? > Is greyscale contrast sufficient? Color is low on my list of > desirables. It would be terrible if an error message could not be understood without color. But nobody is suggesting that. The question at hand is whether color can be used to enhance an error message that can be understood without color. For example, whether color can be added to current error messages without any other changes. I personally think it would be an excellent idea. Even clang's C++ error messages can be long. A simple use of color is an excellent way to draw the eye to the more important parts of the message. If the color is not available, then it doesn't help, but the error message can be understood without it. Ian ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-13 5:12 ` Ian Lance Taylor @ 2012-04-13 5:58 ` Gabriel Dos Reis 2012-04-13 6:03 ` Jakub Jelinek 2012-04-13 20:59 ` Lawrence Crowl 2 siblings, 0 replies; 35+ messages in thread From: Gabriel Dos Reis @ 2012-04-13 5:58 UTC (permalink / raw) To: Ian Lance Taylor Cc: Lawrence Crowl, Manuel López-Ibáñez, Jonathan Wakely, gcc Mailing List On Fri, Apr 13, 2012 at 12:11 AM, Ian Lance Taylor <iant@google.com> wrote: > I personally think it would be an excellent idea. Even clang's C++ > error messages can be long. A simple use of color is an excellent way > to draw the eye to the more important parts of the message. If the > color is not available, then it doesn't help, but the error message can > be understood without it. I would expect that an implementation in this direction would transform error ("there is no operator %E with arguments %T and %T", foo, bar, baz) into an internal IL rich enough to represent formatting directives (and "2D" representation) independent of the actual rendering device's capabilities. It would then be up to each output device to display the diagnostics based on their own characteristics (color or not, caret or not, pointing the cursor back to the source file or not). And indeed, it would be really terrible idea if the intelligibility of a diagnostic -requires- colors. -- Gaby ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-13 5:12 ` Ian Lance Taylor 2012-04-13 5:58 ` Gabriel Dos Reis @ 2012-04-13 6:03 ` Jakub Jelinek 2012-04-13 6:07 ` Gabriel Dos Reis 2012-04-13 8:41 ` Manuel López-Ibáñez 2012-04-13 20:59 ` Lawrence Crowl 2 siblings, 2 replies; 35+ messages in thread From: Jakub Jelinek @ 2012-04-13 6:03 UTC (permalink / raw) To: Ian Lance Taylor Cc: Lawrence Crowl, Manuel López-Ibáñez, Gabriel Dos Reis, Jonathan Wakely, gcc Mailing List On Thu, Apr 12, 2012 at 10:11:48PM -0700, Ian Lance Taylor wrote: > Lawrence Crowl <crowl@google.com> writes: > > > On 4/12/12, Manuel López-Ibáñez <lopezibanez@gmail.com> wrote: > >> So given your ideal implementation, if the user-visible result > >> was exactly like the one in Clang, will you be happy with any of > >> the three things: ranges, color and fix-it hints? > > > > There are many issues with color. Does your reader have any > > color deficiencies? Does your software address them? Does the > > system software render colors well? Is color contrast sufficient? > > Is greyscale contrast sufficient? Color is low on my list of > > desirables. > > It would be terrible if an error message could not be understood without > color. But nobody is suggesting that. > > The question at hand is whether color can be used to enhance an error > message that can be understood without color. For example, whether > color can be added to current error messages without any other changes. > > I personally think it would be an excellent idea. Even clang's C++ > error messages can be long. A simple use of color is an excellent way > to draw the eye to the more important parts of the message. If the > color is not available, then it doesn't help, but the error message can > be understood without it. Yeah, I second this. As Manuel said, we should have an option to select never/auto/always coloring, colors must be just visual enhancements of the diagnostics that even when colors are disabled gives all the info that is needed (highlight error/warning/note diagnostic kind keywords, keywords in the source, perhaps types, whatever), we should limit to a very small set of colors, because not so many colors are actually very readable and perhaps make the color sets configurable somehow (things might be different if people use normally black characters on white background or white characters on black background, grep has GREP_COLORS env var here, ls LS_COLORS). Jakub ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-13 6:03 ` Jakub Jelinek @ 2012-04-13 6:07 ` Gabriel Dos Reis 2012-04-13 8:41 ` Manuel López-Ibáñez 1 sibling, 0 replies; 35+ messages in thread From: Gabriel Dos Reis @ 2012-04-13 6:07 UTC (permalink / raw) To: Jakub Jelinek Cc: Ian Lance Taylor, Lawrence Crowl, Manuel López-Ibáñez, Jonathan Wakely, gcc Mailing List On Fri, Apr 13, 2012 at 1:03 AM, Jakub Jelinek <jakub@redhat.com> wrote: > we should limit to a very small > set of colors, because not so many colors are actually very readable and > perhaps make the color sets configurable somehow (things might be different > if people use normally black characters on white background or white > characters on black background, grep has GREP_COLORS env var here, ls > LS_COLORS). I would certainly expect the set of used colors to be small and configurable. Ideally, when mapped to a bicolor rendering with bold and/or underlying they should convey the same visual information. -- Gaby ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-13 6:03 ` Jakub Jelinek 2012-04-13 6:07 ` Gabriel Dos Reis @ 2012-04-13 8:41 ` Manuel López-Ibáñez 2012-04-13 8:47 ` Gabriel Dos Reis 1 sibling, 1 reply; 35+ messages in thread From: Manuel López-Ibáñez @ 2012-04-13 8:41 UTC (permalink / raw) To: Jakub Jelinek Cc: Ian Lance Taylor, Lawrence Crowl, Gabriel Dos Reis, Jonathan Wakely, gcc Mailing List On 13 April 2012 08:03, Jakub Jelinek <jakub@redhat.com> wrote: > On Thu, Apr 12, 2012 at 10:11:48PM -0700, Ian Lance Taylor wrote: >> Lawrence Crowl <crowl@google.com> writes: >> >> > On 4/12/12, Manuel López-Ibáñez <lopezibanez@gmail.com> wrote: >> >> So given your ideal implementation, if the user-visible result >> >> was exactly like the one in Clang, will you be happy with any of >> >> the three things: ranges, color and fix-it hints? >> > >> > There are many issues with color. Does your reader have any >> > color deficiencies? Does your software address them? Does the >> > system software render colors well? Is color contrast sufficient? >> > Is greyscale contrast sufficient? Color is low on my list of >> > desirables. >> >> It would be terrible if an error message could not be understood without >> color. But nobody is suggesting that. >> >> The question at hand is whether color can be used to enhance an error >> message that can be understood without color. For example, whether >> color can be added to current error messages without any other changes. >> >> I personally think it would be an excellent idea. Even clang's C++ >> error messages can be long. A simple use of color is an excellent way >> to draw the eye to the more important parts of the message. If the >> color is not available, then it doesn't help, but the error message can >> be understood without it. > > Yeah, I second this. As Manuel said, we should have an option to select > never/auto/always coloring, colors must be just visual enhancements of the > diagnostics that even when colors are disabled gives all the info that > is needed (highlight error/warning/note diagnostic kind keywords, keywords > in the source, perhaps types, whatever), we should limit to a very small > set of colors, because not so many colors are actually very readable and > perhaps make the color sets configurable somehow (things might be different > if people use normally black characters on white background or white > characters on black background, grep has GREP_COLORS env var here, ls > LS_COLORS). This is exactly what I would like to implement, if I am allowed. But I don't want to turn the diagnostics machinery upside down and implement a "diagnostics internal language" (which I already did in XML http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165#c10, and it sits there useless), just to achieve this. I just want to have a little file called colors.c which abstracts the color implementation including the handling of GCC_COLORS. And add the least amount of code needed to diagnostics.c to check whether the prefix (warning|error|note) should be colored, the caret should be colored, and perhaps the message itself should be colored (or not, once you see the prefix, it is easy to identify the start of messages). That is all that I am proposing. Now, if I can get enough support for this to hope that with a nice implementation it will get accepted, then I will try to get it done. Otherwise, I will just forget about it and enjoy the sun. Cheers, Manuel. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-13 8:41 ` Manuel López-Ibáñez @ 2012-04-13 8:47 ` Gabriel Dos Reis 2012-04-13 9:00 ` Manuel López-Ibáñez 0 siblings, 1 reply; 35+ messages in thread From: Gabriel Dos Reis @ 2012-04-13 8:47 UTC (permalink / raw) To: Manuel López-Ibáñez Cc: Jakub Jelinek, Ian Lance Taylor, Lawrence Crowl, Jonathan Wakely, gcc Mailing List On Fri, Apr 13, 2012 at 3:41 AM, Manuel López-Ibáñez <lopezibanez@gmail.com> wrote: > But I don't want to turn the diagnostics machinery upside down and > implement a "diagnostics internal language" I do think an internal formatting IL/IR for better representation is needed for the kind of things you would like to (e.g. colors) to keep things manageable. That isn't turning things upside down, and it isn't helpful to view it that way. -- Gaby ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-13 8:47 ` Gabriel Dos Reis @ 2012-04-13 9:00 ` Manuel López-Ibáñez 2012-04-13 9:09 ` Gabriel Dos Reis 0 siblings, 1 reply; 35+ messages in thread From: Manuel López-Ibáñez @ 2012-04-13 9:00 UTC (permalink / raw) To: Gabriel Dos Reis Cc: Jakub Jelinek, Ian Lance Taylor, Lawrence Crowl, Jonathan Wakely, gcc Mailing List On 13 April 2012 10:46, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote: > On Fri, Apr 13, 2012 at 3:41 AM, Manuel López-Ibáñez > <lopezibanez@gmail.com> wrote: > >> But I don't want to turn the diagnostics machinery upside down and >> implement a "diagnostics internal language" > > I do think an internal formatting IL/IR for better representation is > needed for the > kind of things you would like to (e.g. colors) to keep things manageable. > That isn't turning things upside down, and it isn't helpful to view > it that way. I am not opposed to having a diagnostics IL/IR, so you or anyone else should feel free to start working on it. But after the XML diagnostics experiment, I personally don't find it interesting enough to work on it (specially to start such a project on my own). As a means to get color output, it would be significantly more code, more invasive change, require more time and effort and produce potentially more bugs than the implementation of colors I am proposing above. So I'd rather work on the latter, even if it is much more limited and less flexible than a diagnostics IL. Cheers, Manuel. > > -- Gaby ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-13 9:00 ` Manuel López-Ibáñez @ 2012-04-13 9:09 ` Gabriel Dos Reis 2012-04-13 14:23 ` Jakub Jelinek 0 siblings, 1 reply; 35+ messages in thread From: Gabriel Dos Reis @ 2012-04-13 9:09 UTC (permalink / raw) To: Manuel López-Ibáñez Cc: Jakub Jelinek, Ian Lance Taylor, Lawrence Crowl, Jonathan Wakely, gcc Mailing List On Fri, Apr 13, 2012 at 4:00 AM, Manuel López-Ibáñez <lopezibanez@gmail.com> wrote: > On 13 April 2012 10:46, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote: >> On Fri, Apr 13, 2012 at 3:41 AM, Manuel López-Ibáñez >> <lopezibanez@gmail.com> wrote: >> >>> But I don't want to turn the diagnostics machinery upside down and >>> implement a "diagnostics internal language" >> >> I do think an internal formatting IL/IR for better representation is >> needed for the >> kind of things you would like to (e.g. colors) to keep things manageable. >> That isn't turning things upside down, and it isn't helpful to view >> it that way. > > I am not opposed to having a diagnostics IL/IR, so you or anyone else > should feel free to start working on it. But after the XML diagnostics > experiment, The XML diagnostics experiment was an external representation. > I personally don't find it interesting enough to work on > it (specially to start such a project on my own). As a means to get > color output, it would be significantly more code, more invasive > change, require more time and effort and produce potentially more bugs > than the implementation of colors I am proposing above. So I'd rather > work on the latter, even if it is much more limited and less flexible > than a diagnostics IL. the short term desire to add color should not cloud the architectural concerns. I don't want to get into a situation when in 3 months someone come and complain that the diagnostic code is too obscure or to hard to debug, and when pressed to explain declares that it was just out of frustration or irony -- and even if it was just frustration, that is a concern. -- Gaby ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-13 9:09 ` Gabriel Dos Reis @ 2012-04-13 14:23 ` Jakub Jelinek 2012-04-13 15:23 ` Gabriel Dos Reis 0 siblings, 1 reply; 35+ messages in thread From: Jakub Jelinek @ 2012-04-13 14:23 UTC (permalink / raw) To: Gabriel Dos Reis Cc: Manuel López-Ibáñez, Ian Lance Taylor, Lawrence Crowl, Jonathan Wakely, gcc Mailing List On Fri, Apr 13, 2012 at 04:09:19AM -0500, Gabriel Dos Reis wrote: > the short term desire to add color should not cloud the architectural concerns. > I don't want to get into a situation when in 3 months someone come and complain > that the diagnostic code is too obscure or to hard to debug, and when pressed > to explain declares that it was just out of frustration or irony -- > and even if it was > just frustration, that is a concern. On the other side, at least for basic color support I see no reason why it would imply the need for any rearchitecturing of the diagnostic machinery. If all we want to initially color is error: in one kind of color, warning: in another one, note: in another one, caret line perhaps some other, then it is just a matter of inserting a few pp_color_switch (pp, COLOR_ERROR); ... pp_color_switch (pp, COLOR_NORMAL);. Or if slightly more is needed, it can be added around some format %letter handlers, say %T could print in some special color if requested. At that point we can have the color support written and if some diagnostic machinery redesign is implemented later, it won't be hard to adjust to it and do more color if desired. Shooting down a potentially user friendly feature to wait until some blue sky redesign is implemented means it might never be implemented. Jakub ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-13 14:23 ` Jakub Jelinek @ 2012-04-13 15:23 ` Gabriel Dos Reis 2012-04-13 15:30 ` NightStrike 0 siblings, 1 reply; 35+ messages in thread From: Gabriel Dos Reis @ 2012-04-13 15:23 UTC (permalink / raw) To: Jakub Jelinek Cc: Manuel López-Ibáñez, Ian Lance Taylor, Lawrence Crowl, Jonathan Wakely, gcc Mailing List On Fri, Apr 13, 2012 at 9:23 AM, Jakub Jelinek <jakub@redhat.com> wrote: > Shooting down a potentially user friendly feature to wait until some blue > sky redesign is implemented means it might never be implemented. This is a mischaracterization and you know it. -- Gaby ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-13 15:23 ` Gabriel Dos Reis @ 2012-04-13 15:30 ` NightStrike 2012-04-13 15:36 ` Gabriel Dos Reis 0 siblings, 1 reply; 35+ messages in thread From: NightStrike @ 2012-04-13 15:30 UTC (permalink / raw) To: Gabriel Dos Reis Cc: Jakub Jelinek, Manuel López-Ibáñez, Ian Lance Taylor, Lawrence Crowl, Jonathan Wakely, gcc Mailing List On Fri, Apr 13, 2012 at 11:22 AM, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote: > On Fri, Apr 13, 2012 at 9:23 AM, Jakub Jelinek <jakub@redhat.com> wrote: > >> Shooting down a potentially user friendly feature to wait until some blue >> sky redesign is implemented means it might never be implemented. > > This is a mischaracterization and you know it. > > -- Gaby It is and it isn't. The guy willing to do the basic color stuff has no desire to do what you want. Is there someone else lined up to do it? If not, then forcing a wait on it effectively blocks the available developer. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-13 15:30 ` NightStrike @ 2012-04-13 15:36 ` Gabriel Dos Reis 2012-04-13 15:41 ` NightStrike 0 siblings, 1 reply; 35+ messages in thread From: Gabriel Dos Reis @ 2012-04-13 15:36 UTC (permalink / raw) To: NightStrike Cc: Jakub Jelinek, Manuel López-Ibáñez, Ian Lance Taylor, Lawrence Crowl, Jonathan Wakely, gcc Mailing List On Fri, Apr 13, 2012 at 10:30 AM, NightStrike <nightstrike@gmail.com> wrote: > On Fri, Apr 13, 2012 at 11:22 AM, Gabriel Dos Reis > <gdr@integrable-solutions.net> wrote: >> On Fri, Apr 13, 2012 at 9:23 AM, Jakub Jelinek <jakub@redhat.com> wrote: >> >>> Shooting down a potentially user friendly feature to wait until some blue >>> sky redesign is implemented means it might never be implemented. >> >> This is a mischaracterization and you know it. >> >> -- Gaby > > It is and it isn't. The guy willing to do the basic color stuff has > no desire to do what you want. Is there someone else lined up to do > it? If not, then forcing a wait on it effectively blocks the > available developer. No. When you submit a patch to GCC (whether it is diagnostics or not is immaterial), you expect that it will get reviewed and recommendations will be made about the appropriate way to get it done. Just have a look at gcc-patches. There is no thing new here. If the submitter refused to follow the recommendations, it is unfair it is being shut down or blocked. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-13 15:36 ` Gabriel Dos Reis @ 2012-04-13 15:41 ` NightStrike 2012-04-13 15:53 ` Gabriel Dos Reis 0 siblings, 1 reply; 35+ messages in thread From: NightStrike @ 2012-04-13 15:41 UTC (permalink / raw) To: Gabriel Dos Reis Cc: Jakub Jelinek, Manuel López-Ibáñez, Ian Lance Taylor, Lawrence Crowl, Jonathan Wakely, gcc Mailing List On Fri, Apr 13, 2012 at 11:36 AM, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote: > On Fri, Apr 13, 2012 at 10:30 AM, NightStrike <nightstrike@gmail.com> wrote: >> On Fri, Apr 13, 2012 at 11:22 AM, Gabriel Dos Reis >> <gdr@integrable-solutions.net> wrote: >>> On Fri, Apr 13, 2012 at 9:23 AM, Jakub Jelinek <jakub@redhat.com> wrote: >>> >>>> Shooting down a potentially user friendly feature to wait until some blue >>>> sky redesign is implemented means it might never be implemented. >>> >>> This is a mischaracterization and you know it. >>> >>> -- Gaby >> >> It is and it isn't. The guy willing to do the basic color stuff has >> no desire to do what you want. Is there someone else lined up to do >> it? If not, then forcing a wait on it effectively blocks the >> available developer. > > No. When you submit a patch to GCC (whether it is diagnostics or not > is immaterial), you expect that it will get reviewed and recommendations > will be made about the appropriate way to get it done. Just have a look > at gcc-patches. There is no thing new here. If the submitter > refused to follow the recommendations, it is unfair it is being shut down > or blocked. Be that as it may, at the end of the day, we won't have color gcc if you insist on waiting for the better framework. Unless, of course, you're going to build the better framework. When you're hungry, sometimes it's better to take an offer of an apple when you really want an orange, because otherwise you have nothing. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-13 15:41 ` NightStrike @ 2012-04-13 15:53 ` Gabriel Dos Reis 2012-04-13 15:59 ` NightStrike 0 siblings, 1 reply; 35+ messages in thread From: Gabriel Dos Reis @ 2012-04-13 15:53 UTC (permalink / raw) To: NightStrike Cc: Jakub Jelinek, Manuel López-Ibáñez, Ian Lance Taylor, Lawrence Crowl, Jonathan Wakely, gcc Mailing List On Fri, Apr 13, 2012 at 10:41 AM, NightStrike <nightstrike@gmail.com> wrote: > On Fri, Apr 13, 2012 at 11:36 AM, Gabriel Dos Reis > <gdr@integrable-solutions.net> wrote: >> On Fri, Apr 13, 2012 at 10:30 AM, NightStrike <nightstrike@gmail.com> wrote: >>> On Fri, Apr 13, 2012 at 11:22 AM, Gabriel Dos Reis >>> <gdr@integrable-solutions.net> wrote: >>>> On Fri, Apr 13, 2012 at 9:23 AM, Jakub Jelinek <jakub@redhat.com> wrote: >>>> >>>>> Shooting down a potentially user friendly feature to wait until some blue >>>>> sky redesign is implemented means it might never be implemented. >>>> >>>> This is a mischaracterization and you know it. >>>> >>>> -- Gaby >>> >>> It is and it isn't. The guy willing to do the basic color stuff has >>> no desire to do what you want. Is there someone else lined up to do >>> it? If not, then forcing a wait on it effectively blocks the >>> available developer. >> >> No. When you submit a patch to GCC (whether it is diagnostics or not >> is immaterial), you expect that it will get reviewed and recommendations >> will be made about the appropriate way to get it done. Just have a look >> at gcc-patches. There is no thing new here. If the submitter >> refused to follow the recommendations, it is unfair it is being shut down >> or blocked. > > Be that as it may, at the end of the day, we won't have color gcc if > you insist on waiting for the better framework. Not necessarily. Would you or Jakub say that he is attempting to shoot down the switch to C++, just because he wants to see some components converted done first (blue sky redesigned done first) even though he did not explicitly offer to do that conversion himself, or would you say that he is making a recommendation of what he considers to be in the best long term interest. I would say the latter. Orange and apple analogy aside. -- Gaby ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-13 15:53 ` Gabriel Dos Reis @ 2012-04-13 15:59 ` NightStrike 2012-04-13 16:02 ` Gabriel Dos Reis 0 siblings, 1 reply; 35+ messages in thread From: NightStrike @ 2012-04-13 15:59 UTC (permalink / raw) To: Gabriel Dos Reis Cc: Jakub Jelinek, Manuel López-Ibáñez, Ian Lance Taylor, Lawrence Crowl, Jonathan Wakely, gcc Mailing List On Fri, Apr 13, 2012 at 11:53 AM, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote: > On Fri, Apr 13, 2012 at 10:41 AM, NightStrike <nightstrike@gmail.com> wrote: >> On Fri, Apr 13, 2012 at 11:36 AM, Gabriel Dos Reis >> <gdr@integrable-solutions.net> wrote: >>> On Fri, Apr 13, 2012 at 10:30 AM, NightStrike <nightstrike@gmail.com> wrote: >>>> On Fri, Apr 13, 2012 at 11:22 AM, Gabriel Dos Reis >>>> <gdr@integrable-solutions.net> wrote: >>>>> On Fri, Apr 13, 2012 at 9:23 AM, Jakub Jelinek <jakub@redhat.com> wrote: >>>>> >>>>>> Shooting down a potentially user friendly feature to wait until some blue >>>>>> sky redesign is implemented means it might never be implemented. >>>>> >>>>> This is a mischaracterization and you know it. >>>>> >>>>> -- Gaby >>>> >>>> It is and it isn't. The guy willing to do the basic color stuff has >>>> no desire to do what you want. Is there someone else lined up to do >>>> it? If not, then forcing a wait on it effectively blocks the >>>> available developer. >>> >>> No. When you submit a patch to GCC (whether it is diagnostics or not >>> is immaterial), you expect that it will get reviewed and recommendations >>> will be made about the appropriate way to get it done. Just have a look >>> at gcc-patches. There is no thing new here. If the submitter >>> refused to follow the recommendations, it is unfair it is being shut down >>> or blocked. >> >> Be that as it may, at the end of the day, we won't have color gcc if >> you insist on waiting for the better framework. > > Not necessarily. > > Would you or Jakub say that he is attempting to shoot down the switch to C++, > just because he wants to see some components converted done first > (blue sky redesigned done first) even though he did not explicitly offer to > do that conversion himself, or would you say that he is making a > recommendation > of what he considers to be in the best long term interest. I would > say the latter. > Orange and apple analogy aside. > > > -- Gaby Ok, fine, but then explain to me how color gcc happens if nobody wants to do the extra work you want? ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-13 15:59 ` NightStrike @ 2012-04-13 16:02 ` Gabriel Dos Reis 0 siblings, 0 replies; 35+ messages in thread From: Gabriel Dos Reis @ 2012-04-13 16:02 UTC (permalink / raw) To: NightStrike Cc: Jakub Jelinek, Manuel López-Ibáñez, Ian Lance Taylor, Lawrence Crowl, Jonathan Wakely, gcc Mailing List On Fri, Apr 13, 2012 at 10:59 AM, NightStrike <nightstrike@gmail.com> wrote: > On Fri, Apr 13, 2012 at 11:53 AM, Gabriel Dos Reis > <gdr@integrable-solutions.net> wrote: >> On Fri, Apr 13, 2012 at 10:41 AM, NightStrike <nightstrike@gmail.com> wrote: >>> On Fri, Apr 13, 2012 at 11:36 AM, Gabriel Dos Reis >>> <gdr@integrable-solutions.net> wrote: >>>> On Fri, Apr 13, 2012 at 10:30 AM, NightStrike <nightstrike@gmail.com> wrote: >>>>> On Fri, Apr 13, 2012 at 11:22 AM, Gabriel Dos Reis >>>>> <gdr@integrable-solutions.net> wrote: >>>>>> On Fri, Apr 13, 2012 at 9:23 AM, Jakub Jelinek <jakub@redhat.com> wrote: >>>>>> >>>>>>> Shooting down a potentially user friendly feature to wait until some blue >>>>>>> sky redesign is implemented means it might never be implemented. >>>>>> >>>>>> This is a mischaracterization and you know it. >>>>>> >>>>>> -- Gaby >>>>> >>>>> It is and it isn't. The guy willing to do the basic color stuff has >>>>> no desire to do what you want. Is there someone else lined up to do >>>>> it? If not, then forcing a wait on it effectively blocks the >>>>> available developer. >>>> >>>> No. When you submit a patch to GCC (whether it is diagnostics or not >>>> is immaterial), you expect that it will get reviewed and recommendations >>>> will be made about the appropriate way to get it done. Just have a look >>>> at gcc-patches. There is no thing new here. If the submitter >>>> refused to follow the recommendations, it is unfair it is being shut down >>>> or blocked. >>> >>> Be that as it may, at the end of the day, we won't have color gcc if >>> you insist on waiting for the better framework. >> >> Not necessarily. >> >> Would you or Jakub say that he is attempting to shoot down the switch to C++, >> just because he wants to see some components converted done first >> (blue sky redesigned done first) even though he did not explicitly offer to >> do that conversion himself, or would you say that he is making a >> recommendation >> of what he considers to be in the best long term interest. I would >> say the latter. >> Orange and apple analogy aside. >> >> >> -- Gaby > > Ok, fine, but then explain to me how color gcc happens if nobody wants > to do the extra work you want? when you said "Ok, fine", which of the two alternatives did you intend? -- Gaby ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-13 5:12 ` Ian Lance Taylor 2012-04-13 5:58 ` Gabriel Dos Reis 2012-04-13 6:03 ` Jakub Jelinek @ 2012-04-13 20:59 ` Lawrence Crowl 2012-04-14 6:58 ` Marc Glisse 2 siblings, 1 reply; 35+ messages in thread From: Lawrence Crowl @ 2012-04-13 20:59 UTC (permalink / raw) To: Ian Lance Taylor Cc: Manuel López-Ibáñez, Gabriel Dos Reis, Jonathan Wakely, gcc Mailing List On 4/12/12, Ian Lance Taylor <iant@google.com> wrote: > Lawrence Crowl <crowl@google.com> writes: > > On 4/12/12, Manuel López-Ibáñez <lopezibanez@gmail.com> wrote: > > > So given your ideal implementation, if the user-visible > > > result was exactly like the one in Clang, will you be happy > > > with any of the three things: ranges, color and fix-it hints? > > > > There are many issues with color. Does your reader have > > any color deficiencies? Does your software address them? > > Does the system software render colors well? Is color contrast > > sufficient? Is greyscale contrast sufficient? Color is low > > on my list of desirables. > > It would be terrible if an error message could not be understood > without color. But nobody is suggesting that. Agreed, no one is suggesting that. However, without care, the message might be harder to understand _with_ color. At a minimum, one should be able to turn the color off. As I understand it, that option is in the plan. > The question at hand is whether color can be used to enhance an > error message that can be understood without color. For example, > whether color can be added to current error messages without any > other changes. Yes, color can enhance the messages. I don't think we disagree on that. My point was that color is a harder problem that many people understand. For instance, there is no set of colors that meet web contrast standards against both black and white backgrounds. As I understand the plan, the colors will be user-configurable, which goes a long way to addressing the problem because the user can choose colors that work for them. It would be nice if the default configuration worked for a large set of folks. > I personally think it would be an excellent idea. Even clang's C++ > error messages can be long. A simple use of color is an excellent > way to draw the eye to the more important parts of the message. > If the color is not available, then it doesn't help, but the > error message can be understood without it. Let me try to be clear. I have no objection to the work as long as I can turn it off. If the issues I mention above are unaddressed, it is likely that I will turn it off, which is why the feature is low on my list of desirables. If other folks desire it, I'm happy to let them have it. I'm even happy to add an environment variable so that they can have it. But, responding to the survey question, for me color is not a priority. -- Lawrence Crowl ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-13 20:59 ` Lawrence Crowl @ 2012-04-14 6:58 ` Marc Glisse 0 siblings, 0 replies; 35+ messages in thread From: Marc Glisse @ 2012-04-14 6:58 UTC (permalink / raw) To: Lawrence Crowl; +Cc: gcc Mailing List On Fri, 13 Apr 2012, Lawrence Crowl wrote: > Yes, color can enhance the messages. I don't think we disagree > on that. My point was that color is a harder problem that many > people understand. For instance, there is no set of colors that > meet web contrast standards against both black and white backgrounds. If we output colored text to a terminal, the colors we will use there are those (usually 8 or 16) set up in the terminal. When you configure your terminal, setting an appropriate color palette is part of it, and when you change the background between light and dark, you also change the palette. Since other applications use colors, I would already be in trouble if they were not readable. So somehow I am not too scared. > As I understand the plan, the colors will be user-configurable, > which goes a long way to addressing the problem because the user > can choose colors that work for them. It would be nice if the > default configuration worked for a large set of folks. To confirm your point, clang managed to chose "bold black" as the default color for "note:", which is grey here but still not so visible on my black background :-( With g++ that prints the context of an error first, I often have to carefully scroll many screens of messages until I find the first actual error, so some flashy color there could help. The one thing I have found colors most useful for is coloring types that use a lot of templates. This has become less needed with g++ that uses intermediate types/typedefs to print a short type, but it was a great way to have the arguments at the same depth visible at a glance, and I still use it occasionally (also on the output of c++filt). -- Marc Glisse ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-12 22:05 ` Manuel López-Ibáñez 2012-04-12 22:18 ` Lawrence Crowl @ 2012-04-12 22:18 ` Gabriel Dos Reis 2012-04-12 22:43 ` Manuel López-Ibáñez 1 sibling, 1 reply; 35+ messages in thread From: Gabriel Dos Reis @ 2012-04-12 22:18 UTC (permalink / raw) To: Manuel López-Ibáñez; +Cc: Jonathan Wakely, gcc Mailing List On Thu, Apr 12, 2012 at 5:05 PM, Manuel López-Ibáñez <lopezibanez@gmail.com> wrote: > On 12 April 2012 23:54, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote: >> On Thu, Apr 12, 2012 at 4:49 PM, Manuel López-Ibáñez >> <lopezibanez@gmail.com> wrote: >>> Hi Jonathan, >>>[....] >>> Of course, the major question is: Are the decision makers in GCC >>> interested on any of this? >>> >>> Would some reviewer reject patches implementing them? >> >> I suspect decisions will be based on the implementations themselves. >> > > So given your ideal implementation, if the user-visible result was > exactly like the one in Clang, will you be happy with any of the three > things: ranges, color and fix-it hints? My ideal isn't to replicate Clang :-) I would like us to set a standard that Clang would have to follow :-) There are several things that need to be considered. The three items above are choices in the toolset. Ideally, I would like to have a mechanism where the output could be configured (through a command line switch, etc) that allows for example IDEs (not just GNU Emacs) to hook into databases of advices, standard definitions, etc. Even for our own testsuites, this might be useful instead of the current one-dimensional char sequence oriented diagnostic testing. > > Or you will prefer to never have some of them or to have them disabled > by default? > > Or to have them, but in a different (user-visible) manner? I suspect to some degree this is closer to I would like to see, but again, I would prefer to make a judgment based on an implementation. -- Gaby ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-12 22:18 ` Gabriel Dos Reis @ 2012-04-12 22:43 ` Manuel López-Ibáñez 2012-04-13 1:40 ` Joe Buck 0 siblings, 1 reply; 35+ messages in thread From: Manuel López-Ibáñez @ 2012-04-12 22:43 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: Jonathan Wakely, gcc Mailing List On 13 April 2012 00:17, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote: > On Thu, Apr 12, 2012 at 5:05 PM, Manuel López-Ibáñez > <lopezibanez@gmail.com> wrote: >> On 12 April 2012 23:54, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote: >>> On Thu, Apr 12, 2012 at 4:49 PM, Manuel López-Ibáñez >>> <lopezibanez@gmail.com> wrote: >>>> Hi Jonathan, >>>>[....] >>>> Of course, the major question is: Are the decision makers in GCC >>>> interested on any of this? >>>> >>>> Would some reviewer reject patches implementing them? >>> >>> I suspect decisions will be based on the implementations themselves. >>> >> >> So given your ideal implementation, if the user-visible result was >> exactly like the one in Clang, will you be happy with any of the three >> things: ranges, color and fix-it hints? > > My ideal isn't to replicate Clang :-) > > I would like us to set a standard that Clang would have to follow :-) > There are several things that need to be considered. > The three items above are choices in the toolset. Ideally, I would > like to have a mechanism where the output could be configured > (through a command line switch, etc) that allows for example IDEs > (not just GNU Emacs) to hook into databases of advices, standard > definitions, etc. Even for our own testsuites, this might be useful > instead of the current one-dimensional char sequence > oriented diagnostic testing. That sounds nice. Are you working on this on a branch? I hope you manage to finish it for GCC 4.8. I would like to have color output. And since nobody is paying me to do this work, I'd rather work on what I would like to have. The question is whether this is something that GCC wants to have. If the answer is NO, that is fine, I will have more free time. If the answer is yes but the implementation has to autodetect low contrast settings / read colors from a configuration file / allow users to input colors in their own language, then thanks but no thanks, I'll choose my free time. If it is ok that the implementation works like grep's, then I may try to find some free time to give it a try, since the probability that some new contributor will implement it instead of just using Clang gets closer to zero as time goes by. Cheers, Manuel. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-12 22:43 ` Manuel López-Ibáñez @ 2012-04-13 1:40 ` Joe Buck 2012-04-13 2:27 ` Manuel López-Ibáñez 2012-04-13 8:59 ` Jonathan Wakely 0 siblings, 2 replies; 35+ messages in thread From: Joe Buck @ 2012-04-13 1:40 UTC (permalink / raw) To: Manuel López-Ibáñez Cc: Gabriel Dos Reis, Jonathan Wakely, gcc Mailing List On Fri, Apr 13, 2012 at 12:42:19AM +0200, Manuel López-Ibáñez wrote: > I would like to have color output. And since nobody is paying me to do > this work, I'd rather work on what I would like to have. The question > is whether this is something that GCC wants to have. > > If the answer is NO, that is fine, I will have more free time. I'm not interested in color output, and would turn it off if it were implemented (the escape sequences would just mess things up when capturing compiler output in log files). Clang is much smarter about identifying what the user probably meant when the issue is a typo, or "." instead of "->" or vice versa. Getting GCC to do at least as well in this area is a much better use of developers' time than presenting a cascade of unintelligible messages resulting from template expansion in full color. That said, you're free to work on what interests you. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-13 1:40 ` Joe Buck @ 2012-04-13 2:27 ` Manuel López-Ibáñez 2012-04-13 3:37 ` Gabriel Dos Reis 2012-04-13 8:59 ` Jonathan Wakely 1 sibling, 1 reply; 35+ messages in thread From: Manuel López-Ibáñez @ 2012-04-13 2:27 UTC (permalink / raw) To: Joe Buck; +Cc: Gabriel Dos Reis, Jonathan Wakely, gcc Mailing List On 13 April 2012 03:40, Joe Buck <Joe.Buck@synopsys.com> wrote: > On Fri, Apr 13, 2012 at 12:42:19AM +0200, Manuel López-Ibáñez wrote: >> I would like to have color output. And since nobody is paying me to do >> this work, I'd rather work on what I would like to have. The question >> is whether this is something that GCC wants to have. >> >> If the answer is NO, that is fine, I will have more free time. > > I'm not interested in color output, and would turn it off if it were > implemented (the escape sequences would just mess things up when capturing > compiler output in log files). My proposal is to follow grep, that is, --color=[never|auto|always]. With auto, color would only be printed when isatty() is true. The default could be auto, or never if some people are very much against it. > Clang is much smarter about identifying what the user probably meant when > the issue is a typo, or "." instead of "->" or vice versa. Getting GCC to > do at least as well in this area is a much better use of developers' time > than presenting a cascade of unintelligible messages resulting from > template expansion in full color. > > That said, you're free to work on what interests you. Yes, there is plenty of things that could be fixed in GCC. And I have fixed my fair share of bugs that don't actually affect me at all, for free, on my free time. I find the color output of Clang just beautiful and, in my opinion, color support in GCC would make it a bit more beautiful and attract new users, so it is a much better use of developer's time than fixing yet another obscure diagnostic issue that only triggers with a careful ad-hoc example. That said, I do really think you are free to work on what interests you, so I hope to see your patches fixing diagnostics issues soon. Cheers, Manuel. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-13 2:27 ` Manuel López-Ibáñez @ 2012-04-13 3:37 ` Gabriel Dos Reis 2012-04-13 8:27 ` Manuel López-Ibáñez 0 siblings, 1 reply; 35+ messages in thread From: Gabriel Dos Reis @ 2012-04-13 3:37 UTC (permalink / raw) To: Manuel López-Ibáñez Cc: Joe Buck, Jonathan Wakely, gcc Mailing List On Thu, Apr 12, 2012 at 9:26 PM, Manuel López-Ibáñez <lopezibanez@gmail.com> wrote: > I find the color output of Clang just beautiful and, in my opinion, > color support in GCC would make it a bit more beautiful and attract > new users, so it is a much better use of developer's time than fixing > yet another obscure diagnostic issue that only triggers with a careful > ad-hoc example. That said, I do really think you are free to work on > what interests you, so I hope to see your patches fixing diagnostics > issues soon. Is this the kind of protracted passive-aggressive opinion you were looking for? -- Gaby ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-13 3:37 ` Gabriel Dos Reis @ 2012-04-13 8:27 ` Manuel López-Ibáñez 2012-04-13 8:41 ` Gabriel Dos Reis 2012-04-13 9:08 ` Jonathan Wakely 0 siblings, 2 replies; 35+ messages in thread From: Manuel López-Ibáñez @ 2012-04-13 8:27 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: Joe Buck, Jonathan Wakely, gcc Mailing List On 13 April 2012 05:36, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote: > On Thu, Apr 12, 2012 at 9:26 PM, Manuel López-Ibáñez > <lopezibanez@gmail.com> wrote: > >> I find the color output of Clang just beautiful and, in my opinion, >> color support in GCC would make it a bit more beautiful and attract >> new users, so it is a much better use of developer's time than fixing >> yet another obscure diagnostic issue that only triggers with a careful >> ad-hoc example. That said, I do really think you are free to work on >> what interests you, so I hope to see your patches fixing diagnostics >> issues soon. > > Is this the kind of protracted passive-aggressive opinion you were looking for? I think my words above should be read in their own context, where their true meaning can be fully appreciated. Then, one may be able to appreciate that: * Saying "I don't think X is important, so I am against it and you should spend your free time in Y." and "Of course, you are free to spend your time in whatever you want." is not logically consistent. The only choices offered are Y or nothing. * A real choice is offered by the paragraph above which changes the statement to "I don't think X is important, and you should use spend your free time on Y, but I am not against Y, so patches welcome." * In the paragraph above, you also seem to have missed the irony that the example I chose as "not important" are small diagnostic issues, on which I (among very very few) have spent significant effort in the recent years. I was hoping that this irony would help the reader to understand that the example is not meant to be taken seriously, and it is only there to demonstrate the previous logical inconsistency. But my writing skills are still as poor as always, since it seems I am having trouble making myself understood by some. So if you still didn't get my point above, I am unable to explain myself in better terms. Thus, let's forget about this and focus on the issue at hand. Cheers, Manuel. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-13 8:27 ` Manuel López-Ibáñez @ 2012-04-13 8:41 ` Gabriel Dos Reis 2012-04-13 9:08 ` Jonathan Wakely 1 sibling, 0 replies; 35+ messages in thread From: Gabriel Dos Reis @ 2012-04-13 8:41 UTC (permalink / raw) To: Manuel López-Ibáñez Cc: Joe Buck, Jonathan Wakely, gcc Mailing List On Fri, Apr 13, 2012 at 3:27 AM, Manuel López-Ibáñez <lopezibanez@gmail.com> wrote: > On 13 April 2012 05:36, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote: >> On Thu, Apr 12, 2012 at 9:26 PM, Manuel López-Ibáñez >> <lopezibanez@gmail.com> wrote: >> >>> I find the color output of Clang just beautiful and, in my opinion, >>> color support in GCC would make it a bit more beautiful and attract >>> new users, so it is a much better use of developer's time than fixing >>> yet another obscure diagnostic issue that only triggers with a careful >>> ad-hoc example. That said, I do really think you are free to work on >>> what interests you, so I hope to see your patches fixing diagnostics >>> issues soon. >> >> Is this the kind of protracted passive-aggressive opinion you were looking for? > > I think my words above should be read in their own context, where > their true meaning can be fully appreciated. Then, one may be able to > appreciate that: > > * Saying "I don't think X is important, so I am against it and you > should spend your free time in Y." and "Of course, you are free to > spend your time in whatever you want." is not logically consistent. > The only choices offered are Y or nothing. > > * A real choice is offered by the paragraph above which changes the > statement to "I don't think X is important, and you should use spend > your free time on Y, but I am not against Y, so patches welcome." > > * In the paragraph above, you also seem to have missed the irony that > the example I chose as "not important" are small diagnostic issues, on > which I (among very very few) have spent significant effort in the > recent years. I was hoping that this irony would help the reader to > understand that the example is not meant to be taken seriously, and it > is only there to demonstrate the previous logical inconsistency. > > But my writing skills are still as poor as always, since it seems I am > having trouble making myself understood by some. So if you still > didn't get my point above, I am unable to explain myself in better > terms. Thus, let's forget about this and focus on the issue at hand. > > Cheers, > > Manuel. If you believe people miss your use of irony, then it is up to you to decide how to effectively get your points through effectively -- I am just not sure blaming people for missing your use of irony is effective. If this passive-aggressive strategy was the first or second time, I would not mind -- in fact, I was hoping you would get tired of it yourself. So, yes just to straight to the points. -- Gaby ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-13 8:27 ` Manuel López-Ibáñez 2012-04-13 8:41 ` Gabriel Dos Reis @ 2012-04-13 9:08 ` Jonathan Wakely 1 sibling, 0 replies; 35+ messages in thread From: Jonathan Wakely @ 2012-04-13 9:08 UTC (permalink / raw) To: Manuel López-Ibáñez Cc: Gabriel Dos Reis, Joe Buck, gcc Mailing List On 13 April 2012 09:27, Manuel López-Ibáñez wrote: > > I think my words above should be read in their own context, where > their true meaning can be fully appreciated. Then, one may be able to > appreciate that: > > * Saying "I don't think X is important, so I am against it and you > should spend your free time in Y." and "Of course, you are free to > spend your time in whatever you want." is not logically consistent. > The only choices offered are Y or nothing. Joe didn't say *you* should spend your time on Y, he suggested something he thought was more important, and he said *he'd* turn off colour output which is not the same as saying it shouldn't be added. > * A real choice is offered by the paragraph above which changes the > statement to "I don't think X is important, and you should use spend > your free time on Y, but I am not against Y, so patches welcome." That's how I read Joe's mail. There's no reason for this discussion to get heated, we're all working towards the same goal. > * In the paragraph above, you also seem to have missed the irony that > the example I chose as "not important" are small diagnostic issues, on > which I (among very very few) have spent significant effort in the > recent years. I was hoping that this irony would help the reader to > understand that the example is not meant to be taken seriously, and it > is only there to demonstrate the previous logical inconsistency. I'm afraid I missed that irony too, despite being well aware of all the great work you've done on those sort of diagnostics. I was about to reply saying the mixing up "." and "->" is not obscure at all. Irony and subtly don't work by email. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-13 1:40 ` Joe Buck 2012-04-13 2:27 ` Manuel López-Ibáñez @ 2012-04-13 8:59 ` Jonathan Wakely 2012-04-13 9:04 ` Gabriel Dos Reis 1 sibling, 1 reply; 35+ messages in thread From: Jonathan Wakely @ 2012-04-13 8:59 UTC (permalink / raw) To: Joe Buck Cc: Manuel López-Ibáñez, Gabriel Dos Reis, gcc Mailing List On 13 April 2012 02:40, Joe Buck wrote: > I'm not interested in color output, and would turn it off if it were > implemented (the escape sequences would just mess things up when capturing > compiler output in log files). There's no reason it would have to do that. Git does a great job of colouring output automatically when printing to a terminal but not when redirected to a file or pipe. It also automatically pipes output through a pager when it won't fit on the screen, and because it runs the pager internally it still knows the final output is a terminal and so outputs in colour. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-13 8:59 ` Jonathan Wakely @ 2012-04-13 9:04 ` Gabriel Dos Reis 2012-04-13 10:54 ` Manuel López-Ibáñez 0 siblings, 1 reply; 35+ messages in thread From: Gabriel Dos Reis @ 2012-04-13 9:04 UTC (permalink / raw) To: Jonathan Wakely Cc: Joe Buck, Manuel López-Ibáñez, gcc Mailing List On Fri, Apr 13, 2012 at 3:58 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote: > On 13 April 2012 02:40, Joe Buck wrote: >> I'm not interested in color output, and would turn it off if it were >> implemented (the escape sequences would just mess things up when capturing >> compiler output in log files). > > There's no reason it would have to do that. Git does a great job of > colouring output automatically when printing to a terminal but not > when redirected to a file or pipe. It also automatically pipes output > through a pager when it won't fit on the screen, and because it runs > the pager internally it still knows the final output is a terminal and > so outputs in colour. Yes, I do not think adding colored output is a challenge when done properly (e.g. checking that, for example, the output device supports ANSI control sequences even when it is a terminal, etc.) What I am concerned about is that the rush to have colored output may shadow the need to do it properly. -- Gaby ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-13 9:04 ` Gabriel Dos Reis @ 2012-04-13 10:54 ` Manuel López-Ibáñez 2012-04-13 11:36 ` Richard Guenther 0 siblings, 1 reply; 35+ messages in thread From: Manuel López-Ibáñez @ 2012-04-13 10:54 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: Jonathan Wakely, Joe Buck, gcc Mailing List On 13 April 2012 11:04, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote: > On Fri, Apr 13, 2012 at 3:58 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote: >> On 13 April 2012 02:40, Joe Buck wrote: >>> I'm not interested in color output, and would turn it off if it were >>> implemented (the escape sequences would just mess things up when capturing >>> compiler output in log files). >> >> There's no reason it would have to do that. Git does a great job of >> colouring output automatically when printing to a terminal but not >> when redirected to a file or pipe. It also automatically pipes output >> through a pager when it won't fit on the screen, and because it runs >> the pager internally it still knows the final output is a terminal and >> so outputs in colour. > > Yes, I do not think adding colored output is a challenge when done properly > (e.g. checking that, for example, the output device supports ANSI control > sequences even when it is a terminal, etc.) What I am concerned about is that > the rush to have colored output may shadow the need to do it properly. If a diagnostics IR is a hard requirement to add color support, then fine. Please, let me know once the diagnostics IR is implemented, and I may consider to try to add color support depending on how complex the IR code is. Please, also let me know if at some moment a simple implementation à la grep becomes acceptable. My excuses to all the readers for such a long thread to reach such a simple conclusion. I also want to apologize to Joe for misunderstanding his position. I don't have anything else to say on this subject. Cheers, Manuel. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-13 10:54 ` Manuel López-Ibáñez @ 2012-04-13 11:36 ` Richard Guenther 2012-04-13 13:40 ` Gabriel Dos Reis 0 siblings, 1 reply; 35+ messages in thread From: Richard Guenther @ 2012-04-13 11:36 UTC (permalink / raw) To: Manuel López-Ibáñez Cc: Gabriel Dos Reis, Jonathan Wakely, Joe Buck, gcc Mailing List On Fri, Apr 13, 2012 at 12:53 PM, Manuel López-Ibáñez <lopezibanez@gmail.com> wrote: > On 13 April 2012 11:04, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote: >> On Fri, Apr 13, 2012 at 3:58 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote: >>> On 13 April 2012 02:40, Joe Buck wrote: >>>> I'm not interested in color output, and would turn it off if it were >>>> implemented (the escape sequences would just mess things up when capturing >>>> compiler output in log files). >>> >>> There's no reason it would have to do that. Git does a great job of >>> colouring output automatically when printing to a terminal but not >>> when redirected to a file or pipe. It also automatically pipes output >>> through a pager when it won't fit on the screen, and because it runs >>> the pager internally it still knows the final output is a terminal and >>> so outputs in colour. >> >> Yes, I do not think adding colored output is a challenge when done properly >> (e.g. checking that, for example, the output device supports ANSI control >> sequences even when it is a terminal, etc.) What I am concerned about is that >> the rush to have colored output may shadow the need to do it properly. > > If a diagnostics IR is a hard requirement to add color support, then > fine. Please, let me know once the diagnostics IR is implemented, and > I may consider to try to add color support depending on how complex > the IR code is. > > Please, also let me know if at some moment a simple implementation à > la grep becomes acceptable. > > My excuses to all the readers for such a long thread to reach such a > simple conclusion. I also want to apologize to Joe for > misunderstanding his position. I don't have anything else to say on > this subject. I suppose we'd want to make the diagnostic machinery accessible by plugins so that IDEs could get an easier hand on things anyway. That way colorization could be achieved using a plugin, too. Richard. > Cheers, > > Manuel. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Updated GCC vs Clang diagnostics 2012-04-13 11:36 ` Richard Guenther @ 2012-04-13 13:40 ` Gabriel Dos Reis 0 siblings, 0 replies; 35+ messages in thread From: Gabriel Dos Reis @ 2012-04-13 13:40 UTC (permalink / raw) To: Richard Guenther Cc: Manuel López-Ibáñez, Jonathan Wakely, Joe Buck, gcc Mailing List On Fri, Apr 13, 2012 at 6:36 AM, Richard Guenther <richard.guenther@gmail.com> wrote: > I suppose we'd want to make the diagnostic machinery accessible by > plugins so that IDEs could get an easier hand on things anyway. That > way colorization could be achieved using a plugin, too. Indeed, we definitely want a standard way to get IDEs communicate with the diagnostic machinery; once that is appreciated, colorization becomes an almost trivial thing to do. -- Gaby ^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2012-04-14 6:58 UTC | newest] Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-04-12 21:50 Updated GCC vs Clang diagnostics Manuel López-Ibáñez 2012-04-12 21:54 ` Gabriel Dos Reis 2012-04-12 22:05 ` Manuel López-Ibáñez 2012-04-12 22:18 ` Lawrence Crowl 2012-04-13 5:12 ` Ian Lance Taylor 2012-04-13 5:58 ` Gabriel Dos Reis 2012-04-13 6:03 ` Jakub Jelinek 2012-04-13 6:07 ` Gabriel Dos Reis 2012-04-13 8:41 ` Manuel López-Ibáñez 2012-04-13 8:47 ` Gabriel Dos Reis 2012-04-13 9:00 ` Manuel López-Ibáñez 2012-04-13 9:09 ` Gabriel Dos Reis 2012-04-13 14:23 ` Jakub Jelinek 2012-04-13 15:23 ` Gabriel Dos Reis 2012-04-13 15:30 ` NightStrike 2012-04-13 15:36 ` Gabriel Dos Reis 2012-04-13 15:41 ` NightStrike 2012-04-13 15:53 ` Gabriel Dos Reis 2012-04-13 15:59 ` NightStrike 2012-04-13 16:02 ` Gabriel Dos Reis 2012-04-13 20:59 ` Lawrence Crowl 2012-04-14 6:58 ` Marc Glisse 2012-04-12 22:18 ` Gabriel Dos Reis 2012-04-12 22:43 ` Manuel López-Ibáñez 2012-04-13 1:40 ` Joe Buck 2012-04-13 2:27 ` Manuel López-Ibáñez 2012-04-13 3:37 ` Gabriel Dos Reis 2012-04-13 8:27 ` Manuel López-Ibáñez 2012-04-13 8:41 ` Gabriel Dos Reis 2012-04-13 9:08 ` Jonathan Wakely 2012-04-13 8:59 ` Jonathan Wakely 2012-04-13 9:04 ` Gabriel Dos Reis 2012-04-13 10:54 ` Manuel López-Ibáñez 2012-04-13 11:36 ` Richard Guenther 2012-04-13 13:40 ` Gabriel Dos Reis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).