Snett 0.0.2
Posted at 2006-04-07
Just released Snett 0.0.2. No major new features, but this one will work with DrDoolittle just fine \o/
XMMS2 Ruby bindings API breakage
Posted at 2006-03-12
Dan "puzzles" Chokola recently convinced me that the naming choices for the XMMS2 module and class in the Ruby bindings isn't quite perfect.
We used to have a module called "XmmsClient" that holds a class also called "XmmsClient".
The module has been renamed to "Xmms", and the class is now simply called "Client".
xmms2-scrobbler, Euphoria (cough) and Snett have been updated already. So if you see any error related to the module/class names, make sure you run the latest code of everything :)
Cleaning up Ruby-EFL
Posted at 2006-02-22
Wow. I wrote most of Ruby-EFL (that's everything but Ruby-EET :P) in summer 2004, when I knew close to nothing about Ruby's internals and its C api. It shows. I recently started writing another application with it, and noticed that you couldn't even inherit from Ecore::Evas::SoftwareX11, for example. That's because I implemented Class.new for all of the classes instead of writing a proper initialize method. Fixing that up led to some great code cleanup, and I'm very happy with the codebase now. These changes are fully backwards compatible, too.
The API has changed for Ecore::EventHandler. You now add event handlers like this:
Ecore::EventHandler.new(Ecore::SignalExitEvent) { |ev| ... }
ie you just pass the event class instead of a stupid constant :)
The next thing I poked at is the Evas::Smart API. Not sure what I was thinking when I wrote the Ruby class back then...
Now it works like this:
# Inherit from Evas::Smart
# Done :D
The name for the smart class will be generated from the class path of the Ruby class. That way you cannot customize it but I don't think anyone would want to do so anyway.
Sorry 'bout the API b0rkage, but I think you'll agree that it's mucho better now :)
Update
Whoops, I forgot to write about how it's now possible to define Ecore events in Ruby :)
It's really easy, look:
class SomethingEvent < Ecore::Event
attr_reader :foo, :bar
def initialize(arg1, arg2)
super()
@foo, @bar = arg1, arg2
end
end
To raise that event, you'd call:
SomethingEvent.raise(arg1, arg2)
Isn't that nice? :)
Poking at Mesa
Posted at 2006-02-12
Some weeks ago I started playing Neverwinter Nights, to put my shiny new r300 graphics card to some use.
NWN is working quite well with the r300 DRI driver, but it used to crash on me in some scenes, without any error message.
aet, one of the authors of the free r300 driver told me NWN would reopen stderr to /dev/null, which kinda explained why I didn't see any error message :)
Should anyone else want to track down bugs in Mesa with NWN, I prepared a tarball with a LD_PRELOAD'able library that can be used to stop NWN from that retarded behaviour.
aet has got a fix for that NWN crash, I guess it will hit CVS soon :) Here's the bugzilla entry for the bug.
It's also noteworthy that I also fixed my first real bug in Mesa yesterday, which was noticed while trying to investigate the NWN crash \o/ Now that I have looked at Mesa/OpenGL driver code for some days, it doesn't look as scary as it used to :)
Update
Fixed the URL for nwn-fix_stderr.tar.gz.
Recent hackings
Posted at 2006-01-29
A week ago, I thought about making an XMMS2 client that works like [strange-quark":http://quark.sunsite.dk. strange-quark sits in your desktop's system tray (sometimes wrongly called notification area) and pops up a context menu that offers basic Quark control.
So I hacked up "snett", based on ruby-gtk2. snett doesn't go into the system tray, because the freedesktop system tray spec says only transient windows should go there. Another reason is that there doesn't seem to be any system tray app that implements the balloon message feature correctly. This includes docker, trayer and peksystray. It's worth noting that trayer seems to be an ugly hack of fbpanel and its tray plugin (don't look at the code, it will hurt your eyes). Most of these trayer apps seem to be based on the tray manager code from libegg. Interesting enough, that code seems to implement the balloon message feature, but apparently it's buggy and I couldn't figure out how to fix it.
So at the moment, snett just sits on your desktop as any other (borderless) window, but I think it should go into the panel/dock/wharf/slit.
Anyway, here's a preview version.
To run it, you'll have to apply this patch to ruby-gtk2, which fixes some really nice (read: silly) bugs :)
X11R7.0 on CRUX
Posted at 2005-12-30
A couple of weeks ago, I began porting X11R7.0 to CRUX. It was a good chunk of work (it's 209 ports so far), but it's working nicely.
Having a modular tree instead of the monolithic one is awesome :)
I created a new repository for the X ports, it's available via httpup
Installing these ports manually is not recommended, use "prt-get depinst xorg" instead :)
Let me know if there are any problems.
Site reworked again
Posted at 2005-12-30
So I reworked code-monkey.de again - it's now powered by Typo.
Subversion repositories are down for the moment, but will be available again shortly.
Switched to e17
Posted at 2005-10-06
Yes, I'm now running e17 too, after being in the Enlightenment development team for about 2 years now. I had to implement a few features to be able to work with it, but now I'm quite happy with it - bye OpenBox.
As you can see on the shot, I'm currently porting pixelhead's Steel Circus to e17 :)
Woobie Edjing goodness
Posted at 2005-09-21
I worked a bit on Redact in the last few days, and I decided they were important enough to release Redact 0.1.5.
Most important changes: ImageDescription#set_border was broken badly, this is fixed now. On the feature side, I added Description#inherit, which works similar to the "inherit" keyword in EDC.
Get your copy now :)
Valgrind support for Ruby
Posted at 2005-09-16
Debugging Ruby extensions with Valgrind is a tedious task, because Valgrind doesn't like Ruby's garbage collector much. Valgrind will print a lot of errors and warnings, which are mostly bogus. This makes it hard to spot the real errors you're looking for.
One way to deal with this is to create a suppression file for Valgrind. Suppression files are used to tell Valgrind to ignore certain errors. For every bogus error, the suppression file has to be extended. Although Valgrind can generate suppression files itself, and I've spend some time on generating a suppression file, I never got a perfect one which made Valgrind shut up about Ruby.
So I wrote a patch for Ruby that tells Valgrind that the memory locations the GC uses are safe to read, which makes it stop bitching about all those bogus errors. The patch is tiny, yet efficient:
Makefile.in | 4 ++--
configure.in | 14 ++++++++++++++
gc.c | 12 ++++++++++++
3 files changed, 28 insertions(+), 2 deletions(-)
Update
I prepared an updated patch.