Updating WordPress is kind of pain. I can completely understand why many people do never update their (non-personal) sites. This is not a large WordPress installation. One site, roughly half a dozen plugins, one theme, and that is it. Nevertheless, today I made the effort to back up the data base and files and to update everything. Two plugins failed to work properly afterwards and it took me two hours to fix everything. However, don’t get me wrong. The heaviest problems I got did not originate from one of the plugins itself, but from the way I used it. Meaning, it was my own fault. Still, a pain.

A few weeks ago I wrote about my experience with VirtualBox and hardware-accelerated OpenGL using an Ubuntu guest OS. This post here is an errata.

The downgrade of the GuestAdditions only downgraded the driver of the virtualized graphics card that much, that OpenGL had to fall back to a pure software rasterizer. Thus, this is no solution at all.

With a current GuestAdditions OpenGL works somewhat. However, it does not work very well. You only have to do something in the grey area and everything crashes (including VirtualBox itself if you are lucky). For example, the Freegut usually available as installation packages in version 2.8 does not work at all. The current release candidate in version 3, however, does work.

Honestly, I have no idea if the whole thing works at all. The frame rates are not convincing. To conclude: this is not a solution and for sure not a replacement for a real computer with real hardware and a real installation. Sad.

Life is not easy as a multi-platform developer. This was the main reason for projects like VISlib and the now dead and buried TheLib. But times have changed. The new C++11 standard brought in some very nice and useful classes. Maybe the only thing I really miss right now is IPC, RPC and fundamentally sockets. However, the new threading classes are very nice, like, of course, std::thread.

Well, I am a Windows-software developer. And I continuously port my code to the other platforms, like Linux and sometimes OS X. Thus, there are always some issues when doing something for the first time. For example, when I tried to build my first test program for std::thread unter Ubuntu, I got the std::exception:

Operation not permitted

Well, of course, I linked against pthread. But something must have gone wrong. I asked the almighty Internet, and of course StackOverflow answered: http://stackoverflow.com/questions/9945391/stdthread-creation-throws-exception

In short words: It was an issue of the ordering of the arguments to Gcc, which in my opinion is one of the most annoying issues with the Gcc.

This does not work:

g++ -std=c++0x -lpthread -o test ./test.cpp

This does work:

g++ -std=c++0x -o test ./test.cpp -lpthread

User user405725 nicely summarized it in his comment:

You generally have to specify libraries AFTER object files or they are not pulled in.

Ok. So what about CMake: StackOverflow: http://stackoverflow.com/questions/1620918/cmake-and-libpthread

The different possibilities may also result in different parameter ordering. Following the formal way and using find_package:

cmake_minimum_required (VERSION 2.6)
find_package (Threads)
add_executable (myapp main.cpp ...)
target_link_libraries (myapp ${CMAKE_THREAD_LIBS_INIT})

everything works like it should be.

However, if I try to take the short way out, e.i. by specifying the arguments directly, like:

SET(CMAKE_CXX_FLAGS_DEBUG "... -lpthread")
SET(CMAKE_CXX_FLAGS_RELEASE "... -lpthread")

on my Ubuntu installation with my Gcc I ended up with the wrong ordering of arguments and my test program failed.

I like Cmake. I works. But you should not try to enforce your way of doing things if it is against the way of CMake used to do things. It will work up to some degree, but you will get problems going beyond that point. Just follow the way of CMake and, most of the time, everything will work.

I am back in Dresden. This was by far the most exhausting business travel ever. The Siggraph Asia 2014 was quite alright, but it completely filled up the days in the Chinese time zone. An the work for the German time zone in this week was as submission to the EuroVis 2015, the writing of a funding proposal, of a final project report, and the reading and commenting of a Ph.D. thesis of a friend of mine. There was few time left for sleeping and none at all for anything else. And that fun lasted the full seven days. My flights back to Germany were today, Sunday. From 4 am. Shenzhen time until now 8 pm. German time. And tomorrow morning I will be giving a lecture. I am so looking forward too that.

Every once in a while I face extremely simple tasks for which I don’t see the simple solution. Not long ago I had to concatenate two binary files into a single one. I really didn’t know how to do it without any major efforts on Windows. I thought of many terrible ideas: copying everything onto a Linux machine, using a Powershell script, googleing for a tool, throwing up a small DotNet tool myself. Luckily I decided to google for the problem and not for a tool. As result I learned that Windows can do the job itself. Well, the old DOS commands can, which are still available on Windows:

copy /y /b file1+file2 dest

Embarrassingly simple.

Important! This post is outdated: here is the update.

Some time ago I stopped using dual-boot systems. My work takes place on Windows and is based on the products of that ecosystem. I will not go into details of the holy war between Windows and Linux. Especially since Linux is an integral part of my work as well. The solution currently working best for me is using a VirtualBox Linux installation. From the multitude of distributions I boringly selected Ubuntu for my use. As computer graphics and visualization researcher I obviously like the OpenGL support in the virtualization solutions. This week I set up a new virtual machine and was greeted by this error prohibiting my OpenGL applications to run:

libGL error: pci id for fd 4: 80ee:beef, driver (null)
OpenGL Warning: glFlushVertexArrayRangeNV not found in mesa table
OpenGL Warning: glVertexArrayRangeNV not found in mesa table
OpenGL Warning: glCombinerInputNV not found in mesa table
OpenGL Warning: glCombinerOutputNV not found in mesa table
OpenGL Warning: glCombinerParameterfNV not found in mesa table
OpenGL Warning: glCombinerParameterfvNV not found in mesa table
OpenGL Warning: glCombinerParameteriNV not found in mesa table
OpenGL Warning: glCombinerParameterivNV not found in mesa table
OpenGL Warning: glFinalCombinerInputNV not found in mesa table
OpenGL Warning: glGetCombinerInputParameterfvNV not found in mesa table
OpenGL Warning: glGetCombinerInputParameterivNV not found in mesa table
OpenGL Warning: glGetCombinerOutputParameterfvNV not found in mesa table
OpenGL Warning: glGetCombinerOutputParameterivNV not found in mesa table
OpenGL Warning: glGetFinalCombinerInputParameterfvNV not found in mesa table
OpenGL Warning: glGetFinalCombinerInputParameterivNV not found in mesa table
OpenGL Warning: glDeleteFencesNV not found in mesa table
OpenGL Warning: glFinishFenceNV not found in mesa table
OpenGL Warning: glGenFencesNV not found in mesa table
OpenGL Warning: glGetFenceivNV not found in mesa table
OpenGL Warning: glIsFenceNV not found in mesa table
OpenGL Warning: glSetFenceNV not found in mesa table
OpenGL Warning: glTestFenceNV not found in mesa table
libGL error: core dri or dri2 extension not found
libGL error: failed to load driver: vboxvideo

Surprisingly a short google search did not came up with a good solution. I only found some indications that the error is related to the VirtualBox guest additions and that one should always use the most recent ones. Of course I did use the most recent ones.

After some more searching I learned that the error is related to rather new OpenGL extensions. These extensions seem to be too new for the graphics drivers of the virtualization. There seems to be a conflict between the extensions the virtual graphics card reports supported and what the vritualization Linux graphics driver makes of it.

I was actually able to solve the error by downgrading my guest additions to an older version. Using version 4.3.12 everything works fine. With any newer version up to 4.3.18 I get that error. So the Iso image of that guest additions will stay on my hard drive. I will wait if newer version of the guest additions or updates of Ubuntu will be able to fix that problem for good.

Inter-process communication always was a pain, at least when dealing with platform independent C++ environments. I have tried many things and none was really satisfying. Either the performance, the usability or the maintainability and extendibility were not acceptable. I never found a method I would want to build on.

Without doubt, a de-facto standard are web services. But, from my perspective, the perspective of a visualization and computer graphics guy, the overhead, in terms of runtime performance and development, are not acceptable. I am not talking about data rates, architecture or latencies alone. But take all these things together and apply then to interactive visualization and you get a solution to 90% of all your problems. The remaining 10%, however, are painfully bad. So you are forced to introduce a second communication channel. And so, you start implementing everything twice, again. Programming in computer graphics and interactive visualization is always so pitiably far away from nice software engineering. But I have chosen this problem as one of my research fields and I have chosen to find fitting solutions to such problems. It is an extremely fruitless work, but to me it is an important topic and I believe it is worth the work.

One rather new idea crawling around in my head is about JSON-RPC. The protocol is simple, small, trivial, but also a sufficient solution to all technical problems. That is a charming combination. Especially so, because no concrete transport channel is needed. Queries and calls can be transported interleaved in the high-performance communication channel used for the rest of the data. But they don’t have to be. I believe, looking at this approach as interpreting and managing layer only makes sense.

And talking about implementation, here we have the catch. I don’t want to claim I did an exhaustive search for implementing libraries. But the libraries I have seen so far were of disillusioning low quality. While, as foundation, jsoncpp and jansson left good impressions I cannot say that about JsonRpc-Cpp and libjson-rpc-cpp. I don’t want to badmouth these projects, but they are not fitting for my plans. For example, it seems impossible to compile theses as Dlls on Windows without massively altering their source code.

Honestly, I do not know where this path is taking me. Well, within the next few weeks it will take me nowhere. I have plenty of other important problems on my desk to keep me occupied. But the idea remains interesting and I will continue on this topic.