Looking back on Free Software

I've read some books on business recently:
They sometimes repeat each other but actually have few interesting moments. At least I started to look on all this from a bit different point of view. Unfortunatly this domain is covered differently by Free Software community people who tend to be idealistic but promote their point of view actively. The words like "community" or "leadership" or "cool people" don't bring much in the end, and the most interesting thing is that such words are mosly spoken by corporate people.

Anyhow, it would be nice to have a project that will have a clear mission and a set of reachable goals, like product plans each one with a design both technical and non-technical documents. It would be nice to have a test set with 90% coverage and a build without warnings and also a tracking system for user requests. Thing like slick UI are also important. After all, it's easier to get this than to build an LVCSR with 95% accuracy I think :)

Frama-C Eclipse plugin

I decided to finally go forward and publish my modifications of frama-c Eclipse plugin I'm doing at work. Moreover I decided to try git/github. Let's see how it goes. The project is here:


the future plans include
  • better graphics
  • more cleanup
  • offshelf support for recent Frama-C versions

Quest in configuration file

After almost a year of wondering I finally discovered what does this mean in sphinx4 config files:

<component name="activeListManager"
<propertylist name="activeListFactories">

Actually it's even described in docs:

The SimpleActiveListManager is of class edu.cmu.sphinx.decoder.search.SimpleActiveListManager. Since te word-pruning search manager performs pruning on different search state types separately, we need a different active list for each state type. Therefore, you see different active list factories being listed in the SimpleActiveListManager, one for each type. So how do we know which active list factory is for which state type? It depends on the 'search order' as returned by the search graph (which in this case is generated by the LexTreeLinguist). The search state order and active list factory used here are:

State TypeActiveListFactory

There are two types of active list factories used here, the standard and the word. If you look at the 'frequently tuned properties' above, you will find that the word active list has a much smaller beam size than the standard active list. The beam size for the word active list is set by 'absoluteWordBeamWidth' and 'relativeWordBeamWidth', while the beam size for the standard active list is set by 'absoluteBeamWidth' and 'relativeBeamWidth'. The SimpleActiveListManager allows us to control the beam size of different types of states.

It's hard to guess, isn't it? Well, I hope soon we'll be able to make configuration easier. The idea of annotatated configuration came to my mind today. With the older idea of using task-oriented predefined configurations it could really save a lot of efforts.

Today with the help of my chief I've found FindBugs, a nice static analyzer that tries to find the issues in Java code and reports about them. It's a very useful tool since I've already fixed a few bad things in sphinx4 and in other projects. The number of false positives is acceptable. The similar tool for C for example is splint, though java tools as usual are much more useful. And there is an Eclipse plugin that helps to apply the tool with a single mouse click.

This makes me think about what can be counted as a development platform. Although it's well known that scripting languages like Python speedup the development, they totally lack the tools like static analyzers, debuggers, profilers, documentation and testing frameworks and so on and so forth. There is some effort to create a common framework to quickly build development tools along with DSL language, but the result is not so advanced I suppose. Basically it seems today there is no choise which language to use for the development and in the light of this it seems very strange that GNOME development goes in completely opposite direction stepping to the domain of JavaScript and naive programming. I hope the desktop will not become a collection of bugs after that.