KDevelop 4.3 final TODO

[Andreas Pakulat]

On 15.02.12 10:52:17, Milian Wolff wrote:
> Andreas Pakulat, 15.02.2012:
> > On 15.02.12 02:45:30, Aleix Pol wrote:
> > > On Tue, Feb 14, 2012 at 2:22 PM, Milian Wolff <mail at milianw.de> wrote:
> > > > Hey all!
> > > > 
> > > > Here's a list of stuff that needs to be done in time for the 4.3 final
> > > > release. I've added some names here and there for people who I think
> > > > could look into it. Of course anyone is invited to help :)
> > > > 
> > > > no "do you want to save?" dialog when closing unsaved document:
> > > > https://bugs.kde.org/show_bug.cgi?id=291091
> > > > -> David, could you look into that? I think it's workingset related...
> > > > 
> > > > crash when committing to SVN with blank commit message:
> > > > https://bugs.kde.org/show_bug.cgi?id=281620
> > > > -> Aleix, could you maybe investigate this?
> > > > 
> > > > endless loop in CppClassType::toString (e.g. with Eigen or Boost code):
> > > > https://bugs.kde.org/show_bug.cgi?id=269352
> > > > -> I'll try to fix/workaround this, apparently
> > > > https://bugs.kde.org/show_bug.cgi?id=287380 contains a small set of
> > > > files to reproduce the issue
> > > > 
> > > > save/restore editor bookmarks:
> > > > https://bugs.kde.org/show_bug.cgi?id=230862
> > > > Anyone up for this? Would be very helpful I think
> > > > 
> > > > Furthermore we *really* need to go through all these great patches on
> > > > reviewboard - some of them are there for far too long! Maybe not for
> > > > 4.3 but I will work on them after my classes finish.
> > > > 
> > > > Thanks and 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
> > > 
> > > just tried the svn one, couldn't reproduce, i closed the bug... maybe
> > > a svncpp thing?
> > 
> > A useful backtrace would be needed for that one to do anything, the one
> > posted is more or less useless since the crash occurs in Qt which is
> > rather unrealistic.
> 
> These kind of crashes we have had a lot of times when emitResult was emitted 
> twice. Most notably in the VCS plugins we've had quite a few of such issues.

Ah, yeah. Though that "should never happen" of course :) Hmm, I wonder
if the order of queued-connections is guaranteed or not, since if its
not that would indeed be a problem as ThreadWeaver::Job emits failed and
done in the case of a failed job. And the connections for the signals to
the corresponding slots are queued, so if the order is twisted I can see
how the internalJobDone slot might emit the result and then later
internalJobFailed would try that again.

Anybody know this detail about QueuedConnection? I'm assuming that the
order of the signals is well-defined, i.e. the queueing is also
well-defined. If thats not the case the code needs to be changed to only
connect to the done signal and do the logic for failed in that slot.

Andreas