Guess what this means:

A two-dimensional interval over integers

This is most easily depicted as a set of integers, bounded by a lower and an upper value - but excluding the upper value. All inbetween values are included in the set. (see also http://en.wikipedia.org/wiki/Interval_%28mathematics%29)

Hmm, two-dimensional, but bounded by a lower and an upper value? And the Wikipedia article it refers to says that

 In mathematics, a (real) interval is a set of real numbers

while the above talks about integers. But oh well.

Got it yet? There's more:

The set is half-open, i.e. the lower bound is included, the upper bound not (if you're used to the notation - we're talking about [a,b) here, compared to closed [a,b] or fully open intervals (a,b)).

This again sounds a bit one-dimensional, but let's put that down as a case of copy/paste joy, and let's assume that the reader is able to extrapolate into two dimensions.

Does it sound familiar yet? Oh well, finally it says:

Alternatively, consider this a rectangle, where the rightmost pixel column and the bottommost pixel row are excluded

Oh. Sure, the concept of "rectangle" is so unfamiliar to programmers that it isn't worth mentioning except after some impressive-sounding mathematics jargon (that perhaps is not really useful in the case of finite, integer, ranges, but I digress). And yeah, let's mention pixels, too, all of a sudden. Of course, giving what apparently tries to be a strict mathematical definition, no need to mention whether the pixels here are centered on integer coordinates, or bounded by them. But I guess it's the former, as otherwise it would make little sense, or would it?

And what is right here, and especially, what is bottom? In mathematics, the y axis usually is depicted as pointing upwards, isn't it?

To make it even more fun, the data structure that this documents contains neither "range" or "rectangle" in its name, but "box"...

Jos Poortvliet , tell us about yourself. Who are you?

Hey, I’m a Dutch Free Software enthusiast living in Berlin with my Brazilian
wife Camila. I’ve been around Free and Open Source for over 10 years, mostly
active around marketing and community related things.

Firefox detects since version 17.0 the Linux system profile, which is a great improvement for the operating system. While colour conversions on all platforms still default to on for ICC tagged content, they can be enabled for all other colours. Untagged colours will then default to sRGB instead of omitting monitor compensation for them. To do so go to the famous about:config URL and change gfx.color_management.mode from “2″ to “1″. Then use the installed CMS, e.g. on  KDE KolorManager, to set a system monitor profile, and it will be detected after restarting Firefox.

For Android there is no CMS available. That means the ICC monitor profile must be set manually or sRGB will be assumed instead. The settings name in about:config is gfx.color_management.display_profile. Enter into this string the file name with full path, if you are on Android. That procedure is somewhat inconvenient compared to desktops. However the OpenICC group has published some specifications for implementation. This might be even possible for students inside the rewarding Google Summer of Code 2013 program.

For comparison, the Chrome web browser does support colour management on some desktop versions but unfortunately not on Android.

The below false colour test image should look correctly with ICC profile enabled browsers. Look at the colour gradients and then at the colour names and compare.

Enjoy cross platform colour management.

openSUSE Team at SUSE is looking for a senior KDE developer that is willing to join the company to work on openSUSE distribution and customer products where KDE technologies are present.

As those of you who are closer to KDE and/or openSUSE know, Will Stephenson has been leading this area the last few years. He is now facing new professional challenges within SUSE so we are looking for somebody that coordinates the openSUSE Team efforts related with KDE together with the openSUSE community, upstream and other SUSE Teams.

Our default openSUSE desktop, KDE, is obviously a relevant piece of our puzzle. But beyond pure KDE work, the selected candidate will also work in other areas of the distribution and will play an important role as openSUSE/SUSE advocate in technical forums.

openSUSE currently ships other desktops too so it will be important for the selected candidate to drive high levels of cooperation with the openSUSE GNOME (and others) team and upstream in cross-distro development efforts.

As a preferred choice, we are looking for a KDE developer willing to move to our Headquarters in Nuremberg, GE or to our office in Prague, CZ.

If you are interested, please check the opening details and send your CV through the SUSE Careers website. Links to your contributions to KDE and contacts for references are welcome.

In a more personal note......

Will, thanks for standing strong and work hard for openSUSE and KDE. Good luck in your new position.

Note: like the previous post, this one is a follow-up on a series written by someone else. We're all building on top of giant's shoulders. My giant today is Sébastien Pouliot from Xamarin. Read his series Producing Better Bindings.

Second Note: if you're reading this from a news aggregator, you might miss the embedded gists. Read the original there.

I'm lately enjoying writing bindings for Xamarin.iOS and Xamarin.Mac, a lot for the fun, very little for profit. The biggest project by far was creating a managed bindings for cocos2d (v2). This library is huge (~2500 public methods), and the API is far from being fixed in stone. The library is so big that at some point I just gave up, until Miguel resumed the effort during end-of-year break.

No chocolate

One of my worst nightmare was that, at the point of completion, the API would probably outdated, and going through every .h at every release to check consistency looked very expensive from a maintenance point of view. Hopefully, Sébastien came up with automated tests, removing a lot of the burden. There was still a missing part. making sure we were not missing any (important) part of the exposed API. In Producing Better Bindings #1, he said:

There’s no easy way to test for missing constructors[...]. That would require static analysis (not introspection) in order to be useful.

 It was very much like a "you can't get chocolate"-day for me. Which means a lot for a Belgian.

Static Analysis

I wanted that feature badly. But I wasn't in the mood of writing (another) .h parser, just to extract the public API (though I could have used the same tools used for generating documentation). So I opted for analysing the generated library, but not at runtime, just after compiling.

So I added a step in my Makefile that looks like this:

#static analysis
%.selectors: %.a
 nm -P $< | grep "^[-+]\[.*\] t" > $@

which generate a file containing entries like this:

+[CCLayerColor layerWithColor:] t b84 0
+[CCLayerColor layerWithColor:width:height:] t b1b 0
-[CCLayerColor blendFunc] t 1167 0
-[CCLayerColor changeHeight:] t ecc 0
-[CCLayerColor changeWidth:] t e87 0
-[CCLayerColor changeWidth:height:] t e4b 0
-[CCLayerColor draw] t fa1 0
-[CCLayerColor initWithColor:] t d81 0
-[CCLayerColor initWithColor:width:height:] t c3f 0
-[CCLayerColor init] t bd7 0
-[CCLayerColor setBlendFunc:] t 1182 0
-[CCLayerColor setColor:] t 10b9 0
-[CCLayerColor setContentSize:] t de2 0
-[CCLayerColor setOpacity:] t 1114 0
-[CCLayerColor updateColor] t f10 0

which is all we need (and some more we don't need).

The fixture

Parsing the file

Skipping categories

What's missing ?

My new Lenovo T430 arrived last week. After delighting in that satisfying new laptop smell, I made recovery DVDs I will presumably never need, then blew away Windows 7 and installed openSUSE 12.3 (full disclosure: I work for SUSE, so my choice of distro may not be entirely unbiased).

Some niceties:

• The textured touchpad is lovely. Much better feel than a pure flat surface.
• As I’d expect, the keyboard is excellent (even if PGUP/PGDN aren’t where I’m used to).
• The openSUSE installer is quick and easy. I’m pretty sure there’s less steps than last time I did a regular openSUSE install from scratch a couple of years ago.
• No problem setting up encrypted LVM, although on my ~500GB drive it defaults to a 20GB root and 25GB /home, with a whole lotta free space left over in the encrypted partition, so that might want some tweaking.
• Entering the passphrase on boot happens on a pretty graphical screen, you don’t get thrown back to a terminal window where random junk is appearing over the passphrase entry prompt.
• Moving my mail over from my old laptop was pretty much just an rsync of the Thunderbird profile directory (and maybe a tweak to ~/.thunderbird/profiles.ini)

Some oddities:

• The Novell GroupWise 8.0.2 client had a couple of problems:
• It claims to need libXm.so.3 (listed in RPM Requires), but works fine without it. This is fortunate, because openSUSE 12.3 doesn’t ship openmotif22-libs-32bit anymore.
• Unless you’ve installed libpangox-1_0-0-32bit, the GroupWise client will segfault somewhere in libwebrenderer.so. This is less than obvious.
• The YaST disk partitioner seems slightly confused adding new LVs inside my encrypted VG later on (it either locked up or crashed). I haven’t had time to investigate this properly, so I’ve ignored it for the moment and used lvcreate and mkfs in a terminal instead.
• You do need to reboot at least once after initial install for NetworkManager to work properly (this is mentioned in the release notes).
• I’m running GNOME 3.6, and I tried using the tweak tool to have it just blank the screen – not suspend – when closing the laptop lid. Turns out systemd is being too clever for me, so I had to fiddle with that a bit (set HandleLidSwitch=ignore in /etc/systemd/logind.conf, then run sudo systemctl restart systemd-logind).

Very little else to report so far. Aside from the oddities above everything else seems to Just Work^TM. OTOH, all I’ve really done is web browsing, email and assorted fiddling around in terminals. Maybe listened to a bit of music (the inbuilt speakers are well and truly loud enough, but a bit tinnier than real speakers – can’t say I’m terribly surprised by that though).

One year ago I wrote about the Lenovo Thinkpad Tablet based on Tegra II. After 12 months + the device is now pretty doomed. Not only mechanical switches stop working, the power supply gave up around the same time. Looks like Lenovo sells cheap and crappy hardware for business prices. For a ThinkPad labeled device that is far behind any expectations. But the whole concept behind Lenovos business tablets is flawed.

The manufacturer delivered since quite some time no security updates. The device boots only OS kernels digitally signed by Lenovo. So business administrators can not fix anything on their own as is otherwise usual for Android. That lockout makes just junk in a business environment. Further the company decided to build upon a Windows only chipst for the ThinkPad 2 Tablet, without any plans for migration of investments in Android. The minimum would have been a dual boot machine for those, who prefer to continue with, what they have build already. This is a business reset decision inside Lenovo. One simple measure would be to make the kernel signature public available to allow for security and OS updates on the device on a professional base. An other important step is to open up the currently Windows only ThinkPad 2 tablet for Android.

I am happy to announce that i succeded in compiling wxRuby 2.0.1 on my Buildservice account and it is available to be installed in just one click for openSUSE 12.2 and 12.3.

wxRuby is an old but working library based on wxWidgets toolkit, till some day ago the dependency from SWIG 1.3.38 and some small errors raised during the manual compilation, made the use of this library the worst nightmare for beginners who was looking for a fast approach to GUI based programming in Ruby.

After some day spent to investigate about a possible upgrade of the SWIG dependency to the current 2.0 version, i produced some patches to fix this and the other annoying compiling errors, and finally, thanks to the Buildservice infrastructure, a wxRuby RPM compiled from sources with the relative patches are now availables for all openSUSE users!

As far i googled this should be the first distro to have a precompiled and working wxruby gem among its repositories (being compiled from sources the gem is generated for 32 and 64 bits architecture from Buildservice itself), so Rubyists take a look on software.opensuse.org, select the package coming from my home project account and enjoy!

Here's a few tips and tricks that some people might want to use to fine tune their openSUSE 12.3 machines

'Traditional' Multi-monitor behaviour for GNOME 3 workspaces

GNOME 3 has a bit of a weird way of handling multiple monitors with its multiple workspaces feature. When switching workspaces, it's only the workspace on the 'primary' monitor which changes, the applications running on the second monitor (or 3rd or 4th..) remains where they are, as if they're on the own single, static, workspace.

Some people like this behaviour - I use it so I can have one screen with key tools I need all the time (Network monitors, etc) where my other screen is the one where I'm constantly shifting and changing depending on what I'm doing

But if you'd like to change to a 'traditional' arrangement where changing workspaces changes the applications on all of your screens, all you need to do is run the following command as yourself (I'd recommend pressing ALT+F2 and just copy/pasting this in there)

gsettings set org.gnome.shell.overrides workspaces-only-on-primary false

and if you decide you want to change it back to the standard behaviour

gsettings reset org.gnome.shell.overrides workspaces-only-on-primary

Making your fonts even prettier in GNOME 3

First things first - I strongly recommend that if you have them installed, remove the Microsoft TTF fonts with the following command as root

zypper rm fetchmsttfonts

As I explain on my Google+ post, 'back in the day' Microsoft's fonts were pretty much considered the only acceptable fonts and the Free/Open alternatives installed on openSUSE by default were considered ugly.

That might have been true back then, but in this day and age the Free/Open fonts installed are much smoother and I find myself looking at the MS fonts and recoiling in horror much as I used to at Linux fonts.

To really get your fonts looking perfect, I'd recommend playing around with the 'Hinting' and 'Antialiasing' options in the Fonts section of 'gnome-tweak-tool' (launch by pressing the Winkey/Super and searching for Tweak)

I find that having 'Hinting' set to 'Slight' and 'Antialiasing' set to 'Rgba' looks best on my machines.

Installing the Groupwise Client on openSUSE 12.3

Quite a few of us openSUSE users work for companies that run Novell's Groupwise. Their Linux client hasn't seen any development in recent years, but with the absence of an open source alternative, many of us needed to find a way to get 'old faithful' working.

Thanks to Michael Brookhuis from SUSE, we have a solution. Run the following command as root to make sure you have all the necessary packages installed

zypper in openmotif-libs-32bit libstdc++33-32bit libpangox-1_0-0-32bit

And then run the following to make a symlink so Groupwise can find the openmotif libs you just installed

 ln -s /usr/lib/libXm.so.4 /usr/lib/libXm.so.3

Or you could just be like me and use the Groupwise Web Interface, which has finally grown on me :)

Hope this helps some people out there

The combination of limare and open-gpu-tools can now run Quake 3 Arena timedemo without depending on the binary driver for the shader compiler!

Connor Abbott has been being his amazing (16y old!) self again in the weeks after his talk at FOSDEM, and he pushed his compiler work in his open-gpu-tools tree to be able to handle basic vertex shaders. Remember that our vertex shader is a rather insane one, where the compiler has to work real hard on getting scheduling absolutely right. This is why an assembler for our vertex shader was not too useful and the most part of a compiler had to be written for it to generate useful results. A mammoth task, and Connor his vertex shader code is now larger than the code I have in my limare library.

So it was high time that we brought limare and OGT together to see what they were capable of with some basic shaders. Luckily, the Q3A GLES1 emulation has basic shaders, what a nice coincidence :)

So Connor turned my simple vertex shader essl into the high level language used by the OGT vertex shader compiler, and through steps described at this wiki page, turned them into MBS files (Mali Binary Shader - the file type output by the standalone compiler, and also by newer binary driver integrated compilers). Limare can then load and parse those MBS files, and run the shaders. No need to involve the ARM binary anymore when we have OGT generated MBS files :)

The result was quite impressive. We had a few issues where the limare driver (which has mostly taken its cues from the output of the binary driver) and OGT disagreed over symbol layout, but apart from that, bringing up the shaders connor produced was pretty painless. Amazingly effortless, for such a big step.

Connor then spent another day playing with the fragment shader assembler, fixed some bugs, and produced 3 fragment shaders for us. One for the clear shader used by limare directly, and 2 for Q3A. After some more symbol layout issues, these also just worked! We even seem to be error-margin faster with the MBS files (due to texture coordinate varyings being laid out differently).

So this is a really big milestone for the lima driver project. Even with our insane pre-optimized architecture, we now are able to run Quake 3 Arena without any external dependencies, and we are beating the ARM binary while doing so.

For generating your own shader MBS files, check out Connors OGT, and then you can head straight to Connors wiki page. My Q3A tree now has the MBS code included directly. And i pushed a dirty version of my FOSDEM limare code.

As for this new limare code, this fosdem_2013_pile branch will vanish soon, as i need to properly pry things apart still. This is run-for-the-price code, and often includes many unrelated fixes in the same commit. It's better to do archeology on it now, than 3y from now, so this needs to be split. But in the meantime, you all can go and give Q3A on a fully free driver stack on Mali hw a go :)

I will not post a video, as there really is nothing new to see. It is the exact same timedemo, running some promille faster. Build things, and then run it yourself on your sunxi hardware (i am still working on porting it to the new kernel of a more powerful platform). That's the best proof there is!

For building limare, check out the fosdem2013_pile branch and then just run make/make install.

For building Q3A all you need to do is run:

make ARCH=arm USE_LIMARE=1

And, when you have the full quake installed in ~ioquake3/baseq3, you can create a file called ~ioquake3/baseq3/demofour.cfg with the following content:

cg_drawfps 1
timedemo 1
set demodone  "quit"
set demoloop1 "demo four; set nextdemo vstr demodone"
vstr demoloop1

You can then run the ioquake3 binary with "+exec demofour.cfg" added to the command line, and you will have the demo running on top of fully free software!

Now we really have covered all the basics, time to find out how Mesa will play with our plans :)