krazy2 / ebn developments.


I just have been busy finishing my master. Which, I can say, is progressing nicely. I’m winding up my last two courses and preparing for my move to Berlin, where I’ll do my master thesis research at KDAB.

However, that’s not what I wanted to blog about. I wanted to write an update about the work I’m doing on the english breakfast network, krazy2 and the integration of a C++ parser in the framework. Due to one of the courses I followed I got interested in software maintenance, evolution and quality. Within KDE we have all kind of policies and measures in place to guarantee some kind of quality like coding standards, commit policies, program lifetime policies and what not more. Another framework we also have is the englishbreakfastnetwork which most of you probably know by now.

EBN shows the results of several tools that are developed like krazy2 and documentation sanitzers, which are ran against the KDE code base. So, what’s the actual use of this? Most of the checks are not that advanced. In this [1] paper it is even concluded that the presence of public coding standards and shared practices does not seem to have a significant influence on the quality in comparison to projects where this isn’t the case. So what is the use of krazy2/ebn in it’s current form than? I think that its main function, in its current form, is to provide a good point for starters who want to help out with easy coding/documentation tasks.

However I think that we can get more out of the EBN framework. To get more we also need to store a bit more. And that’s one of the things I’m currently working on. Currently a new tool is in development. It is (becomming) a framework which can run different tools on a software component. It’s a bit like the krazy2ebn script, but more flexible as it will support not only krazy2 but also other checkers to be plugged in. The framework will store not only results of the checkers (and their plugins) in a database but also the versions of the checkers/plugins that are used for a specific run. The main differences in storing the results will lie in the fact that the new framework will store detailed result information of all runs done. Storing all this information will enable us to not only see the current state (in terms of issues found by the tools) of the software, but will also enable us to relate checker evolution to the quality. It will also be possible to search for modules/submodules that shows tendency of bitrot (e.g. modules which have only a growing amount of issues over a specified period). This whole framework is in an early state and comments/suggestions are of course welcome.

Another thing I’ve been working on with a collegue student is integrating a C++ parser into the quality framework. I’ve played with several parsers and currently I’m using SolidFX from SolidSource IT [2]. This is a commercial parser but we can use it for free on EBN, due to the fact that one of my profs at the university is the author of it. It has some really nice features like:

It does full syntax analysis of several C/C++ dialects (including the one(s) supported by the gcc compiler suite); own preprocessing; and an almost full semantic analysis along the C++
Standard, including most of the template instantiation/specialization stuff. Tested on things like Boost, Python, Coin3D, wxWidgets, parts of the Linux kernel, also Windows code. There’s also a mechanism for error recovery in case of lexer/parser/type-checker errors due to wrong code/missing includes.

Currently we’re Implementing a check using this parser which checks if a class overrides non-virtual methods of (one of its) base classes. We’re interested in implementing other checks, of which you think are useful and require a full fledged parser. So feel free to leave a comment or drop me an email. Please describe precisely what you want to check and also why. I’m also idling in #ebn btw. That’s all for now folks, thanks for reading.

[3] From the author, prof. Alex Telea

This entry was posted in Uncategorized and tagged . Bookmark the permalink.

8 Responses to krazy2 / ebn developments.

  1. Anonymous says:

    Even if the parser is free as in beer (at least for you), the fact that it is not (and will remain, at least for the immediate future) non-free as in freedom is limiting.

    Why not use something like dehydra instead?
    It uses gcc and for sure gcc has all the language coverage you could ever wish for.
    It is also actively maintained and supported by the mozilla folks.

    And there is also the kdevelop parser which, though not even nearly as advanced as
    gcc or the commercial frontends, is hopefully already reasonable enough for kde.

  2. Bertjan says:

    Yep, I totally agree on the “freedom” stuff. So why? Well there are a couple of reasons first of all I *tried* (probably not hard enough at that time) to get Dehydra working and the maintainer seemed to busy at that time to get me really started. Another reason is that this is also part of an uni assignment and some guarantees on correctness of the parser where needed. I also had a look at the KDevelop parser and this one is heavily intertwined with the user interface and it seemed some work to get the parser working standalone.

    And last but not least, sometimes you just need to get things done…. using a working parser, although not free can help on this.

    “is hopefully already reasonable enough for kde”

    Well this is the point I don’t agree on. Working with “half-baked” sollutions will definitely get you more work in the future. Also, the whole point of integrating a full-fledged C++ parser was to be able to do more advanced checks. So working with a parser which for example doesn’t give you the type system will again (as with perl scripts) result in lots of heuristics.

  3. fwegvekhw says:

    Gf9veq rlfzxoqrazft, [url=]wbjcqsctwquo[/url], [link=]knseolgcqiqo[/link],

  4. edidiev says:

    4x4s5d gbnmrsvmevyl, [url=]etgaltmxpxgd[/url], [link=]zzdncqcxgqzp[/link],

  5. Milian Wolff says:

    As a KDevelop Hacker I ask myself:

    Wy don’t you reuse some of our code?

    The DUChain would give you all the information you can think of. And it’s totally free _and_ lives already in KDE SVN.

  6. pmprodxfxl says:

    j9zEWE juhexrxtawpw, [url=]ocgtiqorgbau[/url], [link=]lzfpozloioet[/link],

  7. Did you try Alitheia Core?

    The task you describe is useful and the purpose is definitely noble. But did you do any research before resorting to write yet another framework for gluing quality tools together? I am asking since I am currently working on one (actually the paper you reference was a very rough outline of its functionality) and I would rather see what you missed in it that led you develop a new solution. I have already used Alitheia Core to process very large projects (FreeBSD-large) and writing plug-ins for it is dead-simple…

    (PS: Sorry for self-promotion, but I think re-inventing the wheel is not the way to go.)

  8. ziiyxbafyqq says:

    UacOVq lntvpbxnmvop, [url=]xdynwjrmbgia[/url], [link=]cwxrfttpeaqr[/link],

Comments are closed.