Got The Time?
10.09.2010 BEAST/BSE release 0.7.2 available
BEAST/BSE and BSE-ALSA version 0.7.2 are available for download:
http://beast.gtk.org/beast-ftp/v0.7/beast-0.7.2.tar.bz2 http://beast.gtk.org/beast-ftp/v0.7/bse-alsa-0.7.2.tar.bz2
BEAST is a music composition and modular synthesis application. The “Bedevilled” portion of the names has no religious background, please refer to the About page for more details.
Homepage: http://beast.gtk.org/ Downloads: http://beast.gtk.org/beast-ftp/ Feedback: http://mail.gnome.org/mailman/listinfo/beast/
The 0.7.2 release provides new plugins and instruments, and a long list of bug fixes, improvements and translation updates.
TRANSLATORS: Please help us to improve the BEAST translations at Transifex.
Overview of Changes in BEAST/BSE 0.7.2:
- BQS Bass Drum E8012 [Tim, Stefan] - BQS Slow Hum [Stefan, William DeVore] - FSM Fresh Water Bass instrument [Krzysztof Foltman] - FSM Growl Bass instrument [Krzysztof Foltman] - FSM Synth String Sweep [Krzysztof Foltman]
Overview of Changes in BSE-ALSA 0.7.2:
UPDATES: Updated translator instructions and uploaded a new release tarball with build fixes.
09.09.2010 Request to support voting in GNOME Bugzilla
These days I often have a hard time to keep up with the tasks on my TODO lists, but I do manage to sneak in a spare hour here or there to look into code I authored sometime ago and that’s waiting for maintenance attention. For projects like Gtk+/GLib it’s incredibly hard to figure a good start and order for bug processing if time is sparse and the number of bugs is flooding you.
Other projects on the net use issue trackers that support user voting of individual requests, here are two examples:
Of course I do realize that we have priority and severity fields in GNOME Bugzilla, but those are for a different purpose than polling the public opinion on which bugs should be fixed best/next, or which bugs have the largest pain impact on our user base.
At least for me, a publicly open voting system for GNOME Bugs would be immensely useful to judge where it’s best to concentrate my development efforts.
30.08.2010 Rapicorn release 10.08.0 available
Rapicorn 10.08.0 is available for download:
http://rapicorn.org/dist/rapicorn/rapicorn-10.08.0.tar.bz2
Rapicorn is an Experimental UI Toolkit. Most things in a toolkit implementation will benefit from proper application of modern technologies (e.g. pthreads, XCB, Cairo, compositing, IDL, XML notation, path evaluation, DSLs, unit tests, SVG). Rapicorn is developed on this base with the aim to significantly improve developer efficiency and user experience.
This release contains a multitude of new features like Python bindings, an automated test suite, myriads of bug fixes and small improvements.
Homepage: http://rapicorn.org/ Downloads: http://rapicorn.org/dist/rapicorn/ Feedback: http://rapicorn.org/mailman/listinfo/rapicorn-list
Updates in Rapicorn 10.08.0:
29.07.2010 Lanedo at GUADEC
Like every year, the entire Lanedo Crowd is currently attending Guadec. If you’re around as well, we can strongly recommend attending one of the talks we’re giving on:
Feel free to approach us for a chat or for handing over your CV.
25.06.2010 Using distcheck with ccache + colorgcc
Waiting for unit compilations to finish during development, particularly with G++ and heavy optimizations can be quite time consuming. A run of make distcheck
escalates the problem, because all files during a dist
need to be rebuilt. Small errors triggered late in the dist
build might require several time consuming restarts of the build process.
With ccache, a tool exists that can majorly speed up this process. I’ve been using it successfully for several years now. A related development aid is colorgcc which is a colorization wrapper for gcc. This also is under heavy use for my development. It turns out that some tweaks are needed to get it working together with ccache though.
Here’s how to use the tools in combination to speed up regular project builds and also distcheck
:
~/.ccache
which might not be the best choice for network homes or encrypted homes. Using /tmp
is also suboptimal since it is usually cleaned upon reboots. So I’d recommend to put this into your .bashrc
:
export CCACHE_DIR="/var/tmp/ccache-$USER"
This will retain the compiler cache across reboots in /var/tmp
.
To briefly summarize its effects:
ln -s colorgcc colorg++ ln -s colorgcc colorgcc-4.4 ln -s colorgcc colorg++-4.4
Invoking the script through those links will cause it to strip the ‘^color’ prefix and invoke the respective compiler.
/usr/bin/ccache
will be used to wrap the compiler invocation if it exists. rm -f config.cache ./autogen.sh CC=colorgcc-4.4 CXX=colorg++-4.4 nice make all -j4
distcheck
builds:
CC=colorgcc CXX=colorg++ nice make all distcheck
Finally, you might want to tweak the colors of colorgcc’s output which can be adjusted in /etc/colorgcc/colorgccrc
. FYI, here’s the color setup I prefer to use in a black terminal window:
srcColor: bold white introColor: bold magenta warningFileNameColor: cyan warningNumberColor: bold cyan warningMessageColor: yellow errorFileNameColor: cyan errorNumberColor: bold cyan errorMessageColor: bold yellow
UPDATE: Fixed ccache default dir thanks to anonymous.
23.04.2010 Doxer release 10.04.0 available
Doxer 10.04.0 is available for download:
http://rapicorn.org/dist/doxer/doxer-10.04.0.tar.bz2
Doxer is a documentation tool initiated originally for generating source code documentation. This is the first public release of Doxer as a separate package (it has been included in other packages previously).
This release contains a wiki markup parser, a corresponding HTML generator, and a Drupal input format module. The markup syntax is designed to cover the feature set required to write source code documentation and general purpose documents. The parser and HTML generator have a strong focus on robustness to support the full range of user sophistication found on general purpose websites. An extensive test suite accompanies the development.
Homepage: http://rapicorn.org/doxer.html Download: http://rapicorn.org/dist/doxer/ Wiki Markup: http://rapicorn.org/DoxerMarkup.html Feedback: http://rapicorn.org/mailman/listinfo/rapicorn-list
User visible features in Doxer 10.04.0:
14.09.2009 OSiM 2009
Together with Martyn Russell, Carlos Garnacho and Kristian Rietveld, I’m attending OSiM this week. None of us has been here before, so we’re quite curious about the conference and will keep our eyes open.
My schedule still has some holes, so if you would like a chat at the conference, drop me a line and we can arrange a meeting.
PS: Yes, I’ve seen Alex recent work and will take a look once I’m back from the conference.
09.04.2009 Gtk+ 3 Roadmap Participation
Lots and lots of things have been going on around me lately, but that’s best left for other posts if I ever get around to do them.
A few months ago, I’ve sat down with quite some help by others and collected the input and feedback around Gtk+ 3.0. The outcome of that was a first Gtk+ 3 Roadmap draft that was sent around to the core team.
After some recent poking, the draft has now been posted on the Gtk+ development list, here is the Gtk+ 3 Roadmap Draft Announcement.
I’d like to thank everyone who participated in the fruitful discussions leading to this and particularly Stormy and Dave Neary for their suggestions on the post-draft process.
Cody Russell has kindly volunteered to wikify the roadmap, so future alterations will be easy. I much appreciate his initiative, especially because I can’t foresee to have much time around the roadmap personally in the near future.
The roadmap draft is best discussed on the mailing list and provided online here: Gtk+ 3 Roadmap Draft
This roadmap is also a call for participation to all developers and contributors.
If you have an interest in Gtk+ 3, this is the time to participate in constructive discussions around the roadmap or sign up for one of the many development tasks.
I sincerely hope this is helpful for everyone.
Es ist nicht deine Schuld daß die Welt ist wie sie ist.Es wär’ nur deine Schuld wenn sie so bleibt.
– Die Ärzte
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!