DU-chain classes questions ...

[Sandro Andrade]

>
> > 2) Looking at contextbrowser plugin source code, it seems that I must
> > always use IndexedDeclaration
> > instead of Declaration for those data which are going to be used across
> > DU-Chain locks and probably defined as member attributes. Is this correct
> ?
> > If yes, I still need to check if IndexedDeclaration::data() return a
> > non-zero declaration, right ?
>
> I think that it makes sense in this area of usage. It's not slow if the
> declaration is still in memory. If it's not, it's tried to load it from
> disk.
> But since anything could have happened in the meantime, e.g. the
> declaration
> could have been removed, you still have to check whether the data is still
> valid.
>
>
Ok, updating plugin to use Indexed*.


> > 6) If I select a new symbol while collecting uses, apparently the collect
> > is paused and resumed from the last point if first symbol is selected
> > again. The pause point can be restored from m_waitForUpdate and
> > m_updateReady QSets in UsesCollector, but the question is: are the
> > remaining updateContextForUrl calls cancelled when a new symbol is
> > selected ? Or do they run to completion ?
>
> They probably run until completion. Just a guess though. But I mean you
> don't
> have any API to abortJobForUrl or anything like that. And it shouldn't
> matter
> that much, since most of the time you'll switch symbols in a single
> context.
> If you jump to another context, it will get reparsed anyways for the
> editor,
> and there'll be only one job for that in the BackgroundParser.
>
>
I think in controlflowgraph plugin we have a slightly different requirement
because
I need to collect all uses of the current symbol and that likely spans to
several
(including not-in-editor) files.


> Did you experience problems where too many (obsolete) jobs are still
> running?
> I never encountered that problem (at least not knowingly).
>

Yes, as I generate a new graph (including uses - incoming arcs) whenever
cursor enters a
new definition/declaration there could be too much obsolete jobs if user do
it in a higher frequency.
It would be like calling "Show uses" from contextbrowser several times.

For contextbrowser that wouldn't be so injurious because just signal
processing would be required.
In controlflowgraph plugin the control flow generation (outcome arcs) is
performed in background
so I wouldn't like to spawn inadvertently too many threads.

One possible solution might be to disable automatic generation for graphs
using more than two or three
call levels. Any suggestion ?

Thanks,
Sandro


> Bye
> --
> Milian Wolff
> mail at milianw.de
> http://milianw.de
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100415/3cfbf560/attachment.html>