Posted by Diego "Flameeyes" Pettenò
Mon, 17 Dec 2007 22:16:00 GMT
As you may or might not know, I maintain the net-irc/rbot package in Gentoo. In particular, I’ve been focusing on the 9999 live SVN ebuild, as upstream still hasn’t released some new versions since 0.9.10 which is quite old.
I’ve also been using the 9999 ebuild on the production server, and that’s where ServoFlame stays up from, so it’s usually quite tested.
Today I added two new USE flag in a new revision of the ebuild: translator and shorturl. These are present so that the dependency on dev-ruby/mechanize and dev-ruby/shorturl that the two plugins need.
What I’m looking forward to in rbot is to allow users to choose which plugins, needing an external package, should be installed, and which not, just by setting the proper USE flags.
This should make rbot administration even simpler for Gentoo users, isn’t that great? Well that and the fact that you need not to check which gems need to be installed, as Portage will take care of everything for you.
Posted in Gentoo, English | Tags rbot, Ruby | no comments
Posted by Diego "Flameeyes" Pettenò
Mon, 17 Dec 2007 18:23:00 GMT
valgrind has a very nice way to output information in parseable form for the memcheck (the primary) tool: XML.
You don’t really need a custom parser, you just need to read the correct elements and attributes, and you’re done. The format seems actually to provide enough extensibility so that it can be used for every tool, and so I expected.
Starting from this I decided to start working on a new valgrind frontend, in Ruby. To begin with, I started writing the abstraction, and a test suite so that I could make sure what I wrote was what I was expecting to get.
Unfortunately, when I decided to start adding the support for a second tool, to see that my code was doing the right thing with different tools, I discovered that helgrind does not output XML. Nor does massif.
So it seems that to write a frontend to something more than just memcheck (which is what Valkyrie supported), you’d have to parse the plaintext output, which is quite more difficult.
I suppose this is why Valkyrie stopped at supporting memcheck..
At this point, I suppose that to write an Helgrind frontend I’d have to hack at valgrind itself to add XML output to the tool. I think I’ll try that soon enough.
Posted in English | Tags Frontends, Helgrind, Ruby, valgrind | no comments
Posted by Diego "Flameeyes" Pettenò
Mon, 17 Dec 2007 00:22:00 GMT
No, I’m not going to criticise the ecompress implementation, actually I’m quite glad that ecompress was created, because it’s that, which allows what I’m going to write here ;)
So, on most modern systems, with the exception of servers and laptops, one of the problems you most rarely have is running out of disk space. Standard 3.5” SATA drives are cheap and so rarely you have to save disk space. So while I think it’s still a good default to compress manpages, info pages and documentation, most users don’t really need that.
So if you don’t mind using some more space for documentation and man pages, you might want to try this on your make.conf:
PORTAGE_COMPRESS=""
This way ecompress will be a no-op and will skip on compressing the doc, installing it non-comrpessed, using more space, but less (not much less, but still less) CPU time during build.
One nice advantage is that also displaying manpages will be faster as it doesn’t have to decompress them on the fly ;) (and bzip2 can be quite slow to decompress even on modern computers, when compared to gzip).
Posted in Gentoo, English | Tags BZip2, Manpages, Tricks | 9 comments
Posted by Diego "Flameeyes" Pettenò
Sun, 16 Dec 2007 23:56:00 GMT
So today I updated my system and seen that the new nmap version features a totally new frontend, written in Python with pygtk. While this bothres me a bit because I had to install the pygtk package with its siblings, I actually find this an interesting and useful change.
I say this because, well, frontends don’t need to be fast or to have a tight memory usage pattern; most of the times, frontends only have to take care of user interaction, and the user interaction is neither cpu, nor memory, nor I/O bound, it’s user bound.
Scripting languages don’t usually suffer from architecture problems, like endianness of variables, or missing definitions or include files moved around; well, the base interpreter does suffer from these problems, but it’s one package instead of every package.
Also, scripting languages usually makes it easier for users to change the frontends if they need, which is certainly an advantage for the part of the program – the frontend, as said – that faces the user.
This made me think about writing a new Valgrind frontend; my language of choice would certainly be Ruby, the problem is: which GUI libraries would I be using?
An year ago I was dead set on Korundum, KDE’s Ruby bindings, but I don’t think this is feasible now. The reason is of course tightly related to the KDE4 development: writing on Korundum makes little sense, considering that the focus is now KDE4, but KDE4 itself is too young to write the frontend using that. Plus there is one big problem with QtRuby: the Qt3 and Qt4 Ruby bindings install the same shared object, with different APIs, making a Qt3 Ruby program incompatible with a system where Qt4 Ruby is installed. And writing the frontend in pure Qt4… I’m not sure about that.
The alternative is to use ruby-gtk2. Even if I don’t like the GTK C interface myself, the Ruby version seems nicer to me. And with Nimbus I can finally stand GTK2 interfaces. I should probably try this out, it might be good enough to go.
Actually, with little work it’s likely that I could write a pure-Ruby abstraction for a valgrind frontend, and then two interfaces, one in GTK2 and one in Qt4. This is another nice part of scripting languages: you usually have the basic set of objects not being part of the libraries used (QString, GString, …) and you can more easily share code between Qt, GTK, NCurses, whatever you want.
So, anyway.. I need something to keep my mind busy tonight, as I’m having some real-life trouble (no, not health trouble, just… love trouble :/), so I’ll probably start tonight to work on something.
Posted in English | Tags Frontends, Korundum, NMAP, Qt, Ruby, valgrind | 5 comments
Posted by Diego "Flameeyes" Pettenò
Sat, 15 Dec 2007 12:41:00 GMT
So, as Albert already blogged Valgrind 3.3.0 was released, with a new Helgrind (mutex analyser), a new massif and some new tools too.
So it’s great, having a new version of such a powerful debugging and analysis tool, is quite nice for developers; it’s also one of my main tools for xine-lib’s testing.
There are, though, some bad news that go with the current release though.
The first problem is that the newly rewritten massif now only outputs a way different information output through a ms_print script; there isn’t a graph image anymore, the only graph is in ASCII-art, and I really fail to interpret it. I hope that in the next weeks someone (maybe me) will write a script that produces the nice graph images for the new massif too.
The second problem is that helgrind doesn’t seem to work properly with xine-lib at least, as it’s stuck after not much time from the start; I’ll have to look deeply into it.
The third, and hopefully last problem, is that valkyrie is not updated since August 2006, so it’s practically impossible that it supports the new options provided by the new memcheck too, while malloc-fill is something I’d very much like to use to check xine-lib.
I’d say we need better valgrind frontends! :)
Posted in English | Tags debugging, valgrind, Valkyrie, xine | no comments
Posted by Diego "Flameeyes" Pettenò
Fri, 14 Dec 2007 08:35:00 GMT
I’m probably going to mail this later today on xine-devel, but in the mean time I want to at least express my thoughts so that I can straight them up.
As you probably know if you follow xine development, xine-lib has an internal copy of FFmpeg. The current version in xine-lib-1.1 is no more updated for a while, because updating it is actually quite some work, as the build system from FFmpeg is not used at all.
On 1.2 the situation is simpler as I’ve wrote an integration between xine and the FFmpeg build system, which makes updating it almost a piece of cake. Still, it’s some work to do.
There is another point to consider, that is that most distributions nowadays don’t use the internal copy of FFmpeg at all, preferring to install their own FFmpeg in system, and then using that.
So I’m considering the idea of removing the internal FFmpeg from xine-lib entirely. Why this? Well, it makes less work for us xine developers, and should better follow what FFmpeg developers prefer too.
To make it easier for casual users who install by source, we could simply provide tested snapshots of FFmpeg (maybe coordinating with distributions too), and document how to build that and link to that statically without actually installing it on the system (thanks to pkg-config that should be quite easy, and thanks to Mans, probably headers will soon be easier to handle too).
Another reason why I’d rather get users to build FFmpeg outside xine-lib, beside the fact that by using more libavutil functions more than just the FFmpeg plugin would be linking to libavutl, is that this way it would be simpler for frontends like xine-ui to link to it. Why should they? Well, libavutil again. The new versions provide av_strlcat function, for instance, which I could use in xine-ui without having to use a BSD replacement when using GLIBC.
I think xine (and xine-ui) should really try to move away as much code as possible from the main source trees because, at the moment, there aren’t enough people who can handle the amount of code present.
This should go on the same pace as writing documentation for the code that is there and remains there, but even that is quite lacking.
I hope to find my motivation back by doing this kind of cleanup, which is actually quite funny to do, in some masochistic way. I’m not sure if it will, but I’ll at least try.
Posted in English | Tags ffmpeg, Motivation, xine | 1 comment
Posted by Diego "Flameeyes" Pettenò
Thu, 13 Dec 2007 16:44:00 GMT
As the title says, I’m losing motivation to work on Free Software.
Why? Well, there are lots of factors, some depending on what happened to me this summer, some just general tiredness, and then there’s the Free Software environment as a whole.
So the great news of these days is that TrollTech released Phonon backends, for all the three operating systems they care to suppot (Linux, OSX and Windows.. the fact that Qt and KDE are available for FreeBSD, NetBSD and other Unix-like Free Software operating systems is often ignored, but let’s say that the Linux support is some kind of UNIX support, even if it’s not always true). Of course, they can’t use GPL backends for those, as they’d be unable to use them with their commercial Qt releases, so instead of contributing to the development of Phonon-xine (and maybe xine itself), they just decided to go with GStreamer.
I don’t like GStreamer, and I never tried to hide that; I don’t like the architecture, the complexity, but less of all I like the way Fluendo makes money from Free Software users thanks to the whole software patents idea.
Why should this change anything for Phonon-xine? It’s still the main backend for kdelibs (for now), but you all know how the binary distributions don’t like to risk with software patents, so I wouldn’t be surprised if they all would just ignore the presence of Phonon-xine and decide to go with the GStreamer backend by default.
So I’m losing motivation, because I see politics and money talking more than users lately, and I don’t really like this (and I like it even less when the same persons who think this is just fine criticise the proprietary software developers for doing… well just the same; you can expect that developers focusing on proprietary solutions would like to make the money talk (and get money), just as they plan, but if you define yourself a free software developer, or even worse a free software advocate, and you’re easy to give up users’ rights for politics, then you’re just an hypocrite – and no I’m not referring to anyone in particular, just a generic idea I see around).
I’ll probably just resign as a xine developer soon (while of course keeping the tracker available, now that it’s up); I’m also considering just looking for a different kind of job area I can take, selling off the devboxes, buying an iMac and use the computer just to surf when I have nothing else to do, and to listen to music. As it is I’m wasting my time and my life on stuff that just doesn’t matter for anyone anyway.
Posted in English | Tags FreeSoftware, GStreamer, KDE, Life, Motivation, Phonon, xine | 8 comments
Posted by Diego "Flameeyes" Pettenò
Tue, 11 Dec 2007 22:50:00 GMT
So, after removing a few thousands (yes, thousands) lines of code in a new xine-lib-1.2-plugins-changes branch, I’ve decided to start working on yet another branch. This time the name for the branch is xine-lib-1.2-libavutil.
As the name suggests, it’s a branch designed to get support for libavutil in xine-lib, basically replacing xine-lib’s code with libavutil whenever possible.
Right now I have at least three features used by xine’s plugins that I can factor out to libavcodec: CRC, SHA1 and Base64 implementations.
CRC is currently used by the A52 decoder, by DVB input and by the TS demuxer; libxine carries an implementation, while the A52 decoder uses a52dec’s internal code to perform CRC16 instead. In the new branch all these three plugins use libavutil, and link against it, sharing the CRC data table and the code, while the implementation in libxine is gone, disappeared.
SHA1 is used by CDDA plugin, which is also one of the two users of Base64. SHA1 and Base64 are used to handle CDDB fetching. The current CDDA plugin has its own implementation of both, while on the new branch it once again uses libavutil. The result? The shared object of the plugin is 20KB smaller than the original.
Today’s balance is not bad: two files removed from the main branch (dummies used by directfb to build the X11 and FB versions), five files gone from the -avutil branch, and a few thousands lines of code gone from the -pc branch.
Tomorrow I’ll see if I can get xine_xmalloc replaced with av_mallocz; this is going to be a huge change, and I’m not sure if I want to take that step yet, but it would be a nice thing to get rid of all the implementations in xine-utils that we don’t really need as part of xine.
Oh I have a patch to send to ffmpeg-devel now, too.
Posted in English | Tags ffmpeg, Optimisation, xine | 1 comment
Posted by Diego "Flameeyes" Pettenò
Tue, 11 Dec 2007 10:13:00 GMT
So one of the targets for 1.2 release of xine is to actually get the plugin interface to shape. At the moment it has a lot of small issues needing to be addressed, to begin with the cache.
Anyway, today’s optimisation is geared toward removing two functions from every plugin: get_identifier and get_description.
Those two functions return, as the name suggests, the identifier and a localised description for the plugin. As it stands, they just return a literal (or the return of a gettext call).
I’ve now opened a new branch that replaces the two functions in the plugin classes structures with simply two pointers, that is two strings. This way they can be accessed without adding a call when using it, and also saves adding the actual functions to the plugins.
I first thought of adding the description inside the plugin_info_t structure that’s exported by the shared objects themselves, using N_() to allow internationalising the strings, and then call gettext() when accessing it. Unfortunately this doesn’t work out well for plugins that are injected by the frontend (like Amarok and Phonon do), as they don’t have plugin_info_t and they wouldn’t have the strings present in xine’s catalog.
So while using just one gettext call in libxine for the description would be, performance-wise, simpler, at the moment I just can’t do that, I will investigate if I can tell gettext to just search an extra catalog if none is found though, to see if I can return to that idea.
Anyway, the result compared with codiff (from dwarves package, that actually needs to be bumped), is quite nice, for libxine itself it’s 158 bytes of code less, okay just crumbles, but still nicely done without too much effort. For the plugins it’s 32 bytes each; probably would be more once I get rid of the various gettext calls in the plugins, although that will reduce the improvement for libxine (in the balance, though, it will still be gain).
I also have a couple more plans to change the plugins and reduce the resource waste, but that will come later on today, probably.
Posted in English | Tags Optimisation, plugins, xine | no comments
Posted by Diego "Flameeyes" Pettenò
Thu, 06 Dec 2007 18:05:00 GMT
As I blogged yesterday, I had some trouble with Wine while trying to play Total Annihilation: Kingdoms.
Today I want to blog about the solutions of the troubles I exposed yesterday.
The first problem is the one with PulseAudio, as I said I hit a bug already opened in Bugzilla about the ESounD wrapper that didn’t work. I fixed this today in Portage with 0.9.8-r2 and -r3 (respectively standard and experimental baselayout 2 init script). I prepared the patch to be applied to the upstream repository too but I want to discuss it with Lennart first. So if you want the ESounD wrapper for PulseAudio, make sure to use a new enough version of it. Older versions (0.9.7 series and earlier) aren’t affected by the problem as far as I know.
The other problem was with TA:K fullscreen not working natively, and the map scrolling not working properly when using the windowed mode. The solution, as I foresaw yesterday, is to change the X settings so that Wine’s virtual desktop is ran fullscreen. To do this I decided to simply start the X instance with just xterm running, and then run wine on TA:K executable, after setting the virtual desktop to my desired resolution (1280×1024). I actually had to change the X resolution too, as I’m using two monitors and thus I had to switch from 2560×1024 to a single monitor duplicated.
When playing the game at the same resolution as wine’s virtual desktop and of Xorg itself, you get a “virtual fullscreen”that is 100% working: it’s fullscreen so I can’t move the mouse outside the game window, and thanks to the fact I am fullscreen I don’t even get distracted while playing.
Unfortunately I’m afraid I won’t be able to enjoy it for long, I need to start working on another project now (for my job), even if I’m quite tired, and today I really didn’t feel well.
I hope the Wine trick can be useful to other people too. Maybe I’ll be able to make a script that actually sets that up and runs the game you ask it to.
Posted in Gentoo, English | Tags ESounD, PulseAudio, TAK, Wine | 4 comments
