|This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106567/|
On October 5th, 2012, 8:27 p.m., Michel Ludwig wrote:Ok, this looks very good already. I just have have a few suggestions for improving the patch even more. Sorry, but I don't see how 'cleanStruct()' could help avoid any race conditions. Could you elaborate on that?
On October 5th, 2012, 10:17 p.m., Eugene Shalygin wrote:As well as I remember, I came to understanding while I was analyzing why do I see absence of the master documents when I have many projects openend. What happened is that same info object has been scheduled for parcing twice or more. I do not remember, unfortunately, what was leading to that. Some of the projects are sharing the same files, if that can play role. Anyway, in that case the second scheduling cleans up structure that was built in result of the first parsing, and this cleaned object is used for project tree building or something like that. And I saw incorrect project trees, empty bibliography completion lists and so on. Then I moved cleaning into the install* methods, and that, as I thought, should lead to cleaning in the same thread that builds project tree, and the problem disappeared. And I thought that it is more logical to clean structure right before populating with the new one. So I would leave it even if double parsing will not (and shall not) happen.
On October 6th, 2012, 8:37 a.m., Michel Ludwig wrote:Hhmmm, I think if this problem still occurs it must have been caused by something else as all the code in TextInfo and the structure view is executed in the GUI thread, which means that no race conditions can occur (the output parser is passed to the event loop of the GUI thread using a blocking signal/slot connection, see 'KileDocument::Manager::handleParsingComplete' So, at the places where 'cleanStruct' was called it had no effect as it was followed immediately by 'operator=' and everything GUI-related runs in the GUI thread only.
On October 6th, 2012, 1:31 p.m., Eugene Shalygin wrote:I disagree. When we call m_ki->structureWidget()->update(itemInfo, true) from projectOpenItem(), it was cleaning structure immediately, and then was scheduling the parsing of the item. And if parsing queue contains many items, result of parsing of some other item uses clean structure of this item. And this happens if the same items is scheduled for parcing twice.
On October 6th, 2012, 3:46 p.m., Michel Ludwig wrote:Ok, but that's a different issue. Your fix was right for the reason that you had emptied 'Info::cleanStruct()'.
On October 6th, 2012, 3:56 p.m., Eugene Shalygin wrote:Pardon me, but cleanStruct() is what I've added. Before this code was in updateStruct() and causing above described problem. So, despite I did not understand your last comment completely, I think that main iea was that we leave clearStruct()?
No, that's exactly the point. It is unnecessary to clear any information before the parsing takes place.
On October 5th, 2012, 8:27 p.m., Michel Ludwig wrote:
src/documentinfo.cpp (Diff revision 4) const long* TextInfo::getStatistics(KTextEditor::View *view) 542 return KUrl(); 551 return Info::url();I don't know how much work this will be but could you try to remove the 'Info::url()' method completely? It just causes too many problems, for example when files are renamed. It should be sufficient to use 'urlFor' from the doc manager instead.
On October 5th, 2012, 10:17 p.m., Eugene Shalygin wrote:Well, I've tried. Indeed, it leads to many changes. Some of them are trivial, some are not. For example, Info::lastModifiedFile() uses url(). Where can I get doc manger from in that function? Perhaps, it would be better if I remove introduced by patch changes in Info constructors, and switch to the using of doc manager in the parser thread, then you accept this patch ;) and further clean up can be done independently?
On October 6th, 2012, 8:36 a.m., Michel Ludwig wrote:Ok, let's do it this way.
On October 6th, 2012, 1:31 p.m., Eugene Shalygin wrote:Ups... Manager::urlFor(TextInfo* textInfo) calls Manager::itemFor(Info *docinfo, KileProject *project /*=0*/) which in turn calls Manager::itemFor(const KUrl &url, KileProject *project /*=0L*/) with docinfo->url() Thus, by removing url from Info we destroy this chain.
On October 6th, 2012, 3:46 p.m., Michel Ludwig wrote:Ok, let's wait with this for now then. The whole thing is a mess anyway and needs to be cleaned up! Could you just remove the additional URL parameter that you have added from the patch?
On October 6th, 2012, 3:56 p.m., Eugene Shalygin wrote:Sorry, I can not :) If the parser does not know the url, it can not deliver the results to a proper destination. That is why I've started all this work with adding url to Info objects, because without that, the url exists only for Infos with documents. So the idea was to provide information to parser without loading KateDocument. This includes url and file contents.
Calling 'KileDocument::Manager::urlFor' in 'DocumentParserThread::addDocument' should now work for project items as well.
On October 5th, 2012, 8:27 p.m., Michel Ludwig wrote:
src/kiledocmanager.cpp (Diff revision 4) void Manager::projectOpenItem(KileProjectItem *item, bool openProjectItemViews) 1549 //oops, doc apparently was open while the project settings wants it closed, don't trash it, update openState instead It looks like this is still needed somewhere...
On October 5th, 2012, 10:17 p.m., Eugene Shalygin wrote:Can not understand how that is possible: we create view now only if item->isOpen() == true, then why should we check it again? The same applies to the trashDoc() call, doesn't it?
On October 6th, 2012, 3:56 p.m., Eugene Shalygin wrote:Any comment about this?
That seems fine.
On October 5th, 2012, 5:33 p.m., Eugene Shalygin wrote:
Review request for Kile.
By Eugene Shalygin.
Updated Oct. 5, 2012, 5:33 p.m.