Make jekyll fast again: Compile rb-gsl on Arch Linux
In order to make this blog, I use jekyll. It's a great little thing that takes simple text files (using Markdown syntax in my case, more is supported) and turns them into the HTML files your browser is showing you now.
It's great, but awfully slow by default. This blog doesn't have a lot of
content, yet it takes, well, too long for me to have actually waited for it. As
a note nicely indicates though, using rb-gsl will speed things up immensely. It
mentions 10 times faster results, but I'm pretty sure it's (much) much more than
that for me.
Unfortunately, things didn't work so well recently, as I upgraded to ruby 2.0 The cost of living bleeding edge and all that, or something. Anyhow, rb-gsl wouldn't compile no more, making me a sad panda.
kalu 2.0.1 to make sysupgrade work again
Ok, little screw up on my part in kalu 2.0.0, as I removed an init call
(g_type_init()) in kalu-dbus a little too soon. This call has actually only
be deprecated in GGlib 2.36 :)
My bad; Sorry about that.
kalu 2.0.0; pkgclip 1.2.0; pacdep 1.0.0
pacman 4.1 has now hit core, so time for official updates of everything that uses libalpm. For the most part this is only about being compatible with the new API.
Where does your window manager place new windows?
I'm not even sure this falls under the "an itch to scratch" category, it wasn't that much of an itch, but here we are.
Though I don't use the whole DE, I'm using lots of XFCE applications, such as
their window manager, xfwm4 I really like it, but somewhat regularly I would
get a little annoyed by where it would place new windows.
Typical case would be this: I have an application (e.g. file manager) maximized, then I have a gVim window on the left side (the window is about half my screen's size, so I can have two side by side). Then I would open a new terminal; my terminal window is 1/4th of the screen, so I could have 4 opened at the same time.
Naturally, I would expect my terminal window to go on the top-right corner, but it wouldn't go there. Instead, it was on the bottom-left one, i.e. on top of gVim. Now this might not seem to make sense, but it does (of course) if you know how xfwm4 actually works.
Natural Sort Order in C
As Jeff Atwood said back in 2007, "The default sort functions in almost every programming language are poorly suited for human consumption."
This was true then, and remains true today. Working on a project of mine, I needed to sort strings, filenames to be precise, using the famous natural sort order. Because that's how we expect things to work, "foo2" comes before "foo15"
Unfortunately, it's not as simple as one might hope. Most sort functions are indeed pretty bas at this, because while they might do a lot of great things, when it comes to comparing strings containing numbers they still have no understanding of natural order, and use what's referred to as "ASCII order".
strdup/free vs atomic reference counting
As I was working on a little C project of mine, I realized that often times I would have functions returning strings, and couldn't simply return the pointer directly (especially in mutli-threaded app) as the caller needs to be safe using the string.
Typically, what is done is simply return a copy of the string, and the caller must free it once it's done. But this would be happening a lot on my application, and I wondered if it wouldn't be better to save those strdup/free calls, using reference counting.
So I implemented that, and then recently found myself reading about this again, where I'd find both that avoiding those malloc/memcpy calls by using reference counting is good, or that atomic operations (which I used to implement reference counting) could be slow and once shouldn't be afraid of using malloc/free.
And I started wondering...
Wanna try pacman 4.1 (and still use kalu) ?
As you've probably heard, the next version of pacman is coming, and you can try the first RC.
Because API changes are introduced, whatever uses libalpm will require not only to be rebuild against the new library, but is likely to need code adjustements as well.
This was obviously the case for kalu, and everything should be done & ready.
I've been using it for a little while now, and now that rc1 is out I've pushed
it (in the next branch) on
github, so
you can test the next pacman while still enjoying kalu.
kalu goes 1.4.0, speaks French
It's been a little while since a new version of kalu - upgrade notifier for Arch Linux - has been released. But version 1.4.0 is here, and with it comes a bunch a bugfixes, as well as a couple of new features.
dapper 1.0.0 released
Version 1.0.0 of dapper - a simple desktop applications autostarter - has been released. In addition to the bump to 1.0.0 as per semantic version rules, this release is mostly about bugfixes.
kalu could speak your language!
The next version of kalu - upgrade notifier for Arch Linux - is almost ready, and one of the changes it will introduce, is support for internationalization.