Python documentation

[Sven Brauch]

Hi,

> You could save the time needed to load python and especially to load
> the python modules.
Python caches them very well. It won't take any relevant amount of time when
loading modules for the second time (you can easily try that out in a
terminal). :)

I'll have a look at the DUChain ItemRepository thingy, thanks for the hint.
But I cannot imagine why using SQLite should be so difficult or "fat"...
it's part of most Qt distributions, isn't it? At least for me, it was
available automatically.
And I imagined loading and storing things would be like... 2 lines, where do
you see a possibility for thousands of lines of code there? If the file ever
gets corrupted (which I don't expect to happen, will it?) I can easily just
delete it. It's just a cache.
Plus, a "real" (sorry :) database would be way more flexible in terms of
searching, distributing with predefined data, exporting/importing, ...

But i'll definitely have a look at the DUChain method.

Thanks,
Sven

2010/11/17 David Nolden <zwabel at googlemail.com>

> 2010/11/17 Sven Brauch <svenbrauch at googlemail.com>:
> > Hi!
> >
> > Thank you very much for your answers.
> >
> > Well David, it's not only about speed; I also consider it extremely
> > inelegant to waste CPU time for virtually nothing. There's really no
> reason
> > to generate documentation for a module 20.000 times a day when there's no
> > chance it'll ever change... plus, progress indicators are very nice, but
> > being fast enough to leave them out is always nicer. :) Also, for some
> > modules like QtGui, it takes about 30 seconds to generate documentation;
> of
> > course, you don't want to show all that in a tooltip, but maybe the
> > sub-packages listed there, and being able to load those from a databse is
> > much nicer than yet another pydoc hack. But I agree, waiting for 0.5
> seconds
>
> Well, how do you fill the database? It will also require a kind of
> pydoc, so the question is just: Is it better to add 50 lines of code
> in the pydoc plugin, or is it better to add a thousand of lines of
> code to KDevelop, plus an additional "fat" dependency, which is
> SQLite.
>
> With the database, you will have the typical load of work like always
> with databases. Where to store it? What about multiple running
> instances? Is the database corrupted? Is the entry you're requesting
> still current? And then bugs, bugs bugs. I have experience with this
> because we used a separate database in KDevelop3 for the code model.
>
> We already maintain a database, which is the duchain storage, so if
> you consider a database as a cache, then it should be that one. It is
> much more efficient than any SQL database, and already has perfect
> integration with KDevelop, so you won't have to worry about any of the
> points above (except for the "Is the entry still current"). You can
> easily use a duchain ItemRepository as a database, as is done in many
> components. Take a look at kdevplatform/language/duchain/uses.h /
> uses.cpp, there you have a fully working simple single-key database.
> You just have to copy it over, change the names, and change the data
> types. For example, you could map from IndexedQualifiedIdentifier to
> any set of Indexed.... types you add to the "UsesItem" successor, plus
> a dynamic list of the item type you add through the APPENDED_LIST_...
> stuff.
>
> > I considered keeping the python scripts running for the parser, too, but
> I
> > dismissed it because it's simply not worth it. The only thing you could
> save
> > with that is time needed for startup; which is actually only needed once
> > because python caches stuff very well (and also keeps semi-compiled
> versions
> > of the script around, so it's not even reparsed).
>
> You could save the time needed to load python and especially to load
> the python modules. I don't know where most of the time is wasted
> though, so maybe this wouldn't help much.
>
> Greetings, David
>
> --
> 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/20101118/9c85419b/attachment.html>