Shocked by the title? So I am.

Would you like to see Qt supported on this platform? Just two days ago the answer was like "But it's close to impossible".
Now with NDK 1.6 the "little robot" OS opens more to C/C++ native code. I am eager to read some analysis on the topic.

Well it is officially the end of GSoC. This update brings you the wrap-up of what happened in the project, what got done, what didn't get done, and what is next on the wonderful world of automated code Refactoring in C++.

What Got Done

The week before last into GSoC, and this is how things are:

Sadly I had very little time to work on the project last week because I had to be out of town for the most part. Despite of this setback though, there was a significant improvement, which is the user review widget. What this means is: Screenshot time!

Here is another update on the progress of the KDevelop refactoring support SoC.

Last week was pretty hectic for me. Sadly I didn't have as much time as I would have liked to work on the project, and even less to blog about it. However with this update I will list things that have happened these past two weeks. Among things that happened:

Another week into SoC, and status update for anyone mildly interested

So what has happened in the last week? Well I worked in the KDE hacking rooms at Akademy .

So what's the holdup? Where is all the cool stuff you promised?

Hello everybody, I should introduce myself first: I am Ramón Zarazúa, I am a GSOC student working on C++ refacoring support for KDevelop. I am very pleased to be contributing to KDE and the community, and want to make us the best we can be!

State of things:
To be honest things are not going good For lots of different reasons progress has been stagnant on the project. There have been changes in the plan, and now focus will switch to do refactoring on a more textual level (instead of the initially planned purely conceptual level). I am currently working on the refactor framework, and a refactoring concept to "make a class implementation private" or as it is known in QT and KDE: the 'd' pointer.

Yes, sounds strange. Why should i did it ?
Well, first is known among the distros that qt-creator in first release is not the most friendly to packaging.
Not only beacuse qmake, but because some distros rely on things like splitted packages or 32/64 bits coexistent libs and plugins.
Second, was quite a challenge for me do this, because i need to learn some new tricks ( thanks dfaure for automoc4 help ).
Third, dressing my packager hat, i would love to see qt-creator been in the main Mandriva distro, compliant with our policies, and been adopted as well i expect for kdevelop4 when be released. Qt Creator is one of the amazing IDE's around and i thought that worth the effort to give some love in buildsystem to have it in a full Mandriva way, including our flags and standard cmake build.
During the process, i could manage to fix all bugs open in our bugzilla about packaging, and at same time enable the "most wanted" feature here, the designer plugin, which for some reason was not enabled in our qmake previous compilation.

To summarize what i did:
- Write whole cmake buildsystem
- Backported icons and mime and desktop files from upstream binary Qt Software package ( as same as Kubuntu did )
- Make the plugin standard dir be the Qt plugins standard dir, which make possible have 64 and 32 bits plugins instalable
- Make qt-creator easily compliant to /usr linux install
- Splitted libraries in subpackages as usual, and installed in our standard libdir instead of a subdir
- Reenabled designer plugin.

So, now i'm totally happy with all the changes, barely minimal in code ( most moc include additions and add standard Qt plugin path ).

For who is interested, our svn repository is Qt Creator Package Repos
For who wants to try our marvelous distro, today we will be releasing RC1 from Mandriva 2009 Spring, so you will be able to see how hard we are working to make a better distro for you...

So, the last two days I've been concentrating on introducing locking into the definition-use chain which I've been writing for KDevelop. I've taken quite a coarse-grained approach, with one lock for each document's chain, and with separate object local locks each time that an object can reference another object that is on a different chain.

It took several hours yesterday to complete the basic scheme where the chains weren't referencing each other. I didn't even realise they weren't referencing each other until later, when I recognised that a speedup commit that Matt had contributed had removed some of my code which made this happen before. In fact, it was fortunate, because it allowed me to develop the code in two steps.

So today I've been trying to make the chains play nice while referencing each other. The going hasn't been easy. First I was confronted with some more unprotected accesses - these aren't too hard to fix, thanks to an extensive assert system that I've put in place to detect when locks aren't being held that should be. Second, there was a deadlock in the code completion code which took a little while to figure out - note to anyone using QReadWriteLock: if you ask for a second read lock while someone else is asking for a write lock, you'll deadlock. Third, I hit a race inside katepart where text edits and smart range updates could occur simultaneously, which was also bad. That wasn't too hard to fix. Now, I'm cleaning up some access of deleted memory with the help of Valgrind.

I'm not sure that this code can even be made to be reliable, given its complexity. Adam Treat pointed me at an article recently, The Problem with Threads, and I'm starting to agree. Having multithreaded definition-use parsing and manipulation would be a good goal, but perhaps not more than being stable. So, I plan to give it some time in svn to see if it can be made reliable enough for kdevelop's purposes.

In other news, my latest hardware purchase arrived today - a Dell 30" flat panel screen. At 2560x1600, when you combine it with another large screen (I have 2x 24" already, at 1920x1200), my graphics card can't handle them in xinerama mode, as the virtual screen size maximum is 4096x4096. So, I've been trying it in separate screen mode, but it's not a particularly pleasant setup - problems including the loss of ability to alt-tab between screens, kicker popping up on the other screen to the one that you're working on (and crashing), and of course not being able to drag apps between screens. Anyway, the 30" screen is excellent quality. I took a photo but it doesn't do it justice at night time...

Firstly, thanks to clee for adding me to the Planet. When I left Trysil I planned to blog more often, and now you too can read about it

So, for the last 2 weeks I've been on annual leave, and have had the fortune to be "on a roll" with my coding. I'm currently concentrating on KDevelop 4. We're privileged to have a new parser framework by Roberto Raggi and Jakob Petsovits. I've been working on extending this good work with a new type system and definition-use chain.

The definition-use chain is a sequence of scopes in a code file, and the associated definitions which occur in those scopes. These are created on the first pass after parsing to an AST (abstract syntax tree), along with the data types. On the second pass, we search for a definition which corresponds to every variable use, and complete the chain. This work is now nearing completion; remaining issues are template support, and better forward declaration and typedef support. I also have to reconsider the use of shared pointers in the type system, because as Roberto pointed out, C++ allows recursive types (which don't work well with shared pointers). Here's a look at some of the highlighting possible with the definition-use chain: (please ignore the bugs

On Thursday, I implemented code completion. This is the first real use of the new model-based code completion that I wrote for Kate. By expressing the possible completions in a model, and properties associated with each (eg. public/protected/private, etc), Kate can then perform some advanced functions such as sorting, filtering, and grouping. I'll post a screenshot when I can undo some recent breakage.

On Friday I implemented a symbol table, which contains a reference to every definition currently in memory (from all files). I should have done this a week ago - it turned out to be quite simple. Now, hopefully the definition searching will scale up to handle the load when we have all includes parsed in.

[Side note: did you know that Print Screen invokes KSnapshot? a neat trick I learned by accident]

Some work has also gone into performance of this new system, which has paid handsome dividends thanks to valgrind/callgrind/KCachegrind. Parsing speed was increased by 80%, thanks to the removal of dependance on QTextStream in the preprocessor, an unused symbol table in the parser, and KUrl comparisons in the definition-use chain (which I was surprised about... I thought it would be much quicker given that they should be implicitly shared). More recently, I've optimised the most heavily used paths in the definition searching algorithms, and was pleasantly surprised at the performance increase when switching a critical foreach loop into a const iterator style. Also, I've discovered QVarLengthArray in optimising our QualifiedIdentifier class; as they are created and destroyed very often, reducing the list overhead was important (note to self: maybe making them implicitly shared would help even more).

So, where to from now? We're reaching a fairly stable api, and one which allows for code refactoring, intelligent navigation, improved automatic code generation (eg. I'm looking forward to "create switch statement"), context-sensitive code completion, integration of documentation, debugger integration, a code structure view, call graph, static code analysis etc. If you're interested in helping, we'd love to hear from you [as manyoso would say, especially if you have QGraphicsView mad skillz].

One of bugzilla features is displaying various headlines, probably in order to cheer up the poor bugreporter or bughunter. KDE bugzilla actually doesn't seem to have this enabled, but I liked this in the old SUSE bugzilla, it had a nice collection of funny quips for the headlines. Those are gone now though after the switch to Novell bugzilla, which seems to prefer various encouraging quotes from famous people (I can't help it but sometimes they kinda remind me of the old communist times with their slogans). However, looking at the complete list I can see that some funny comments are finding their way even here, so all is not lost .

Anyway. Among the various lines I found some that show that even wise and well-known people have their limits. Consider, for example, this one:

If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor, and when was the last time you needed one? -- Tom Cargil, C++ Journal.

The name rings a bell, I think I read a C++ book by this person once (I don't remember if it was a good or bad one though, I've read both kinds). But if he doesn't known, well, good luck I'm here to the rescue. The answers are "some nonsense just made up" (because, if nothing else, private destructor effectively disables inheriting, so it can't be a base class) and therefore the second answer is "never", for everybody. I admit though that the question looked really tricky. Let's try if I can make up something like that as well. How about this one?

If you think plain C is not overly complicated, just what is a static const non-volatile pointer to a register non-const volatile integer, and when was the last time you needed one?

(Just in case you wonder, the answers happen to be remarkably similar. Bonus points for people who can explain why a correct answer may be "&" or "" and "all the time" if it's changed to "register const non-volatile pointer to a static const non-volatile X" depending on the type of X. Extra bonus points if I didn't get it right and you can point it out )

And there's one more interesting quote that shows that a person often doesn't see all the posibilities of their invention:

I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay

I don't see why one should feel so depressed about not seeing all the possible uses. It happens to everybody, all the time. I wonder if something like this would cheer this guy up:

I invented the term Programming, and I can tell you I did not have C in mind. -- Charless Babbage

(Although, I suppose, Alan Kay would probably like it more to find out Charles Babbage had no idea Smalltalk would exist one day. My bad.)

I think I should even try to submit these to the Novell bugzilla, I know I can't compare myself with the others, but perhaps they'll make it through. Everybody needs to cheer up sometimes when digging through bugreports.

Anyway. I have one more that probably says it all:

Bugrit. -- Foul Ole Ron