kdevelop Syndicate content

warning: Creating default object from empty value in /www/htdocs/w0065fc9/milianw/modules/taxonomy/taxonomy.pages.inc on line 33.

» GSOC: Revive Quanta+ Brand for KDE 4

Wed, 04/28/2010 - 19:19

Yay I got a GSOC slot :)

So I hope I don’t have to introduce myself anymore to you guys. Instead I’ll show you what I’ve planned to do over the summer:

Motivation for Proposal / Goal:

Back in KDE 3 times, Quanta+ was one of the reasons for me to use KDE. In my eyes it was the IDE for web development out there, and I loved to use it. Sadly it’s bitrotting nowadays without a finished KDE 4 port. That, combined with the fact that more and more distributions drop all KDE 3 packages, makes the need for a port more urgent than ever.

Implementation Details:

Thankfully, KDevelop 4 is nearing it’s first release and the KDevplatform is mature enough nowadays. This means that during summer I shall finish the port of Quanta+ to KDevplatform and supply it with all the plugins required for a proper webdevelopment IDE. My goal is it to provide a proper IDE for PHP webdevelopment. In more detail:

  • make Quanta+ 4 compile
  • remove obsolete plugins or code parts in Quanta+
  • port required plugins to KDevplatform structure
  • polish PHP plugin, including XDebug support
  • polish Script Execute plugin
  • polish CSS plugin
  • get a first working version of a XHTML/XML plugin, if time allows even with HTML (SGML) support
    • support autocompletion
    • support inline validation
    • support documents that use multiple languages (XML, PHP, CSS, JavaScript) at the same time
  • polish the UI/Workflow for Webdevelopment
    • hide KDevelop/C++ specific actions
    • add templates for common PHP frameworks
  • if time allows, get a rough support for JavaScript (at least Outline for functions)

Put these all together with the existing features in KDevplatform we can reuse, we’ll end up with a hopefully useable IDE for webdevelopment. Hence my final goal is it to release a first Beta version of Quanta+ for KDE4.

Tentative Timeline:
  1. getting rough first shell of Quanta+ 4 up and running, removing old cruft, cleaning up old code and porting required things
    ~ 3 weeks
  2. polish existing plugins (PHP, XDebug, Execute Script, CSS, Upload)
    ~ 2 weeks
  3. create XHTML/XML plugin
    ~ 3 weeks
  4. polish UI/workflow
    ~ 2 weeks
  5. bug hunting etc., ending in a first beta release of Quanta+ for KDE 4:
    ~ 2 weeks

Lets see whether it works out as planned. But I think this commit shows you that I’m on the right track:

http://websvn.kde.org/trunk/extragear/sdk/quanta/data/pics/quanta-splash…

» Where Profiling Sucks

Mon, 04/05/2010 - 03:12

Ok, you should know by now that I love profiling and making things faster. Yet there’s always a “but”. For me it’s blocking syscalls, or anything that makes the app “slow” for the user but doesn’t show up in Callgrind as the Instruction Fetch cost doesn’t go up.

The usual suspect is of course locks (which we have quite a lot in KDevelop) or QProcesses with waitForFinished() or similar… You won’t see them in any Callgrind profile. Does anyone know a way to achieve that? Something that makes Callgrind increase the Ir cost for blocking func calls depending on the time it blocks? Or some other tool that would show me these?

And if you are interested: I was still able to find the cause for slow parsing of Custom Make Manager projects (Qt, Linux Kernel, …) in KDevelop: The cache in the IncludePathResolver never hit, since a operator== was improperly implemented ;-) I really wonder how we could have missed that for so long! I’ve also added some more changes that should make it much faster to parse projects that rely on the IncludePathResolver. I was personally now able to parse 10.000 files of the Linux Kernel in about 9.5 minutes. This is roughly a third of the Kernel, so I’d get to a total of approx 30min. Compare that to the 2.5h for 5% that one of our users reported ;-)

» Profiling Rocks - KDevelop CMake Support now 20x faster

Wed, 03/31/2010 - 01:24

I just need to get this out quickly:

We were aware that KDevelop’s CMake support was slow. Too slow actually. It was profiled months ago and after a quick look that turned up QRegExp, it was discarded in fear of having to rewrite the whole parser properly, without using QRegExp. Which btw. is still a good idea of course.

But well, today I felt like I should do some more tinkering. I mean I managed to optimize KDevelop’s Cpp support recently (parsing Boost’s huge generated template headers, like e.g. vector200.hpp is now 30% faster). I managed to make KGraphViewer usable for huge callgraphs I produce in Massif Visualizer. So how hard could it be to make KDevelop’s CMake at least /a bit/ faster, he?

Yeah well an hour later and two commits later, I managed to find and fix two bottlenecks. Both where related to QRegExp. Neither was the actual parser, instead it was the part that evaluated CMake files, esp. the STRING(...) function. So even if we’d used a proper parser generator, this would still been slow.

The first one was the typical “don’t reinvent the wheel” kinda commit which already made the CMake support two times faster for projects that used FindQt4.cmake, i.e. any Qt or KDE project. Not bad, right? Well, while I fixed that I saw that KDevelop tried to do some Regular expression replacement on the output of qmake --help, this could not been right, could it? With help of Andreas and Aleix we found the bug in the parser and that made the CMake support 10 times faster.

So yeah, CMake projects using Qt or KDE should now get opened a whopping 20 times faster in KDevelop :)

I really love KCacheGrind and Valgrind’s callgrind - again it proved to be the most awesome tool one can imagine! If you are interested in the callgrind files:

  1. without optimization
  2. first optimization
  3. second optimization

Note: with KCacheGrind from trunk you can open these compressed files transparently :)

» Kate/KDevelop HackSprint - Up To Day 4

Wed, 02/17/2010 - 19:43

Woha, quite a few days flew by without me blogging about anything. Thankfully the others started to write so I don’t have to repeat it all ;-) Instead I’ll concentrate on stuff I did or learned.

GHNS for Snippets

Well, first I think an excuse is in oder: There is a GHNS button for Kate Snippets in 4.4.0 but it’s broken, neither me nor Joseph had time to acutally use and fix it… But anyways, I fixed it now for 4.4.1. For 4.5 we’ll also have an Upload Dialog.

I also added both now to KDevelop, you can now upload and download snippets from it. I added a few dump examples but will probably improve it steadily.

Kate Performance

On Saturday and Sunday I started to profile Kate highlighting for a large MySQL dump and managed to greatly improve the speed. Actually the funny thing is that I could improve RegExp based highlighting (you still should try to prevent using it, it will always be slower than simple char/string based highlighting). And the knowledge for this optimization I had from my time as an active contributor for GeSHi. I feel like it was ages ago, he funny :)

So if anybody has a big file that takes ages to load (but only if you use KDE 4.5 trunk or higher), tell me and give me the file. I might find some more ways to optimize different languages.

Other Stuff

Other than that I also managed to fix a few more bugs in Kate and KDevelop and had a good time with the other guys here in Berlin. Yesterday I showed some others how I spent quite a few nights: Partying in Berlin is nice :)

Oh and Bernhard showed me a little gem of his: Kate Standalone which you can use to build only KatePart from kdelibs trunk. This actually works very well (up until some new API from KDE trunk is used).

» Kate/KDevelop HackSprint Day 1

Sun, 02/14/2010 - 01:58

So, first day of the Kate/KDevelop hacksprint.

We just talked and hacked at the rented flat,got to know each other and had a fun time. Everybody made it more or less in time, even last minute attendee Adymo from Ukraine, nice! Hacking-wise the productivity wasn’t that high, esp. for me, but a few patches got committed here and there.

Right now I’m working on a little speedup for Kate, esp. for big MySQL files - lets see how it turns out. Cullmann showed me a few things I could do so maybe it works out, lets see.

Over the next week I plan to push in user configurable include paths for the PHP plugin and do some more Snippets & Scripting work in Kate, lets see how it turns out. I’ll go home now, kinda sucks that I don’t stay with the others here at the flat but have to take a 1h ride into the city… Berlin is definitely too big :D

» Snippets In KDevelop / Kate

Wed, 02/03/2010 - 17:59

Hey all!

Just wanted to give you a little rundown on Snippets in Kate 4.4 (via the snippets_tng plugin) and KDevelop Beta 8 (soon to be released).

Note: The Kate plugin was written by Jowenn and introduced me to all these nice features. For KDevelop I wrote a somewhat simpler yet imo better implementation. We will try to get the best of both worlds into KDE 4.5. Stay tuned!

General Usage & Features
  • create a snippet repository (or download via GHNS [see below])
  • create snippets in that repository
  • insert snippets via the snippets view (i.e. double click), or (imo better/faster) insert them via code-completion (remember: CTRL + Space requests code completion at the current cursor position!).
  • snippet gets inserted (properly indented) and potential placeholders/variables get expanded. A variable is something like %{date} or ${email}. Also take a look at the API documentation.
  • variables that get inserted via “${…}” will be “selectable”, meaning you can jump from one var to the other by hitting TAB / Shift TAB
  • the %{...} vars will only get expanded and inserted, without getting selectable.
  • multiple occurrences of the same variable will be updated once one of them gets edited, something that is called “mirroring” in other editors.
  • once one edits ESC the cursor is placed at the end of the snippet or to the first occurrence of ${cursor} or %{cursor} and the user types something, the snippet-handler quits and you are left with your normal editor until you insert the next snippet
  • nested snippets (i.e. insert snippet than insert another one) should “just work”.
Snippet Management
  • group snippets by file type, i.e. PHP snippets will only be offered during code completion when one edits a PHP file.
    Note: In KDevelop and KDE 4.4 nested documents are supported, e.g. create a CSS snippet and it will be shown inside the CSS parts of a HTML document or similar. This uses my HighlightInterface I wrote for KDE 4.4. I still have to rewrite some parts of the snippets_tng plugin for Kate so that it works there as well
  • group snippets in repositories, set an Author and a License of your choice
  • publish snippet repositories via GHNS: In Kate you can already download snippets from GHNS but we sadly don’t have any repos up on opendesktop… I’ll have to add some prior to KDE 4.4. Also we didn’t have enough time to implement uploading of Repos from inside Kate in time for KDE 4.4. So stay tuned for KDE 4.5. KDevelop currently has no support for GHNS, but I plan to fix this tomorrow or the next days - together with uploading from inside KDevelop, i.e. all the nice features of GHNS v3.
  • in KDevelop (and someday in Kate as well) you can simply select a part of your currently opened document and select the “create snippet from selection” in the ContextMenu - easy & fast!
TODO

There’s much to do.

  • Highest priority right now for me is to get GHNS with all bells and whistles supported for KDevelop.
  • Then I’ll merge and integrate the Kate & KDevelop plugins as much as possible, so we have a reduce code base.
  • Also important is to make all shortcuts configurable
  • Another thing is: How could we improve interoperability even between e.g. editors like TextMate or Gedit? Both have snippets features and their bundles are available in the net. If we can support those we’d save us a lot of work

Also, I should probably do a screencast… Not now though ;-)

» progress in PHP support for KDevelop

Wed, 01/20/2010 - 14:44

Hey everyone. Been some time since I last blogged… I want to take the chance to give you all a bit of overview over the last changes in the PHP plugin for KDevelop:

Performance Improvements

I spent quite some time profiling various aspects of the PHP plugin, be it parsing and DUChain building over to (just yesterday) code completion. I’m confident to say that I found (and removed) quite a few bottlenecks, making the plugin much more comfortable to use.

I’m really blown away time over time again by valgrind & KCachegrind… What would we do without these tools?

Documentation

An (imo) very strong point for using KDevelop for PHP programming is it’s seamless support for documentation. Be it the “simple” inline documentation in the Declaration Tooltips or the extended integration of the remote PHP.net docs. But these past days I improved our generator for the inline documentation of built-in PHP language constructs considerably:

  • add documentation for function/method parameters
  • add @since where appropriate
  • fix some missing declarations or bugs, esp. some that where part of SPL

These changes increased the size of the generated file to whopping 3.1M. This was too much for me and hence I added support to ship this file zipped (i.e. now it’s 80% smaller) and we decompress it transparently with the use of KZip. Adding such a feature was a breeze, so nice to work with the KDE Api :)

There are still a few things missing and stuff I plan to improve here, so stay tuned for more news in this regard.

» Will code for food

Tue, 12/22/2009 - 05:34

Ha, what a bit of a bribe can do to me… Someday earlier today a user of the PHP plugin for KDevelop brought up the flickering issue in it again. Well as I told him: I myself find it very annoying and wanted to fix it since quite some time, but never got around to it… Usually that would be it and I’d go watch some more FamilyGuy until I’m in the mood to track this bugger down. But well, thankfully Phlogi wasn’t so easy to dispatch:

<Phlogi> milian: ok… I’ll send you pizza and beer if you fix this!

Hours of gdb sessions later, I finally committed a fix. So Phlogi, if you read this: You owe me ;-)

To all others: If you tried the PHP plugin out and the flickering was too much for you: Give it a try again! I’m personally totally overwhelmed, the difference is huge! I often perceived the PHP plugin to be magnitudes slower than the C++ one. Well, looks like most of this was only due to the flickering. Now things are much smoother.

Happy holidays!

» PHP and PHP-Docs plugins now up for review (meaning: SVN location moved!)

Thu, 12/17/2009 - 22:29

Hey all!

Just a quick note: Niko and me moved PHP & PHP-Docs to kdereview, we hope to move both plugins to extragear/sdk/kdevelop-plugins. So, if I understood things correctly, after a two week period the plugins will get moved there (well, if we pass the review, but I think we can do that).

So for anybody that uses the plugins from SVN, you’ll have to relocate. The new addresses are:

  • /trunk/kdereview/kdevelop-php
  • /trunk/kdereview/kdevelop-php-docs

See you in two weeks :)

» Real FOSS appreciation

Mon, 12/07/2009 - 03:25

So, it’s been roughly a year since my first commit to kdelibs. According to Ohloh it’s been in November 2008. And boy have I learned much in this year. I learned C++ just to be able to contribute to KDE, since I thought it would be awesome to be able to “fix your own itch”. I have to say: It was the best decision I ever made.

I really came to appreciate FOSS in a whole new light: Contributing to a big project like KDE gets you in contact with lots of nice people. And they will help you get things done. What’s better is that in the process you learn lots of things. And I mean lots. I can now use GDB, Valgrind, now my way around some parts of the KDE/Qt API, can investigate performance related questions… And since these are such huge topics, there’s always more to learn, much more!

I doubt someone could learn that much by reading books or writing his own little application without the help of a community. The wealth of possibilities inside KDE will increase your horizon constantly. And there is tons of very good code to study! Want to know why something is not working? Look at the source. Still not helping? Ask your fellow developers. I really have to say it’s an awesome feeling to be part of this big community.

Fixing an itch: Qalculate! backend for Cantor

You know, I’m officially a Physics student, I just happen to be way more interested in programming (the practical part of it, not really that much the theoretical part).

Since I started with Physics two years ago, I always required a good calculator, esp. for experimental physics. The best calculator I found was Qalculate!, especially it’s great support for units and constants made me solve tedious exercises in a fraction of the time it required my fellow students that could not use Qalculate (it only runs on Linux). Really, it’s an outstanding piece of software in my opinion.

But to get to the point: Qalculate was the last KDE 3 app on my desktop, and I wanted to change that. Now I read about Cantor, esp. once fellow KDevelop hacker Apol wrote about his KAlgebra backend for Cantor, and I knew: This is the perfect fit for libqalculate!

So last week I started and already have a somewhat working backend available:

http://websvn.kde.org/trunk/playground/edu/cantor-backends/qalculate/

This once again showed the utterly insane greateness of FOSS: I started to hack on the backend and looked at the existing backends for guidance. I also contacted arieder, the author of Cantor, directly and chatted with him, getting help. But I did not only /take/. I reviewed his API, gave suggestions, reported whishes and bugs and eventually hacked a little bit on the sources themselves. Imagine this in a corporate environment: I’d probably have had to report in some shabby tracker and wait ages for my feature request to be closed as wontfix…

And while writing the backend I had this realization that also triggered this blog post: I actually did something useful in a few days. I could never have imagined being in that position one year ago. I always thought that C++ was a bit of black magic, especially writing things from scratch. But now… Now I’m somehow able to grasp code and come up with something working in a few days.

The problem this brings, is of course that you can easily loose track and overload yourself with work… I could spent lots of hours in any part of KDE. My TODO alone bears for KatePart, KDevelop-PHP, KDevelop itself, Quanta, …. You name it! I think this will become a fun holiday ;-)

PS: Just a quick note: I really think that Cantor will become a great and useful application for science students. It will be your central application for any calculations, either numeric (e.g. Qalculate) or symbolic (e.g. Maxima).