develop how to install on mavericks

[René J.V. Bertin]

On Monday January 19 2015 15:36:07 Kevin Funk wrote:

Hi Kevin,

> @Rene: Can you tell us the state of your KDevelop on Mac work?
> What's been fixed? Where do we still have issues?

I think the only thing that I haven't been pushing to RB is the crash-on-exit-from-patchreview (and after committing), because it's such a hard nut to crack. (Or rather, it's so hard to find the remaining nut(s) to crack..)

I may now have found the underlying reason. As far as I know it's always been due to a sort of flaw in Qt's approach of combining ObjC objects and C++ objects. ObjC objects aren't deleted, they're released, and when the corresponding ref count reaches 0 they're disposed of ... when the time comes. In principle that's when the event loop they're part of exits, i.o.w. when no more events can be delivered to them.
Specifically, that theoretically means if you wrap an ObjC class in a C++ class, you should (a priori) never call the C++ dtor (and thus only use instances allocated with new) but use a method that releases the ObjC object ... and the ObjC dealloc method should then invoke the C++ dtor. Something contrived like that.
If you fail to do that, there's a risk that deleting an object (that corresponds to a UI element) is done when events are still pending, or that the deletion itself generates events that are delivered to an object (not necessarily *the* object) that's already been deleted. I'm pretty sure that's what causes the crash when I click the "Finish Review" button and haven't closed all open documents in the view manually. The crash happens something like 2 out of 5 times (and usually when it suits you least ;)), but it's always in the same location, handling a mouse button release event. Maybe it's simply that the patch review is closed when you press on the finish button, and the inevitable release event delivered to a deleted button widget. Confirming that will be a lot of work and probably require a full debug build (Qt & KDE).

The fix in Qt I'm testing now is in the release mouse button handler, where it tries to find the widget for the event. There's a comment stating that in the relevant case no hint should be given to a nativewidget, and yet a nativewidget pointer is handed off to the lookup function. Which promptly tries to use a stale pointer which can only be that nativewidget pointer. So I've recompiled that module passing in NULL instead of nativewidget. Since then I haven't seen this particular crash despite trying hard to provoke one (like closing a patch review while a re-parse was going on). But I've thought before to have found the culprit so I'm holding my breath. Or not, actually :)

Other issues are crashing when there are too many open files, not a specific OS X issue I think. A good way to hit that one is to load 2 calligra projects (say, a virgin git checkout and a working copy with local changes) in a single session.

The *big* issues on OS X are of course the lack of support for lldb and for Objective C. Both are a bit beyond my comfort zone to start working on (and do it properly). I've "hacked in" a very basic form of support for Objective C that simple accepts .m (ObjC) files as regular C and .mm (ObjC++) files as C++. That doesn't give support for the OO aspects of the language, but at least it provides minimal parsing and integration with API documentation, quick access to function definitions etc.

You asked me to tell more, no? :)

> Would be nice to publicize our KDevelop on Mac work a bit, maybe this could be 
> your first KDE blog post? :)

Ouch, I'm really not a blogging person, and publishing (as in writing about) my own work has always been one of my weak points...
But I appreciate the suggestion :)

R.