We have talked to a lot of people and got a lot of feedback – thank you for that, it was awesome! Here are some of the most prominent feedback items (if you think I forgot something valuable please drop a mail to lasse@schuirmann.net):

We lack something to check java code: we have corrected that and did a Java Checkstyle integration available in the coala development release or on GitHub.

The Interviewer for the Hacker Public Radio asked for Perl – plus they had a stand nearby. We couldn’t help but force a very poor newcomer to create a perl critics wrapper which is currently WIP at GitHub. [Edit, this has been merged and is available in the dev release!]

People wanted Go language support. Nothing easier than that! Go vet and gofmt are supported now, available in current development release and in the source code. GoLint is in the works and more will follow!

coala could be too generic to be useful. This is no feedback to be ignored, thanks to the people who brought that up. Our experience with using several different tools for static code analysis has shown that coala is a significant boost in comfort for the user, while writing analysis routines has shown that indeed coala reduces the amount of work needed for creating code analysis significantly. We need to make sure this stays that way and that it does not grow into a huge monster where analysis routines (bears) take over more than they should – actively.

Jenkins integration would be awesome. Jenkins currently has wrappers for a lot of tools, coala could simplify this for them and their users. We actually were not aware of this and it is something we really want to give users the best out-of-the-box jenkins experience with their code analysis. We will try to get a GSoC student to work on this.

It works. A few people tried it out and it seemed they were genuinely surprised positively. People that knew coala before and ignored it came to us and admitted that we apparently seem to do something that is actually useful. It was very important for us to hear that.

Our new logo sucks. Well at least some people liked the old one better, especially the ASCII art which sadly doesn’t do well as a logo. For those of you we have the new release logo for the coala eucalyptus release and we’ll continue to produce those fine pieces of artwork – this one by Christian Witt:

I’m very happy to tell that apparently a few people of our indian community have managed to get a stand and a talk at FOSSASIA later this year. If you didn’t make it to FOSDEM and live over there – be sure to drop by, talk to them and grab a drink.

9 responses on “coala at FOSDEM 2016”

How does coala compare to something like firehose (https://github.com/fedora-static-analysis/firehose )? From what I can see both have the ability to wrap existing static analysis tools but is coala’s intended purpose to be used interactively (with the option to suggest/apply fix ups) rather than homogenizing and collecting results?

coala tries to do a bit more than firehose. Yes, a common API/format in the middle is an important part.

1. Yes coala supports automatic issue fixing, currently via diffs, we also want to support diff generation functions so e.g. variable renamings can be done interactively with the user.
2. coala provides various user interfaces – editor plugins, we’re currently creating GitMate which automatically reviews PRs, interactive as well as noninteractive CLIs.
3. Basically coala is made for creating code analysis. Having something like coala is cool because if you’re doing research on code analysis you just write your logic and coala does the rest – you can rapidly prototype your algorithm and instantly use it in production. Second, you can reuse language independent routines. A routine cutting away trailing whitespace doesn’t have to be rewritten for every language if it can easily be combined with language dependent routines.
4. We do wrap a lot of tools because our goal is to reduce redundancy, not create some. This way users have a unified way to operate any code analysis with a good usability.

Did that help? You might find the link to the talk useful, it’s always a bit hard to explain what coala is.

Actually there’s a 5th thing: coala allows the user to use one configuration file for everything. You can set the `tab_width` setting and all linters and other routines should pick that up, there’s no need anymore to configure all linters individually and read up on all of them.

Yes of course, that’s part of the core idea. You can get JSON, native Python objects or even a custom format string to make parsing for you as easy as possible. We use that for providing editor plugins, Jenkins is on our list too. We’d love to speak to you at https://gitter.im/coala-analyzer/coala if you’re interested in that.

Interesting project! Just one minor issue: Why has setup.py code in it to download a jar file? What is supposed to be in the file? If it is free software, why not use its source code and compile it? Why download it over unsecured HTTP? Is the content not relevant? Thanks!

Hi, thanks for raising this issue! We use Checkstyle which is LGPLv2 licensed, which is downloaded here. We do this to make the installation as simple as possible. Would you mind filing an issue at https://github.com/coala-analyzer/coala/issues/new with your explicit concerns? This is an important debate we should have I think.