Graph Library Suggestions

I have an idea for an algorithm that requires a graph. Any suggestions on good library in c++ for the data structure would be nice, then I wouldn't have to reinvent the wheel. There is one special requirement; there can be (but needn't be) two edges per connected nodes. Each edge has a direction and weight. If the edge is implemented as a template class, then it can store a tuple or pair with the differing weights for each direction. I've taken a look and boost, but it seems like overkill, Below is an example of what I need.



I created the image above in Kivio. This is the first time I've had an opportunity to use it. Great work KOffice team!

EDIT: I'm going to go with boost for now. Additional suggestions are still welcome.

Sonnet Updates

I've been fairly busy the past two weeks and haven't put as much work into Sonnet as I would like. However there are several recent developments to mention.

Language Detection
We now have preliminary support for distinguishing between pt_PT and pt_BR as well as en_US and en_GB. Portuguese seems to be a special case that most NLP programs explicitly acknowledge, which I now understand. I'm not sure what should be done to additionally distinguish between en_ZA or en_AU. I've a few ideas and will let everyone know my thoughts after more testing is done. I really didn't want to start messing around with dialects, but the response to that position has been massively against me; so into the fray I go.

Elixir
The engine and documentation for Elixir is now ready for public scrutiny and comment. It has been interesting for me to write, since I've decided to only use C++ and the standard libraries so that there wouldn't be dependencies. Qt has really spoiled me :) The work has so far been done in my personal subversion repository. It will be made public as soon as Bug #9775 has been fixed and I have a working freedesktop.org CVS account.

Documentation
Aseigo mentioned the need for documentation today,

"sonnet might be cool, for instance, but unless there's a tutorial that lets people start using it in their application code quickly it'll almost certainly end up under-utilized and/or take many more revision releases of kde4 to find its potential realized."

So true. The public interfaces for Sonnet have only just settled down, and some are still on my computer and yet to be committed. So, this weekend I'll update most the changes littering my working directory and start outlining some tutorials to be put in the wiki. I've been fairly good in providing apidox so far, but those need some improvements as well. Of course, KDE4PORTING.html needs to be updated as well.

Merging
I've been hesitant to merge into trunk while the interfaces rapidly changing, but now that isn't much of a concern. A list of programs and libraries in kdepimlibs, kdebase and several other specific cases has been compiled and I'll be able to modify them when merging to ensure they build. For those projects that I personally won't migrate the tutorial should enable their developers to migrate seamlessly.

Sonnet In The Press

Nathan Sanders of OSTG interviewed me for an article last week. The result has just been published on Linux.com in an article entitled, "KDE 4's Sonnet will turbocharge language processing."

Overall, I'm pleased with the coverage, but I do have a few misgivings; although, any minor errors likely are my fault for providing limited explanations in the interview. The scope my concern of is largely limited to grandiose statements I did not intend. For example, "[I]mproved multilingual support is the "most requested change" from KDE 3..." I didn't really mean this; it was a context sensitive statement. I meant something such as, "Excluding technical issues like, 'KSpell doesn't work for me' The most requested features for KSpell that I know of (from end users) involve improving its multilingual support." But, requesting extra qualifiers for my statements is more likely an exercise in vanity than in promoting greater truth.

I will mention, the article doesn't note the work of David Sweet. I'm not familiar with what exactly he did, but my understanding is that he wrote much of the original KSpell and thus much deserves some credit.