Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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.


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.


Schaefer, Doug wrote:
>From my perspective, I'm in favor of completely removing cygwin support
from the CDT core. We should be treating cygwin as a toolchain with the
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.

-----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.

On Thu, Jan 29, 2009 at 9:29 AM, Elena Laskavaia
<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:


       Does anybody know the purpose of
       Related to
       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
       path or it is possible to relax this requirement?


       On Thu, Jan 22, 2009 at 11:38 AM, Andrew Gvozdev
       < <>
<>>> 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>>> wrote:
              Is this error parser? Or it is part of the build?

              Andrew Gvozdev wrote:

                  I was looking at the issue reported in
                  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
                  no doubt about its correctness, it
appears that running
                  separate external program for each line
trying to map
                  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?



                  cdt-dev mailing list
                  cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx>
       <mailto:cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx>>


              cdt-dev mailing list
              cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx>
       <mailto:cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx>>



       cdt-dev mailing list
       cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx>

   cdt-dev mailing list
   cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx>


cdt-dev mailing list
cdt-dev mailing list

cdt-dev mailing list
cdt-dev mailing list

_______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx

Back to the top