Fwd: why is a source file parsed when being closed ? (was: Re: my first post)

[Tommaso Massimi]

I have just seen I sent the following mail only to Alexander,
so I'm resending it to the list.

best regards
Tommaso

On 12/20/05, Tommaso Massimi <tmassimi at gmail.com> wrote:
>
>
> On 12/15/05, Alexander Neundorf <neundorf at kde.org> wrote:
> >
> > On Thursday 15 December 2005 00:20, Tommaso Massimi wrote:
> > > On 12/7/05, Alexander Neundorf <neundorf at kde.org> wrote:
> > ...
> > > > So this might be the reason too why closing a file is so slow in
> > kdevelop
> > > > ?
> > > >
> > > > void ProblemReporter::closedFile(const KURL &fileName)
> > > > {
> > > >    QValueList<Problem> problems =
> > > > m_cppSupport->backgroundParser()->problems( fileName.path() , true ,
> > > > true);
> > > > }
> > > >
> > > > It seems this is done in order to remove the problems reported from
> > this
> > > > file
> > > > from the problem view if the file is closed.
> > > > I just tried with the call to problems() commented out, the FIXME
> > from
> > > > the closed file still disappears from the problem view. So this
> > seems not
> > > > to be
> > > > the reason.
> > >
> > > Anybody else knows why problems() is called there ?
> >
> > ...
> > > void BackgroundParser::addFile( const QString& fileName, bool
> > readFromDisk
> > > ) {
> > >         QString fn = deepCopy( fileName );
> > >
> > >         bool added = false;
> > >         if ( !m_fileList->contains( fn ) )
> > >         {
> > >                 m_fileList->push_back( fn, readFromDisk );
> > >                 added = true;
> > >         }
> > >
> > >         if ( added )
> > >                 m_canParse.wakeAll();
> > > }
> > >
> > > It seems it is only checking for duplicate files
> > > (I hope m_fileList->contains( fn ) doesn't implement strange
> > behavoiur...).
>
>
> I have to correct myself:  this function is not involved at all
> when a file not included in the project is opened.
>
>
> > before add a file it could be possible to implement some more checks
> > like:
> > >
> > > - file size:
> > > probably a big file is not a source file:
> > > my troubles are coming out when I check the .dmp file generated by
> > objdump
> > > (I'm developing an embedded application,
> > > so quite often I have to check the assembler code stored in a big
> > file)
> > > It could be possible to add some limit to the size of the file (1
> > MByte?).
> >
> > Hmm, not sure.
> >
> > > - file type
> >
> > I think that's the way to go. Can you come up with a patch ?
>
>
> a sort  of patch:
>
> void ProblemReporter::closedFile(const KURL &fileName)
> {
>     KMimeType::Ptr res = KMimeType::findByFileContent( fileName.path() );
>     if (res && res->isValid())
>     {
>         QString mimetype = res->name();
>         if ((mimetype == "text/x-chdr"  ) ||
>             (mimetype == "text/x-c++hdr") ||
>             (mimetype == "text/x-csrc"  ) ||
>             (mimetype == "text/x-c++src"))
>         {
>             QValueList<Problem> problems =
> m_cppSupport->backgroundParser()->problems( fileName.path() , true ,
> true);
>         }
>     }
> }
>
> these few lines were enough to solve my problem.
> Please note that this means that files not included into the current
> project are not parsed when opened,
> but are parsed when they are going to be closed.
>
> While this would help for non-source files, closing a file is still very
> > slow.
>
>
>  yes, I made a test with these line applied; the trouble seems still
> coming from the same line
>
> QValueList<Problem> problems = m_cppSupport->backgroundParser()->problems(
> fileName.path() , true , true);
>
> It seems that if a file is closed before it's background-parsing is ended,
>
> the file is parsed during its closure; but I'm not sure about that,
> I well know kdevelop is a big project and I can't have understood it
> in the few hours I have spent debugging it.
>
>
> Bye
> > Alex
> > --
>
>
> Bye
> Tommaso
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20051226/f3025b39/attachment.html>