KDE/kdelibs/kate/buffer

[Milian Wolff]

On Sunday 11 April 2010 11:50:15 Christoph Cullmann wrote:
> Niko Sams wrote:
> > On Sat, Apr 10, 2010 at 10:39, Christoph Cullmann <cullmann at absint.de> 
wrote:
> >> Perhaps (for the future), you should take a look how qtcreator does the
> >> parsing, after the last talks to Roberto, it seems that more intelligent
> >> it might be good idea to fork that parser or at least steal some (LGPL)
> >> ideas.
> > 
> > Forget that, that's not an option.
> > 
> > However what imho could be done is porting KDevelop to the new Buffer and
> > Cursor stuff. (But I have no idea what needs to be changed to do that)
> > I think we should:
> > - as a short term goal make kate and kdevelop as stable as possible
> > with the current technology
> > - as a mid term goal work out a plan what could be changed in which way
> > - as a long term goal have all all non-optimal code replaced by something
> > better
> > 
> > Unfortunately we are currently we are stuck at step 1, because david
> > and hamish (the only
> > ones who have in depth knowledge about what kdevelop does and needs) are
> > short of time.
> > 
> > I think we can solve this issue together! No need to kill each other :D
> 
> I like the idea of cooperation, but the current situation is not
> acceptable:
> 
> Nobody can do changes perfectly correct in kate part without breaking
> kdevelop and then getting constant complaints from either the kdevelop
> devs or users...
> To be honest, I don't like that.
> I designed the new buffer in a time-frame of some weeks, it got unit
> tests from the start, it handles encodings lot better and it is faster...
> But what do I get: complaints and insults
> I asked for input on kdevelop list, nothing, and now the whining is
> great...

After sleeping for long hours, I hope I cooled a bit down. I want to apologize 
me, since it was probably me who did the insulting comment. Christoph, I hope 
you know that I admire your coding-foo and that I don't want to insult you or 
anything. We had a good time at the meeting, hope this wasn't the last one.

Anyways, regarding the above problem: I think what would be optimal would be 
unit tests in Kate that mirror the usage in KDevelop. I think it will be lots 
of work but I hope that I can do at least a bit of that. This way you wouldn't 
have to use KDevelop to find problems. And it would/could also show us where 
we misuse the API and you could help us maybe to fix it.

> I have not reverted milian's commit, but I won't tolerate any more
> invasive stuff.
> 
> If kdevelop gets crashs => lock your smart mutex in more places.
> Don't patch KatePart to hide your faults...
> The smart mutex will stay there, at least for KDE 4.5

I think that I acted prematurely since I assumed that - since it works with 
4.4 - it was a regression in 4.5. If the old code was never threadsafe and 
this simply shows a nother misuse in KDevelop, I'm sorry and I'll try to hunt 
down the place and fix it.

Yet could you tell me:

Does this mean, that one has to lock the SmartRange interface _always_ when 
one accesses it's API? Look at the backtrace in this bug:
https://bugs.kde.org/show_bug.cgi?id=233823

It accesses the smartrange in 
KTextEditor::CodeCompletionModelControllerInterface::updateCompletionRange, 
should it be locked there?
 
> What would help me a lot:
> Could I get a list of the interface functions KDevelop uses of the smart
> range interface?
> I would then deprecate any other and kill the implementation, that the
> Smart* mess at least not spreads further.
> 
> Btw., if nobody steps up to provide a list, I can do my own, by grep -r
> for each interface function.
> Each I don't find will get a deprecated marker and it's implementation
> will do kFatal.

I'll see what I can do.

Bye, have a nice weekend, hope I didn't spoil it for you :-/
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100411/03c3f49c/attachment.sig>