Sat, 01 Oct 2011
Bugs filed versus the phase of the moon.
One of the more classic jokes about not yet understood bugs is that the phase of the moon is somehow involved in causing it.
Being bored, I decided to spend some time to see whether "date of bug filed" could somehow be correlated with "phase of the moon" for a given source package.
Fast forward an hour of perl experimenting, and here we are:
#!/usr/bin/perl -w
use strict;
use warnings;
use constant PI => 3.1415926535;
use feature "say";
use SOAP::Lite;
use Astro::Coord::ECI::Moon;
my $soap = SOAP::Lite->uri('Debbugs/SOAP')->proxy('http://bugs.debian.org/cgi-bin/soap.cgi');
if (!defined($ARGV[0])) {
die "E: must have a source package!\n";
}
my @bugs = $soap->get_bugs(src=>$ARGV[0])->result();
my $bugsdata = $soap->get_status(@bugs)->result();
my $moon = Astro::Coord::ECI::Moon->new();
my %count = ( 'new' => 0, 'first' => 0, 'full' => 0, 'last' => 0);
foreach my $bug (keys %$bugsdata) {
my $time = $$bugsdata{$bug}->{date};
my $phase = $moon->phase($time);
if ($phase <= 45 * PI / 180 || $phase > 315 * PI / 180) {
$count{'new'} = $count{'new'} + 1;
} elsif ($phase <= 135 * PI / 180 && $phase > 45 * PI / 180) {
$count{'first'} = $count{'first'} + 1;
} elsif ($phase <= 225 * PI / 180 && $phase > 135 * PI / 180) {
$count{'full'} = $count{'full'} + 1;
} elsif ($phase <= 315 * PI / 180 && $phase > 225 * PI / 180) {
$count{'last'} = $count{'last'} + 1;
}
}
say "Number of bug submissions during new moon : " . $count{new};
say "Number of bug submissions during first quarter: " . $count{first};
say "Number of bug submissions during full moon : " . $count{full};
say "Number of bug submissions during last quarter : " . $count{last};
This uses the (not packaged in Debian) Astro::Coord::ECI::Moon perl module.
Use like so:
wouter@carillon:~code/perl$ ./debbugsmoon nbd Number of bug submissions during new moon : 2 Number of bug submissions during first quarter: 10 Number of bug submissions during full moon : 1 Number of bug submissions during last quarter : 3
Apparently there's a reasonable correlation between 'the moon is in the first quarter' and 'people file bugs on nbd'.
Note: no, the above is probably not very scientific. That's not the point.
Wed, 13 Jul 2011
'grass' theme
I got tired of my previous website theme, so I created a new one. And thanks to the miracles of CSS, I didn't have to throw out the old—there's still a 'choose your layout' option in the menu.
Playing with CSS is fun, and this was an ideal opportunity to learn the new features of CSS3. I've used some of those, and did so in such a way that the theme should still be usable under a browser that doesn't speak CSS3 yet (I hope, though I didn't test). I'm calling it the 'grass' theme—if you go check it out, you'll see why—and it's now the default.
While I was at it, I found out about this little features of CSS that I didn't know about earlier, but could be useful none the less:
Using background: inherit is not the same as background: transparent. The latter will render all elements on the site (including floating elements) on top of eachother, while the former will inherit the background of parent elements, but will 'hide' elements that have a lower z-index value on the same location. This is useful if you have position:fixed or position: absolute elements that might overlap with floating elements on small screens.
I'm sure this is old hat to anyone who's done some serious web development (me, serious web development? hah!), but it's news to me.
One thing I haven't found is whether it's possible to use an alpha layer using CSS3. I looked for quite a while and didn't find it, so I suppose the answer is that it can't be done, and you'll have to use a PNG file with alpha values, or some such. Oh well.
In other news, 
. But I
guess that's not a surprise to anyone. Leaving by car, in three days.
That might be a surprise. Still have to pack a shitload of things, and
also find some things. No surprise there—nothing better
for me to do something than an uncomfortably close deadline. Oh
well.
Thu, 26 Aug 2010
include povanim.mk
I was finding myself to be running the same povray command lines over and over again. And then ffmpeg2theora. And occasionally forget to update one or two .png files in the mean time, because I was trying and trying and trying some stuff all the time, and forgot that one frame in the final render. That's silly; that's why we have make.
So I wrote me a makefile.
START := $(shell grep 'Initial_Frame' $(INIFILE) | cut -d'=' -f 2) STOP := $(shell grep 'Final_Frame' $(INIFILE) | cut -d'=' -f 2) NUMBERS := $(shell seq -w $(START) $(STOP) ) POVFILE := $(shell grep 'Input_File_Name' $(INIFILE) | cut -d'"' -f 2) ifeq ($(OUTPUT),) OUTPUT := $(basename $(shell grep 'Output_File_Name' $(INIFILE) | cut -d'"' -f 2)) endif ifeq ($(OUTPUT),) OUTPUT := $(basename $(INIFILE))_$(basename $(POVFILE)) endif PNGFILES := $(foreach nr, $(NUMBERS), $(OUTPUT)$(nr).png) LEN := $(shell echo "$(STOP)" | wc -m) $(OUTPUT).ogv : PATTERN := $(OUTPUT)%$(LEN)d $(OUTPUT).ogv : $(PNGFILES) ffmpeg2theora -f image2 -i '$(PATTERN)'.png -o $@ $(OUTPUT)%.png : ONAME := $(OUTPUT) $(OUTPUT)%.png : INAME := $(INIFILE) $(OUTPUT)%.png: $(POVFILE) $(INIFILE) povray $(INAME) -D +SF'$*' +EF'$*' +O$(ONAME) ifeq ($(CLEANFILES),) clean: $(RM) $(CLEANFILES) endif CLEANFILES := $(CLEANFILES) $(PNGFILES)
The first part, to just write the makefile so that it would work, was easy. The second bit, write it so that you can include it in the same Makefile several times and have it generate patterns for the files you need, without having them conflict with eachother, was... slightly harder. But not impossible, apparently, with GNU make.
Use like this:
INIFILE=foo.ini include povanim.mk INIFILE=bar.ini OUTPUT=bar include povanim.mk
with povanim.mk containing the above Makefile
Now just run 'make' or 'make bar.ogv', wait for the rendering and encoding to complete, and you have an animation film. You can even use make's '-j' option to speed up processing by using multiple processors. Which will no longer be useful when povray 3.7 comes out (since that uses multithreading to use all cores with a single povray instance, anyway), but it is for now.
Mon, 19 Jul 2010
Stream-of-image video data and cinelerra
Just so I won't forget, but also to make sure others with similar problems to me don't need to search for several hours before finding it's so simple that it's silly:
If you have a bunch of image files (PNG, JPG, whatnot) that you want to treat as a single clip in cinelerra rather than hundreds (if not thousands) of individual files, the trick is to use a "list file": you create a file with some metadata and a list of all the files that make up the video clip, and import that, rather than the individual files.
If said individual files are PNG files with alpha information, doing so also makes it ridiculously easy to create an animation that only covers part of the screen.
The file format is pretty basic; but over at this page on the cinelerra.org website they list two scripts (one python with GUI, one bash and command-line only) that can generate such a file, given a bunch of image files. That makes it even easier.
I'd also like to note, for the record, that cinelerra outperforms kdenlive in everything but 'transcoding flexibility'. Kdenlive also has support for image lists (and you can create them in the gui rather than having to muck about with external programs or editors), but it has the rather nasty misfeature of doing the equivalent of "Oh, look, what's that? We don't need that, let's throw it away" whenever it encounters alpha information in PNG files.
For full reproducability, it's also possible to generate PNG files with alpha information from povray if you use the +UA command-line parameter, and say something like
sky_sphere {
pigment {
color rgbt <0, 0, 0, 1>
}
}
somewhere in your scene file. Yes, I know, povray is non-free, but it works, and—as opposed to blender—I do know how to use it. Hey, I'm not RMS.
Wed, 07 Jul 2010
Pauly site: redux
A few years ago, when I was still a member of the Jozef Pauly ensemble from Ekeren, at some point I took over maintaining their website. One of the things I did was converting it to drupal, mainly because that would allow other members of the ensemble to help maintaining it.
Of course, such things do not happen automatically; and had I spent some more time on the project, it might've actually worked. But I didn't, so it didn't. Oh well.
One of the main issues with the site as I set it up, was that I hadn't really done a very good job integrating everything. The standard drupal 5 theme looked pretty good, I thought. Slap on a few modules, and done. Unfortunately, I skipped a bit of testing, and as a result, the site didn't really function the way it should've. When this became apparent, I didn't have the time to properly fix it.
During the last few years that I was a member of the ensemble, someone else stepped up to help maintain it. I told him that one of the things that I wanted to do was to upgrade the site to Drupal 6, so as to make i18n a bit easier. But some of the modules which weren't in drupal core made this somewhat harder than needed, and I didn't have the time to investigate in-depth what the issues were.
In the end, I set up a secondary site on a different vhost on the same server that ran drupal6, and gave that guy admin rights there to help convert things to the new site. I planned to lead the effort to make things work; but when I came back not so much later, it turned out that he'd done a very good job already, and that it was probably a good idea to let him finish.
This took much, much longer than expected; but eventually, he's finalized the setup, and it's now live (since a few weeks) on their official site.
This site has content in both Dutch and English, though there is slightly more in the Dutch version: since they're doing a concert trip again this year, there's a blog for their families. Also, some people individually have decided to blog about the whole thing, too, which is... interesting.
At any rate, I think the site looks very, very cool. Go check it out!
I guess we may have to start thinking about doing an upgrade to Drupal 7 some time soon. But, hey.
Sun, 04 Jan 2009
Quake I
Years ago—I think some two years after it was released—I bought me a copy of Quake. I found the original box in a shop that had just one left, and was selling it at a serious discount; I still have the box, with the original artwork.
I didn't have Internet at the time, though, so I never played it online. I did finish the game at one point, though I don't remember whether it was with or without cheatcodes. I'm certain I got very far, though I had a tendency to start using cheatcodes when the monsters I had to pass got too hard for me to actually be able to pass them.
When I did get an Internet connection, Quake III Arena had just been released, so not many people still played Quake I. However, my very own ISP then did have a QuakeWorld server still running, and I fondly remember playing a lot on that server. Since I hadn't heard of +mlook, which enables modern-style mouse-based movement in quake, I was still playing with doom-style controls, that is, keyboard only. At first I got fragged all the time, but it didn't take me long to master this method. I got so good at it that I've won some deathmatch games, with keyboard only. Seriously.
Eventually, however, I migrated to a state where I did not have any Microsoft operating systems installed on my system anymore; and while Debian had a 'quakeforge' package in potato, it was rather buggy; I remember it would reproducibly crash when you would load a particular level from the third episode. I did think about fixing the code, but then I didn't really have the time or expertise to do so, so that never got anywhere. Eventually, it was pulled from the archives; and after a while—around the time when my ISP shut down their quakeworld server—I stopped playing Quake; and though I was sad about it not being installed anymore, I just forgot about it.
Recently, however, I somehow stumbled upon this 'Linux Quake HOWTO' over at tldp, and noticed that apart from Quakeforge, there really are other engines, and there really still is a Quake I community around. With quakeworld servers and everything.
Oh boy.
So I installed this 'tyrquake' a few days ago, and I've now already reached episode 3. Some things are coming back, but others aren't really...
Of course, when I connect to one of those quakeworld servers, I get fragged all over. I'm lucky when I end up with a positive frag count. For reference: in Quake I, you only lose frag points when you kill yourself...
Hah.
To be continued, I guess...
Tue, 09 Dec 2008
The advantages of a home-grown comment system
A while ago, I was investigating the possibility to move blog backend to something else; something like, say, drupal, so that I wouldn't have to maintain it too much myself.
For those who care, this blog is a very strange contraption based on subversion, blosxom, php, and a postres backend for the comments.
I've now dropped that migration thought, for a very simple reason: comment spam.
A while back, the spammers had found my blog, and started placing comments using a bot. They might think that these comments will eventually show up on my website, but that's wrong; I always moderate away spam. First, they posted a few comments. I changed a few details about the form, and the bots (who only went to the POST URL, never checking whether the form they requested was unchanged) failed miserably. Then, they posted loads and loads of comments, in a weird attempt to overrun me with comments. One psql run and one DELETE statement later, those comments were gone -- and one minor form change later, the bots failed miserably, again.
This went on for a few months, until the stupid spammer finally understood that he was wasting loads of his time in trying to post something on a website that wasn't ever going to enable his comments, anyway. Or so I thought.
You see, the thing they're really after is my pagerank. In itself, grep.be is nothing special -- but planet.grep.be is, and apparently some of that pagerank score trickles to the other grep.be subdomains. Or, at least, that's what the spammers seem to think, in case it isn't (I wouldn't know).
When the comment spam on my blog had been silent for a few weeks, I found that the spammers had found my gallery installation, and had posted some several thousand comments there. One DELETE statement later they were gone, but a few hours later some of them were back.
I don't know the gallery source code well enough to pull the same trick here (disable comments until manual moderation), and unless I want to do something like using a CAPTCHA on my gallery site (I don't) or disabling comments altogether (I don't, either), I'll just have to resort to removing these comments from the database.
At least by doing that, I can remove them all in one go. And at least the spammers are easily recognizable. For now.
Perhaps I'll have to look into changing gallery's source code after all... or, perhaps, just use something else. Sigh. Stupid spammers
Tue, 02 Dec 2008
Combining ScriptAlias and DirectoryIndex
Apparently that's not possible. When you say "ScriptAlias /cgi-bin /usr/lib/cgi-bin", everything under /usr/lib/cgi-bin is assumed to be a script. That counts for directories, too; so trying to access 'http://localhost/cgi-bin/myapp' isn't going to work, even if you say 'DirectoryIndex index.cgi' and create a file /usr/lib/cgi-bin/myapp/index.cgi.
Workaround: use mod_rewrite:
<Directory /usr/lib/cgi-bin/myapp> RewriteEngine on RewriteBase /cgi-bin/myapp RewriteRule ^$ index.cgi </Directory>
Sucky, but it works.
Sat, 29 Nov 2008
Enemy Territory: Quake Wars
Great game, that. I used to play Wolfenstein: Enemy Territory a few years ago, but this venture into the Quake2/Quake4 saga I could not miss.
When I saw a poll on on the ET community site about which client people were using, I must say I was surprised. Not by the fact that most people use Windows; not by the fact that more people use the Xbox 360 version than the MacOS version, either. What I was surprised about, was the number of people using the Linux version of Enemy Territory
Linux: 20%
One out of five people in one particular niche prefers to use a free operating system, given half a chance. That doesn't mean one out of five people actually does use Linux, but it does mean they would rather be known as such. Provided the poll isn't forged, that is, but then I don't see what would be gained by that.
Interesting. We're doing better at total world domination than I thought.
Tue, 25 Nov 2008
New hackergochi
... again. This must be my third, in about as many years. The picture from which I made it was taken by Andrew, with my camera. I kindof like it; and I think the hackergochi came out well, too.
No, I'm not planning on changing my hackergochi every year, even though it's turning out to be the case. Oh well.
(Speaking of hackergochi: If people on Planet Grep have a hackergochi or something similar that they'd like to get associated with their posts, please send it to me. Now, preferably :-)
Some mail is welcome in /dev/null. Real mail, however, is welcome at my email address
|
|
|
|