When I search for a particular software application (Wt, CMake, etc), please show me, in the results page, the latest version and a link to the download page (or even to the file, if there is only one file to be downloaded) so that I do not need to enter the website, check if there is a newer version and, if there is, go to the download page. Here you have a mockup:
Mockup of Google showing the latest version of CMake in the results page
I am adding Strigi support to an application using the Strigi socket interface (it’s faster than DBus and, in my case, easier to use). When using the socket interface, Strigi needs to to know where the socket should be created (for instance, /home/pgquiles/.strigi/socket) and it will search for indices in a subdirectory of that directory (/home/pgquiles/.strigi/clucene if using the CLucene backend, /home/pgquiles/.strigi/estraier if using the HyperEstraier backend, etc).
So I was telling Strigi the socket should be created in /home/pgquiles/.strigi/socket and to use the CLucene backend, thus indices would be looked for in /home/pgquiles/.strigi/clucene. Problem is, I was not getting any result back!
std::string socketpath("/.strigi/socket");
const char *homeVariableName = "HOME";
char *home = getenv(homeVariableName);
if( 0 != home ) {
std::string socketpath = std::string(home) + "/.strigi/socket";
}
socket.setSocketPath( (const char*)socketpath.c_str() );
Notice the subtle error with block-scoped std::string socketpath hiding method-scoped std::string socketpath. Due to that, Strigi tried to use a socket from /.strigi/socket (which did not exist) instead of the right one, so it did not even try to look for indices!.
By coincidence, today I arrive to the ACCU website. ACCU is an organisation of programmers who care about professionalism in programming and are dedicated to raising the standard of programming. They publish a magazine (C Vu) and a newsletter (Overload), and organize a yearly conference in Oxford, UK. Slides from last year’s conference are available online and seem quite interesting. Next year‘s conference is from April 22 to April 25 and one of the three tracks will be about patterns.
This is mostly a self-reminder
I attended aKademy 2008 and there are so many things to write about I don’t even know what to start with. I’ll probably write something in a few days, when I’m feeling less sick (thanks to a Flemish waiter who had the OpenBossa guys, Knut and I waiting for almost one hour for dinner, I got a cold).
As you may know, part of my job (and hobby, too) consists on “shaking” software to make it compile on different platforms and with different compilers: I port Linux software which builds with gcc to Windows with Visual C++, or Visual C++ to MingW, or… well, whatever. It’s funny.
Back on topic: Wednesday as the Sun tutorials day and I got immediately interested in Sun Studio. Message to Sun Microsystems people: your installer is so broken on Linux it is impossible to make it work on Debian and Ubuntu (and I guess on anything other than RHEL). The only way I found to “install” SS12 was to download the Express version, remove the sh-code and untar the resulting package. It works but it’s so nasty hardly anybody would try that.
Sun Studio 12 is 100% ISO C++ compliant, which means support for wchar_t is not as good as most applications require nowadays. The best way to overcome this limitation is to use Apache Foundation’s STDCXX to replace SS12’s STL (which is STLport 4 (according to Adriaan, stdcxx would roughly correspond to STLport 6)
Building STDCXX is relatively easy, if you know the tricks:
At the moment, I’m trying to get Wt built with Sun Studio 12 on Linux. Given that SS12 is the compiler of choice for KDE4 on Solaris, I may try to get KDE4 built on Linux with SS12 at a later stage. That would help both the Solaris port and the Linux code.
PS: Hello Planet KDE
I was asked today for the CMake modules for finding ZeroC ICE I had talked about in January. Here they are:
You should use FindZeroCIce.cmake to find everything, or the specific module for each library.
Daniel Phillips, the guy behind Zumastor and ddsnap, csnap, RamBack and many other brilliant developments is doing it again: yesterday he announced the tux3 versioned filesystem (as opposed to ddsnap, which was a software layer on top of any other filesystem) which uses versioned pointers instead of copy on write.
He has also written a preliminary comparison with the HAMMER filesystem by Matt Dillon, which is included in DragonflyBSD 2.0
Now, give up your hesitations and subscribe to the tux3 mailing list. Always keep an eye on everything Dan does because he is really smart!
PS: Digg the story!
ffmpeg has been able to record a screencast on X11 for a long time now, using the x11grab input format and the :0.0 device (for the first instance of X). You’d run
ffmpeg -f x11grab -y -r 12 -s 800x600 -i :0.0+480,200 -vcodec ffv1 -sameq ./out.avi
and get a lossless video of the upper right 800×600 area of a 1280×800 desktop. Easy. You could even transcode to a lossy format (such as H.264, Xvid or Theora) if you had a powerful machine.
On Windows it was not that easy. First of all, Windows is not X11, so x11grab does not work on Windows. You need to use GDI or DirectX but ffmpeg did not have support for GDI or DirectX capture. If you wanted screen-grabbing features in you application, either you developed your own solution (ugly, specially because of the video encoding part) or you used Camtasia Studio (Wink does not include a DLL or ActiveX component you can use in your app).
Ramiro Polla and Christophe Gisquet had a heated discussion about one and a half years ago and some very interesting code was shown. Unfortunately, neither Ramiro’s nor Christophe’s code would work with current ffmpeg.
Today I’ve finally brought Ramiro’s code up to date and it works with ffmpeg trunk. It is not perfect, though: it does not capture the mouse pointer, contextual menus shown as a result of a right-click and video scaling and color is not perfect (ffplay shows the video a little blue-ish). Patch. I’ll try and bring Christophe’s code up to date tomorrow, or fix Ramiro’s code.
PS: A request for ffmpeg developers: please, replace your custom configure script with some cross-platform build system. I like CMake but Scons, Waf and others would also do.
Yesterday I stayed up until 4:30 AM while trying to fix Amarok to works on Windows and when I got it to build it was so late I was too tired to test it. So I fired it this morning and this is the result (click for larger images):
I have tested and it plays MP3, WMA, APE and whatever Magnatune streams on. Built with Visual C++ 2008.
Update Two more screenshots added and in case you were wondering, yes, Plasma works!
Yesterday I fixed the Phonon DirectShow 9 backend for Windows. Now audio and video are available to KDE applications on Windows, which means Amarok 2-trunk works! Currently, it can only play .WMA files (I think I have to install the .ax files for the MP3, MIDI, WAV, etc codecs in the KDE bin or libs directory, I’ll try and fix that next week). In the meanwhile, you need patch #6 if you want to build Amarok on Windows and hear something. Please note I’ve only tried to build it with MSVC2005, not MinGW, not MSVC2008 yet.
This afternoon I started to add Visual C++ 2008 support to the emerge tool to build KDE 4 on Windows. After a few changes, I tried to build Qt 4.4.0 but it failed.
“Why, oh why?” I wondered. I had previously built Qt 4.4.0 using VC++2008.
Turns out on this computer I had installed the Visual C++ 2008 Feature Pack, which adds some nice stuff (if the Office 2007 look tastes nice to you) but also breaks some stuff (mostly MFC but also some math functions).
Fortunately, it’s easy to fix the issue: just do not #include <xmath> and everything will work fine. As the same codebase has to work with many other compilers, I cannot just get rid of that line of code: I need to #if-case it for VC++2008 with Feature Pack.
Unfortunately, there is no easy way to check for “VC++2008 with Feature Pack”. Sure, you can check for VC++2008 by checking _MSC_VER >= 1500. Easy. Unluckily, the only way to check for the Feature Pack is to check _MFC_VER (check you have MFC 9.0.30411 instead of 9.0.21022), which is only defined if you #include <afxver_ .h>. Of course that file #includes many other files, which means some ugly, confusing problem is waiting to happen.
How dumb can you be, Microsoft? Why aren’t you changing _MSC_VER, too, and make my life easier?