For those, who never heard about it: Braid (http://braid-game.com, http://www.lgdb.org/game/braid) is an exciting puzzle game, and – for me – one of the best in these days. I garantee, you won’t regret a try!

The game  (I’m afraid, it’s not open source yet) is available in a bundle at http://www.humblebundle.com/. The price is left to the buyer’s decision.

Ebuilds for Gentoo are in progress:

• https://bugs.gentoo.org/show_bug.cgi?id=349136
• http://gpo.zugaina.org/games-arcade/braid

Take a look!

This post focus on people, who have got random freezes and match following requirements:

• > linux 2.6.32
• rv350 gpu
• kms enabled
• use of open source radeon-driver

Note: There are a lot of “random freezes” issues out there. So it’s very likely, that your random freeze is not *this* random freeze. Be sure, you have read through the bugtracker (as referred below), before beginning hacking the kernel. If you are a victim of this bug, then please help by posting your system setup on the bugtracker and testing patches!

The whole matter is documented on freedesktop (bug #28402).

We’ve located the exact kernel-commit, which leads to this regression. It has been discovered, that there is something wrong with the GTT-mapping.

The GTT (or Graphics Translation Table) is the set of page table entries for the GPU IOMMU (GTT is often used to refer to both the page tables and the IOMMU). In order for the GPU to perform an operation on memory (e.g. use it as a scanout buffer, render to it) the memory must be pointed to by GTT entries. That means it must be pinned into physical memory (i.e. not swappable to disk) and GTT pointers must be updated to point at it.

[copied from https://wiki.ubuntu.com/X/Glossary]

Also a patch has been provided, which is more a workaround than a fix (!). For this reason, there is no hope for a quick fix in upstream. You can get rid of the issue by patching your kernel. Further instructions, how to do that, can be found in the web.

I run a 2.6.35 zen kernel with this patch and my machine has survived without a crash for two weeks.

Let’s hope, a real fix will be provided soon.

//Update//

The final fix was found and is included in kernel 2.6.37.

smf

The first one is a very old one. It stands for “set mouse frame”.
A more detailed introduction is provided at its page: http://vootey.wordpress.com/project-smf/

dzen-environment

The second one is about creating a new desktop-info-environment for my (and possibly other’s) desktop.
A more detailed introduction is provided at its page: http://vootey.wordpress.com/project-dzen-environment/

Yet I managed to implement following stuff:

• Objects (circles, balls) can be added, which own attributes:
  • Mass
  • Radius of the ball/circle
  • A force, that acts on the object
  • Initial position
  • Initial velocity
• Elastic collision
  • just the implementation of the centric elastic collision (a little minimalist, I know ; it’ll be changed soon)

This all should work within 3 dimensions (actually more). However, the display is 2-dimensional. So you’ll only see 2D.

Source: physics_05042010.tar.gz (published under GPL)

Requirements:

• >= Ruby 1.8.7
• >= Qt 4.6 (not sure about the exact version, may function with lower versions too)
• version matching Ruby bindings for Qt.

The code is uncommented yet, but I think not unreadable. Nomenclature should do it for now.

What bothers me is the collision detection. Now it’s a simple cross-check (checks the distance two objects) on all existing objects, which is done every move. I can imagine, that this is not the cheapest way, if it’s about computationally intensity. Additionally I cannot avoid a “leapover” of two objects (at small volumes and/or high velocities).

How “leapover” effects on bouncing balls: video (look at the smallest ball)

I also considered a more mathematical approach: If you imagine two objects as two curves through time (R -> R³), you will be able to determine the crossing points in a more analytical (in my oppionion better) way. But this case is only applicable for objects without volume. So what about the extension of such a body? The curve would now look like a tube through time. This looks again like a lot needed computing time. And the “leapover”-problem is again unsolved, isn’t it?

However, after all I discovered a quite nice editor-independend tool-collection, called rcodetools. Information is available at RubyForge and here.

rcodetools is a collection of Ruby code manipulation tools for automagic Test::Unit(RSpec) assertion generation, code annotation, 100% accurate code completion, code and documentation browsing, precise method information (rcodetools is meta-programming aware)…

rcodetools 0.7.0 introduces “test-driven completion” (TDC) which allows 100%-accurate completion while alternating between implementation and tests. Several new mechanisms allow faster development in large projects, and xmpfilter supports RSpec’s latest syntax.

rcodetools can be used with any editor, but it ships with emacs and vim support.

Since I’m a Vim-user, it’s perfect to me … and the deployment is rather easy, if you know what to do.

Assuming Ruby and RubyGems are installed and working, you can simply install it via RubyGems:

gem install rcodetools
gem install fastri

The last one you’ll just need, if you want documentation browsing support. Though I thought, RubyGems does it automatically,  I additionally had to execute the particular setup.rb (e.g. /usr/lib/ruby/gems/1.8/gems/rcodetools-0.8.5.0/setup.rb [path may vary]) as root to set it up properly.

As next step, you have to copy the rcodetools.vim from the mentioned gem-directory into the Vim‘s plugin-directory: in my case: ~/.vim/plugin/).

If you want documentation browsing support, you’ll have to add following line to your Vim-config (~/.vimrc):

let g:rct_completion_use_fri = 1

. Again, this will only work, if you install fastri first. Every time you wanna use it, fastri-server (shipped with the gem) must run.

Now everything should be set up proberly and working. Here is a nice screen-view, how it should look like:

Vim with Ruby code-completion.

At last, one important thing is to say about it: Be aware of the side effects of such technologies! As mentioned above, Ruby is a dynamic language. This means, the plugin has to execute your ruby code to obtain the information it needs. For instance this sideeffect takes place, if your code is deleting a file or sending an email. While you are using the code-completion feature, your code is executed before you really want to. So your file is already deleted or the email is already sent, before you start your program.

Fact is, the decision had to be made, which GUI-framework I want to use in the future. Since I’m a KDE user and KDE’s used framework is Qt4 and since I nearly heard only good things of it (not to mention, it’s open source now), I choose to use it: Qt4. The next logical step was, of course, to look for bindings for Ruby and install them. Sounds easy, but it barely was.

After a unsuccessfull look into the Gentoo portage-tree, I tried my luck in the web. And here (a RubyForge project) it is. Okay, at least there exists a stable version, but building it myself is the last thing I wanna do. I gave RubyGem a try. It’s the Ruby’s package manager, which is delivered with Ruby. I found the right package in the repository, but it was only a win32-version, so it’s not of use for me. At next, Google told me about a qt4-qtruby-ebuild in the qting-edge portage-overlay. Adding the overlay and emerging the ebuild brought me following:

Scanning dependencies of target smokeqt
[ 32%] [ 34%] Building CXX object smoke/qt/CMakeFiles/smokeqt.dir/smokedata.o
[ 36%] Building CXX object smoke/qt/CMakeFiles/smokeqt.dir/x_1.o
Building CXX object smoke/qt/CMakeFiles/smokeqt.dir/x_2.o
/dev/shm/portage/dev-ruby/qt4-qtruby-2.0.3/work/qt4-qtruby-2.0.3_build/smoke/qt/smokedata.cpp:6086:
error: expected ‘}’ before ‘com’
/dev/shm/portage/dev-ruby/qt4-qtruby-2.0.3/work/qt4-qtruby-2.0.3_build/smoke/qt/smokedata.cpp:6086:
error: expected ‘}’ before ‘com’
/dev/shm/portage/dev-ruby/qt4-qtruby-2.0.3/work/qt4-qtruby-2.0.3_build/smoke/qt/smokedata.cpp:6086:
error: expected ‘,’ or ‘;’ before ‘com’
/dev/shm/portage/dev-ruby/qt4-qtruby-2.0.3/work/qt4-qtruby-2.0.3_build/smoke/qt/smokedata.cpp:6086:
error: expected declaration before ‘}’ token
make[2]: *** [smoke/qt/CMakeFiles/smokeqt.dir/smokedata.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [smoke/qt/CMakeFiles/smokeqt.dir/all] Error 2
make: *** [all] Error 2

Disappointment after disappointment …

After some time searching the web for answers, I finally found a appropriate bugreport. It told me to make use of the kdebindings-ruby-ebuild from the kde-overlay (never saw it before). I emerged it, and violá: after spending a day searching the one word kdebindings-ruby, the bindings were finally installed.

I even managed to get my first Hello World-program running:

require 'Qt'

app = Qt::Application.new ARGV

hello = Qt::PushButton.new "Hello World!"
hello.resize(100,30)
hello.show

app.exec

Hello World!

By the way this is my first blog-entry, so this program seems to be quite suitable.