linux Syndicate content

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

» KDevelop 4 - Looking at the feedback

Mon, 05/03/2010 - 23:46

Hey everyone,

I spent some time today browsing teh interwebz to look at the responses our first KDevelop 4.0 release triggered so far. Quite fun I have to admit, given this is the first release of something I actively helped to develop that actually gets a response on the net ;-) What I noticed among the ‘I use VS’, ‘I use vi’, ‘I use ed’ comments (besides ‘I use emacs’):

  • sadly we didn’t update the screenshots everywhere yet, making some people believe we actually look like kdev 3 still ;-) this is not true, take a look here: http://apaku.wordpress.com/2010/04/25/kdevelop-4-0-screenshots/
  • yes we have support for PHP and everyone knows PHP sucks but still everyone uses it ;-) But few seem to notice that C++ is actually “just another plugin”. And we already have support for Ruby, Java and Css somewhat working in the pipelines. And very experimental stuff for C#, python and XML is also there. Imo what we said in the release announcement is true: KDev 4 is much more open for new languages than anything before. It does take some effort, true, but the result is much more pleasing.
  • we’d really welcome new blood in our dev team, esp. for new language support plugins or things like automake, qmake and qt-designer support. there are outdated plugins available, someone just has to polish them…

But all in all I’m amazed by the trolling/feedback ratio. It’s a really good feeling to see so many positive comments on various websites and $random-stranger defending KDevelop against the forces of the trolls :)

I’ll definitely continue working on KDevelop and make sure we’ll continue to improve over the time. This is just the beginning evil laughter :)

Btw. funniest comment on heise.de (German): KDevelop 4.0.0 is a released intended for developers. Of course, it’s an IDE, duh :P

» 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…

» You gotta watch this: RIP: A remix Manifesto

Sun, 04/25/2010 - 18:15

Hey all!

I’m now abusing the fact that my blog is aggregated on the planet to bring this diamond of a documentary some more coverage it deserves so greatly. I’m speaking about Rip: A remix Manifesto. Go and watch it. Now!

I bet every single FOSS user, developer, advocate thrives in watching it. I’m totally blown away and hope that as many people as possible watch it.

And gosh - open source cinema, how cool is that :)

» 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 :)

» Massif Visualizer - Ready for Testers and Feedback!

Mon, 03/29/2010 - 12:47


memory consumption overview

Hello everyone!

In my opinion, the massif visualizer is ready for testing. I bet there are still a few rough edges, but the most important features are in. So if you are going to do any memory profiling these days, please take a look at my tool and give me feedback. I’d be especially interested in whether the massif visualizer helps in the work flow to analyze massif data files.

My personal work flow so far is the following:


callgraph of detailed massif snapshot
  1. generate massif log, one way or the other (unit tests preferred since they give you reproducible test cases)
  2. open log in massif-visualizer, look at overall consumption chart
    1. how does the memory consumption evolve? is there a memleak?
    2. are there designated peaks which could be reduced?
    3. are there any (significant) contributions to the memory consumption, that needlessly stay over the whole application life?
  3. to find the actual culprits in code and/or to grasp the composition of a memory peak, use the detailed snapshot analysis

I wonder how I could improve the tool to also help with verifying that a fix helps, e.g. by either overlaying two charts or by only showing the difference. The problem here is of course that it would only work with reproducible test cases and that it needs interpolation since the snapshots are taken at random points in time. Still, it would be nice to open two massif logs and seeing the impact on memory consumption of a patch visually.

Note: To anyone interested: I generate the callgraphs by converting the massif snapshot trees into a graphviz DOT file. That one I than visualize with KGraphViewer KPart. Since KGraphViewer was in no shape to visualize the huge amount of data in my use case, I had to optimize it greatly and push in some more features to make it better suitable for thirdparty users. To integrate it better, I had to write a public interface, which also means that you need KGraphViewer installed from source to be able to compile Massif Visualizer (I’ll make it optional later on). Hence get the sources from here (packages by your distributor won’t be enough): http://websvn.kde.org/trunk/extragear/graphics/kgraphviewer/

» Massif Visualizer - now with user interaction

Sat, 03/13/2010 - 16:55

Just a quick status update: Massif Visualizer now reacts on user input. Meaning: You can click on the graph and the corresponding item in the treeview gets selected and vice versa. It’s a bit buggy since KDChart is not reliable on what it reports, but it works quite well already.

Furthermore the colors should be better now, peaks are labeled (better readable on bright color schemes, I’m afraid to say…), legend is shown, …

Now lets see how I can make the treeview more useful!

» Transparent loading of compressed Callgrind files in KCacheGrind

Thu, 03/11/2010 - 23:43

Hey everyone!

I just committed an (imo) insanely useful feature for KCacheGrind: Transparent loading of compressed Callgrind files. Finally one does not have to keep those Callgrind files around uncompressed, hogging up lots of space. And what is even more important: It’s much easier to share these files now, as you can send or upload them as .gz or better yet .bz2 and open them directly. KDE architecture just rocks :) So in KDE 4.5 the best profiling visualizer just got better :D

In related news: I’m spending my time as intern at KDAB currently by creating an application to visualize Massif. If you are interested, check the sources out on gitorious: http://gitorious.org/massif-visualizer

It’s still pretty limited in what it offers, yet is probably already more useful than the plain ASCII graph that ms_print generates:


Visualization of a Massif output file

This is very WIP but the visuals are somewhat working now. I plan to make the whole graph react on user input, i.e. zoomable, click to show details about snapshots, show information about the heap items that make up the stacked part of the diagram, …

Also very high on my wish list is some kind of interaction with the KCacheGrind libraries, to reuse it’s nice features like callgraphs, cost maps, etc. pp. you name it :) All these features that make KCacheGrind such an insanely useful application.

Oh and remember: Never do performance optimizations without checking the facts first ;-)

» 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 ;-)

» FOSDEM, 4.4 release party in Berlin, ...

Thu, 01/28/2010 - 00:56

Hey everyone, just a quick blurp:

FOSDEM

Yeah, I’ll go to FOSDEM! Will be my first time, I’m really looking forward to it. Esp. considering that it marks the end of my current semester. My current plan for the following days is:

  • visit relatives & friends
  • go to FOSDEM
  • get an immense overload of hacking at the Kate/KDevelop sprint
  • start working as an intern at KDAB

Looks like the future will be much fun :)

But back to FOSDEM: If you have any questions about Kate/KDevelop/PHP, visit me at the KDE booth. I’ll also attend Aleix’s talk about KDevelop for sure.

4.4 release party in Berlin

So well, Nighrose poked me on IRC and I added a short note about a small get-together on the 13th in Berlin. I’m reluctant to call it release party since it’ll be at the rented flat for the Kate/KDevelop sprint attendees, hence only a limited number of people can attend. But esp. other KDE/Qt/KDAB hackers in Berlin & vicinity are welcome. If you want to come by, take a look at the wiki notes about the “party” and contact me by mail.

If anyone else has a bigger party planned, please tell us. We’d be a horde of 10+ hackers, ready to crash anything :)