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
On Thu, Jan 29, 2009 at 9:51 AM, Elena Laskavaia <elaskavaia@xxxxxxx> wrote:
In this case it can resolve it right when user select this action, saves a lot of time during parsing...
 
Good point. I was considering that as well as an option to convert the path earlier and pass already converted one to all FindFile()  methods. However this will affect some of public methods used by 3-rd party error parsers, particularly in respect of cygwin path handling. Maybe it can be viable option to deprecate some of them and recommend extending error parsers from AbstractErrorParser. It needs some more thinking. Let me see where the code will want to lead us.


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.
 
See bug 151005. I am not sure how to make eclipse to open that external location itself. Any pointers would be useful. Are you saying that it is enough to provide external location in Path column?

Thanks,
Andrew


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

Back to the top