Category: My Tools

Post about my little Software Tools

We updated MegaMol to use cmake to build on Linux OS. This greatly improved the build process on Linux. But this also makes some more uncommon scenarios difficult to realize. For example, cmake usually automatically detects required dependencies. But, in some scenarios you need to override this magic.

In this article I show how to compile a second MegaMol on a system on which a MegaMol already has been compiled and installed. This is useful when working with experimental versions.

VISlib and visglut

First off you build the visglut the usual way. I assume here, that the installed MegaMol uses a different visglut as the one you want to build now:

mkdir megamol_x2
cd megamol_x2
svn co https://svn.vis.uni-stuttgart.de/utilities/visglut/tags/forMegaMol11 visglut
cd visglut/build_linux_make
make

If everything worked you can find the following files:

in megamol_x1/visglut/include:

GL/freeglut_ext.h
GL/freeglut.h
GL/freeglut_std.h
GL/glut.h
visglut.h
visglutversion.h

and in megamol_x2/visglut/lib:

libvisglut64.a
libvisglut64d.a

If so, let’s continue with the VISlib:

cd megamol_x2
svn co https://svn.vis.uni-stuttgart.de/utilities/vislib/tags/release_2_0 vislib
cd vislib

Now, there is the first action which is different from the default build process. As usual we will use the script cmake_build.sh. This script, however, per default registers the build directories in the cmake package registry. This enables cmake to find this package in its build trees. In this scenario, however, we do not want this special build to be automatically found, because we do not want to get in the way of our system-installed MegaMol. We thus deactivate the package registry.

This command configures and builds the VISlib, both for debug and release version:

./cmake_build.sh -dcmn

As always, if you encounter build problems due to the multi-job make, reduce the number of compile jobs:

./cmake_build.she -dcmnj 1

Note that I do not specify an install directory. I do not plan to install this special MegaMol. I just want to build, for example for a bug hunt.

MegaMolCore

It’s now time for the core.

cd megamol_x2
svn co https://svn.vis.uni-stuttgart.de/projects/megamol/core/branches/v1.1rc core
cd core

We first test the configuration by only configuring release and not building anything:

./cmake_build.sh -cv ../vislib -C -DCMAKE_DISABLE_FIND_PACKAGE_MPI=TRUE

Note that I also disabled MPI-Support here. The system I am building on has MPI installed, but I don’t want this MegaMol to use it.

The output should contain this line:

-- Found vislib: /home/sgrottel/megamol20150726/vislib/build.release/libvislib.a

This points to the right vislib, the one we specified. So all is well. We can build MegaMol, again without registering it’s build trees in the cmake package repository:

./cmake_build.sh -dcmnv ../vislib -C -DCMAKE_DISABLE_FIND_PACKAGE_MPI=TRUE

When all worked you got yourself the binaries:

megamol_x2/core/build.debug/libMegaMolCored.so
megamol_x2/core/build.release/libMegaMolCore.so

MegaMolConsole

Get yourself a working copy of the console:

cd megamol_x2
svn co https://svn.vis.uni-stuttgart.de/projects/megamol/frontends/console/branches/v1.1rc console
cd console

Again, we test if everything works by only configuring release and not building:

./cmake_build.sh -c -f ../core

The Console does not register its build tree per default, since no other project depends on the console. So we are fine here.

The output should contain these lines:

-- Looking for MegaMolCore with hints: ../core;../core/build.release;../core/share/cmake/MegaMolCore
-- Found MegaMolCore: /home/sgrottel/megamol20150726/core/build.release/libMegaMolCore.so
-- MegaMolCore suggests vislib at: /home/sgrottel/megamol20150726/vislib/build.release
-- MegaMolCore suggests install prefix: /usr/local
-- Using MegaMolCore install prefix
-- Found vislib: /home/sgrottel/megamol20150726/vislib/build.release/libvislib.a
-- Found AntTweakBar: /home/sgrottel/AntTweakBar/lib/libAntTweakBar.so
-- Found visglut: /home/sgrottel/megamol20150726/visglut/lib/libvisglut64.a

If the directories for other libraries are wrong, for example the AntTweakBar or the visglut use the cmake-typical DIR variable to give a search hint. Remember, relative paths might be confusion. Better use absolute paths. I don’t:

./cmake_build.sh -c -f ../core -C -Dvisglut_DIR=~/megamol20150709/visglut -C -DAntTweakBar_DIR=../../AntTweakBar

But in my case the cmake-magic worked fine in the first place. So, I configure both build types again:

./cmake_build.sh -dc -f ../core

Double check the output. Make sure the core, the vislib and the visglut are found in all the right places. If they are, built it:

./cmake_build.sh -dm

At this point you can quickly test your MegaMol. First open the megamol.cfg configuration file in a text editor and adjust the paths in there to yours. Then run MegaMol:

cd build.release
./MegaMolCon

If this seems ok, and if you have a local graphics card you can run the demo renderer:

./MegaMolCon -i demospheres s

Some MegaMol Plugin

Finally we need a plugin. I go for the mmstd_moldyn:

cd megamol_x2
svn co https://svn.vis.uni-stuttgart.de/projects/megamol/plugins/mmstd_moldyn/branches/v1.1rc mmstd_moldyn
cd mmstd_moldyn

The process is now exactly the same as with the console:

./cmake_build.sh -dcf ../core

The double check the directories for the core and the VISlib. If they are good, build the plugin:

./cmake_build.sh -dm

To test this plugin we go back to the console, and adjust the config file to load the plugin:

cd megamol_x2/console/build.release

Include the following lines in the config file. Obviously adjust the paths to what you need:

<plugin path="/home/dude/megamol_x2/mmstd_moldyn/build.release" name="mmstd_moldyn.mmplg" action="include" />
<shaderdir path="/home/dude/megamol_x2/mmstd_moldyn/Shaders" />

If you now run MegaMol it will try to load your plugin and will report it. The output console should contain something like:

200|Plugin mmstd_moldyn loaded: 11 Modules, 0 Calls
200|Plugin "mmstd_moldyn" (/home/sgrottel/megamol20150726/mmstd_moldyn/build.release/mmstd_moldyn.mmplg) loaded: 11 Modules, 0 Calls registered

And that’s it.

Posted on No Comments Posted in Science, My Tools Tagged with

Today I am presenting another small tool of mine: the ShutdownPlannerGUI

ShutdownPlannerGUI.zipShutdownPlannerGUI.zip Simple GUI for planned Shutdowns of MS Windows
[188 KB; MD5: 45cb64eef13ea47e98a7dcde0773e6f1; More Info]

The basic idea is simple: it is a small GUI, slapped together in C#, around the Shutdown command-line utility. It is about the timer, specifying when the system is going to shut down. The GUI provides several text boxes to conveniently enter the time in hours, minutes and seconds. And that is it.

Posted on No Comments Posted in My Tools Tagged with , ,

Once again, it is time for one of my little tools, which the world does not need (but I do). The idea is simple: think of a series of files in one directory, e.g. music files of a audio book or video files of a TV series. Every once in a while you watch/listen to one of the files and days later you do not remember, which was the last file you have seen. My tool registers to the context menu of the Windows Explorer and provides a simply way of setting a bookmark at the file in the directory. The bookmark is an empty file with the same name, additionally using an extra file name extension). The whole thing is no shell extension, but a simple, normal DotNet application which writes to the right places in the registry. Simple, not elegant, but working.

FileBookmark.zipFileBookmark.zip File Bookmark Utility
[91.2 KB; MD5: bd58a615775c9897ae82536bb678b05b; More Info]

And, just because I can, here is the source code::

FileBookmark_src.zipFileBookmark_src.zip File Bookmark Utility Source Code
[60.2 KB; MD5: 84071f778ccb81b0c39101577a3fa204; More Info]

Posted on No Comments Posted in My Tools Tagged with , ,

The maybe most important coding project of myself which has impact on my private programming as well as on my work is thelib_icon16 TheLib. The basic idea is to collect all classes which we (two friends and myself) wrote and used several times in several different projects over and over again. These classes usually are wrappers for compatibility or convenience around API calls or library calls (e.g. STL, Boost, whatever). That’s where the name of our lib cames from: Totally Helpful Extensions. And, it is just cool to write: #include "the/exception.h".

However, I hear very often: “Why do you write a lib? There are plenty already for all tasks.”

If that would be true, none of us would write programs anymore and we would only “compose” programs from libs. Well, we don’t. Or, rather I don’t. Meaning: TheLib really is helpful. It is not a replacement for the other libs. It’s a complement, and extension.

On Example: Strings!

The string functionality in TheLib is not nearly as powerful as one would required to write a fully fledged text processor. This is not the goal of TheLib. We wrote these functions to provide somewhat beyond basic functionality. The idea is to enable simple applications or prototypical applications to easily implement nice-to-use interfaces for the user.

Especially unter Linux (but also unter Windows) there are usually a total of three different types of strings:

  1. char * or std::string which store ASCII or ANSI strings with locale dependent character sets
  2. char * or std::string which store multi-byte strings, e.g. using UTF-8 encoding
  3. wchar_t * or std::wstring which store unicode strings.

Depending on these types different API functions need to be called, e.g. for determining the length of the string:

  1. strlen
  2. multiple calls of mbrlen
  3. wcslen

On issue that arises between case 1 and 2 is that modern Linux often uses a locale which stores UTF-8 strings within the standard strings. As long as strings are only to be writte, stored, and displayed, this is a great way to maintain compatibility and gain the modern feature of special character availability. However, as soon as to perform a more complex operation (like creating a substring) this approach results in unexpected behaviour als the bytes of a single multi-byte character are threated like independent characters.

Example:

  • Your user is a geek and enters “あlptraum” as input string.
  • This string is stored in std::string using the utf8-en encoding.
  • Your application now wants to extract the first character for some reason (e.g. to produce typographic capitalization using a specialized font).
  • The normal way of doing this is accessing char* first_char = s[0]; and std::string remaining = s.substr(1);
  • Because the japanese “あ” uses two bytes, this results in: “0” + “Blptraum”

This not only applies to japanese characters, but obviously to almost all characters with diacritics. What is even more important: this issue also results in unexpected behaviour when using (or implementing) string operations which ignore case, e.g. comparisons.

Example of changing a string to lower case:

// we will do this the STL-way:
// http://notfaq.wordpress.com/2007/08/04/cc-convert-string-to-upperlower-case/

std::string data;
// contains 'data' is set to "あlptraum" encoded with utf8-en locale

std::transform(data.begin(), data.end(), data.begin(), ::tolower);
// well, content of 'data' is now: "0blptraum"
// ...

To avoid this problem, TheLib internally initializes the system locale for the application and detects if the locale uses UTF-8 encoding. If it does, all TheLib string functions will call the multi-byte API functions to work as expected. In addition TheLib provides some functions to explicitly convert from or to UTF-8 strings (e.g. for file io).

Of course, you don’t need TheLib to do this. You can use another lib (probably. I only know the IBM-Unicode-Lib, which seems like a huge hulk) or you can use your own workarounds or you can ignore such problems as “they will not occure in your application scenarios”. However, having TheLib doing the job is just handy. Nothing more.

Posted on No Comments Posted in My Tools Tagged with

Software should solve problems. Sometimes this is the case.

I had a problem:

I have a somewhat older convertible laptop, an ASUS Aspire 1820PT. A nice and cheap convertible of it’s time. With touch screen support for up to two fingers and with an acceptable computational power. I have upgraded it in the meantime with an SSD and I am now running Windows 8. So far so good. The problem, however, is that the tilt sensor is no longer supported by Windows 8. :-(

So I needed a solution. Hacking drivers or even writing drivers myself is not up my alley. I am an application developer. But, if something does not work automatically (anymore), we just need to make the manual use as comfortable as possible. That’s why I wrote a tiny tool: the DisplayRotator.

The idea is simple: the tool is attached to the taskbar. As soon as it is started it shows DisplayRotatorScreena simple window with four buttons for the four possible display rotation settings. Press one of these buttons and the display settings are changed accordingly. With this, I can setup my desktop orientation of my convertible with two clicks, even two tapps with my finger, and rotate the desktop aynway I like.

DisplayRotator.zipDisplayRotator.zip Display Rotation Tool
[152 KB; MD5: 07c3efddd05a98bf4d02db595b87f2fe; More Info]

And, because I can, the zip also contains the source code of the tool. It is written in C# and naturally uses the Windows API to change the display settings. Nice and easy. With the same code basis all display settings can be changes, like screen resolution and refresh rate. Even detaching or attaching monitors to the desktop is possible. Ok, the code for these functions is not in the tool, but the API calls are the same.

Maybe the tool can be of use to someone else too.

Posted on No Comments Posted in My Tools Tagged with , ,

The Windows Powershell is quite nice. Of course, now all the Linux users start bitching around, that they always has something like this and that it is nothing special. And no one claims otherwise. But still, the PowerShell is nice and I enjoy it. :-)

Like today: I needed a simple hex dump of a file:

PS >  $str = ""; $cnt = 0; get-content -encoding byte C:\pfad\zur\Datei.txt | foreach-object { $str += (" {0:x2}" -f $_); if ($cnt++ -eq 7) { $cnt = 0; $str += "`n"; } }; write-host $str

It’s elegance is limited, that I will admit, however, I does it’s job. And, somehow, it is quite nice …

Posted on 5 Comments Posted in General, My Tools Tagged with

I believe there are many people out there, which did not think this day would come. To all of those, I like to kick you in your shins, at least virtually. If I say I am doing something, then I will do it!

BurnsTOK_3_0_49_0.zipBurnsTOK_3_0_49_0.zip Mr. Burns TOK
There is a newer Version of this File available
[129 KB; MD5: 7868fdb2a0f1c26d28cb88c618bf21e3; More Info]

Therefore, here it is: Mr. Burns TOK (Version 3.0)

Completely rewritten in C# for better maintainability and future bugfixing. Simply download and run (no Setup).
All you need is the Dotnet 2 Framework, which you most probably already have on your machine.

Posted on 4 Comments Posted in Mr. Burns TOK Tagged with