| RE: [cdt-dev] Error parsers, slowness and cygwin |
|
Not that I work there any more, but I know the TI compilers did this too.
Our Intel compiler will use both stdout and stderr so eliminating stdout would be an issue for us. Bill Sent: Thursday, January 29, 2009 5:12 PM To: CDT General developers list. Subject: RE: [cdt-dev] Error parsers, slowness and cygwin But is that guaranteed to be true, i.e., that compile errors never get spit out to stdout? I have a foggy recollection that there was a compiler out there that used stdout. But maybe that's just revisionist history. Anyone else seen one? Doug. Sent: Thursday, January 29, 2009 5:08 PM To: CDT General developers list. Subject: Re: [cdt-dev] Error parsers, slowness and cygwin I think we can improve situation with any error parser if we feed it with stderr output only. All errors (the only task of any error parser is to extract errors) are located in stderr, and in average case stderr much smaller than stdout, which means that parser does a lot of unnecessary work. There is one exception about stdout: it has to provide information about current working directory. But this is just a small part of work error parsers do now. Alex. On 29/01/2009 2:13 PM, Andrew Gvozdev wrote: On Thu, Jan 29, 2009 at 1:37 PM, Elena Laskavaia <elaskavaia@xxxxxxx> wrote: We can have cygwin toolchain, but it does not apply to error parsers... Should we create cygwin gcc error parser? Then we need also cygwin linker error parser, cygwin make error parser and assembler? I think that the right solution would be user-configurable Regex error parser and let the users loose. Andrew Schaefer, Doug wrote:
right plug-in architecture to support it. This issue has been brought up numerous times and it would be great to clean this up. As the quasi-owner of CDT for Windows, I'll take that action and try to work it into my schedule. But I'd like to hear others opinions on that before I get to far. Cheers, Doug. -----Original Message----- From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Elena Laskavaia Sent: Thursday, January 29, 2009 9:52 AM To: CDT General developers list. Subject: Re: [cdt-dev] Error parsers, slowness and cygwin In this case it can resolve it right when user select this action, saves a lot of time during parsing... Btw when this command was added? I think eclipse right now is smart enough to open external location itself. At least it works from other tools. Andrew Gvozdev wrote: I found out what it is. It is well hidden but actually very useful. In Problems view - do right-click on the problem marker and choose "Open external location". If the file exists on disk you would be able to open it - even if it is not in the project and even if outside of the workspace. This option works specifically when the file was not found in the workspace. Resolving cygwin path is an extra nicety here. Thanks for the suggestion, I was considering submitting a patch or two in this area. Andrew On Thu, Jan 29, 2009 at 9:29 AM, Elena Laskavaia <elaskavaia@xxxxxxx <mailto:elaskavaia@xxxxxxx>> wrote: I don't think anybody knows. If you know how to optimize it just do it (submit a patch). I somebody would scream then we can come up with something else, otherwise we can commit it in 6.0 and see if any user would complain. One of the options to create a user preference to enable cygpath resolver, otherwise do simple substitution like you suggested earlier. Andrew Gvozdev wrote: Hi, Does anybody know the purpose of ProblemMarkerInfo.externalPath? Related to ICModelMarker.C_MODEL_MARKER_EXTERNAL_LOCATION. CDT takes some care to enter it in a few places. This field is not being displayed in Problems view or Markers view. Doubleclick on such entry (pointing outside of workspace) has no effect. Anyone knows? There is another call to CygPath and consequent invocation of external program cygpath in ErrorPattern (inside getLocation call). Again, this is called for each line where it cannot resolve file name in order to populate the field "externalPath". Is it important to populate it with translated path or it is possible to relax this requirement? Andrew On Thu, Jan 22, 2009 at 11:38 AM, Andrew Gvozdev <angvoz.dev@xxxxxxxxx <mailto:angvoz.dev@xxxxxxxxx> <mailto:angvoz.dev@xxxxxxxxx <mailto:angvoz.dev@xxxxxxxxx>>> wrote: I refer to ErrorParserManager, findFilePath(String filePath). On Thu, Jan 22, 2009 at 11:04 AM, Elena Laskavaia <elaskavaia@xxxxxxx <mailto:elaskavaia@xxxxxxx> <mailto:elaskavaia@xxxxxxx <mailto:elaskavaia@xxxxxxx>>> wrote: Is this error parser? Or it is part of the build? Andrew Gvozdev wrote: I was looking at the issue reported in eclipse.tools.cdt post <http://www.eclipse.org/newsportal/article.php?id=17892&group= eclipse.tools.cdt#17892 <http://www.eclipse.org/newsportal/article.php?id=17892&group=eclipse. tools.cdt#17892> <http://www.eclipse.org/newsportal/article.php?id=17892&group= eclipse.tools.cdt#17892 <http://www.eclipse.org/newsportal/article.php?id=17892&group= eclipse.tools.cdt#17892>>> and how cygwin paths are handling in the code. Cygwin utility "cygpath" is used to translate cygwin path to windows, class org.eclipse.cdt.utils.CygPath. While I have no doubt about its correctness, it appears that running separate external program for each line trying to map (not yet resolved) filename to cygwin path is a major reason for slowness of output parsing. A short test of parsing with and without the translation attempt shows slowness of x100 times. Is this the best way of doing it? We use eclipse to compile projects remotely and some of them are big enough to produce thousands of warnings where the files are not necessarily present on disk. Is it advisable to replace using of the utility cygpath with a function which would do something like a simple translation from "/cygwin/c/" to "C:/" or so? Perhaps there is already such a function out there somewhere? Andrew ---------------------------------------------------------------------- -- _______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx> <mailto:cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx>> https://dev.eclipse.org/mailman/listinfo/cdt-dev _______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx> <mailto:cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx>> https://dev.eclipse.org/mailman/listinfo/cdt-dev ---------------------------------------------------------------------- -- _______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx> https://dev.eclipse.org/mailman/listinfo/cdt-dev _______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx> https://dev.eclipse.org/mailman/listinfo/cdt-dev ---------------------------------------------------------------------- -- _______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev _______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev _______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev _______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev _______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev _______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev |
