Couple of updates are available. Nothing new for pkgclip, just minor tweaks in the code and a little rewrite to move the process of loading packages into a separate thread. This should ensure the GUI doesn't get somewhat unresponsive during that time, and even make things be/feel a bit faster.
As far as kalu goes, a couple new options were added as well as a tweak that might be helpful for those using notify-osd as notification daemons (which has the unfortunate idea of turning notifications with action buttons into non-expiring windows).
And it also includes changes to reflect the latest changes in the API introduced with pacman 4.1.1.
Also, both of those see their option "SaneSortOrder" disappear, since there's
actually a GTK+ option (in GTK3) that allows to do the same (but for all GTK3
applications!), so better to use that:
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.
Ok, little screw up on my part in kalu 2.0.0, as I removed an init call
kalu-dbus a little too soon. This call has actually only
be deprecated in GGlib 2.36 :)
My bad; Sorry about that.
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.
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.
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".
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...
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
you can test the next pacman while still enjoying kalu.
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.
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.