Since I have always hated the fact that I could not remove these apps from my phone I decided to root it and remove them. This is what you can do to free yourself:

1. Root your phone. It took me less than 5 minutes to root my (AT&T's Galaxy S variant) using instructions found on the internets.
2. Launch the super user application (Ninja icon)

There are two ways to continue: With the Android SDK and without.

If you have the Android SDK:

3. Connect your phone to your computer and open a shell into the phone using the adb shell command.

4. (optional) Make a backup of the files using the File Explorer feature of the Dalvik Debug Monitor (ddms:

   

5. Type su in the shell and you should see the Superuser Request box on your phone.

   

6. cd /system/app and delete the application packages you don't want, such as AT&T Maps, AT&T Navigator, YP Mobile, What, IM service, and MobiTV using the usual shell command rm.

If you don't have the SDK:

3. Get Connectbot the Android SSH client

   

4. Connect to a local root session:

   

5. Type su in the shell and you should see the Superuser Request box:

   

6. cd /system/app and delete the application packages you don't want, such as AT&T Maps, AT&T Navigator, YP Mobile, What, IM service, and MobiTV using the usual shell command rm.

   

Some crapps lead to web address but those still live in /system/app you just have to use something like AStro File Manager to figure out what is what:

On my Captivate AT&T Family Map was called androidlauncher2.1-61x612010_06_11t15_49.apk and AT&T Hotspots was called WISPr_v41.apk

Anyway eventually you end up with something like this:

Everything still worked and I could use the KDE 4.4 with compositing and everything but the whole screen was speckled. The problem only cleared up after I rebooted the machine (i.e. restarting X did nothing).

I tried Python-OpenCL but it didn't actually work and there is no documentation... even the auto-generated docs point to missing pages. PyOpenCL on the other hand seems fairly active, well documented, works, and uses Boost::Python. Anyway save yourself an hour and use PyOpenCL.

Anyway here's a screenshot of the NBody demo

NVIDA's has a bunch of other cool samples on their OpenCL portal

To be honest at some point in the last month I had working OpenCL but I have no idea if it was due to the NVIDIA binary installer or if the OpenCL shared library accidentally slipped into RPM Fusion... but then the library vanished. Hopefully it will stay around until I have time to play with it.

found bundled python: /home/stou/src/blender-svn/install/linux2/.blender/python
Fatal Python error: Py_Initialize: can't initialize sys standard streams
ImportError: No module named encodings.utf_8

The problem was the existence of the empty blender-svn/install/linux2/.blender/python directory... maybe it was causing blender to think that it should use the bundled version of python3.1 instead of the system default one. Who knows, deleting the directory (rm -rf /home/stou/src/blender-svn/install/linux2/.blender/python) fixed the problem:

Oh and the relevant lines of my user-config.py file are:

BF_PYTHON="/usr/lib64/python3.1"
BF_PYTHON_LIBPATH = '${BF_PYTHON}/lib-dynload'
BF_PYTHON_VERSION = '3.1'
BF_PYTHON_INC = '/usr/include/python${BF_PYTHON_VERSION}'
BF_PYTHON_BINARY = '/usr/bin/python${BF_PYTHON_VERSION}'

By the way if you run blender but none of the tools show up:

you are missing the .blender directory

Anyway today I figured out that the whole time I simply had to hold down the Fn key and the machine would come out of stand by like magic.

While Eclipse automagically compiles all of my Java code it doesn't support PBs "out of the box" (or in any way actually) so every time I modify the PB definition file I must compile it by hand. After the fourth instance of changing the .proto file "for the last time" it become obvious that a better solution was needed. Using a shell alias, make file, or an ant build script all seemed like poor solutions. Then it hit me, Eclipse must have support for external tooling.

Sure enough one could use an external program as a project Builder like this:

In the project properties dialog under Builders select New

then Program

which will open a dialog where you can enter information about the executable (eg. protoc) and the necessary arguments to run it.

In the Build Options tab make sure to select During auto builds (After clean is also a good idea I believe) and to also specify the resource to monitor, that is your .proto file by...

...clicking Specify Resource and finding your .proto file.

After 25 hair-pulling-minutes of trying to figure out WHY?! protoc doesn't like your arguments you will notice that it requires both the full path to the .proto file and the same path passed to the -I parameter.

That is all. Please enjoy Protocol Buffers and the Eclipse external builders responsibly.

I explained that they are better off reading books the old fashioned way and then donating these books to the library or the local thrift store.

But I started thinking: "Hmm these things would be decent for reading papers. Like if I could browse Google Scholar and/or read the arXiv, maybe even subscribe to RSS feeds... then I'd buy one". It seems though that I already poses such a device: my computer(s).

Actually if I could get licenses to read all of my existing texts...

%install
#%makeinstall
make install DESTDIR=$RPM_BUILD_ROOT

try it:

CMake Error at cmake_install.cmake:41 (FILE):
  file INSTALL cannot copy file
  "/home/stou/rpmbuild/BUILD/generatorrunner-0.3.3/build/libgenrunner.so.0.3.3"
  to "/usr/lib64/libgenrunner.so.0.3.3".

How do you like that? Did you just waste 2 hours of your life? Well maybe you shouldn't expect things to work as documented. Best of all... someone knew about this but failed to mention it (but I am not bitter).

Today however was the first colloquium that had anything to do with the Classics. The project involved bombarding the parchment from an old prayer book (made of a recycled Archmedien text) with X-Ray's from a synchrotron at SLAC in order to trigger X-Ray flourescence in the ink and allow the researchers to read the over-written text and gain a better understanding of Archimede's theories. While I am not much into The Classics this project is very very cool and the talk was excellent.

X Error: BadWindow (invalid Window parameter) 3
  Major opcode: 3 (X_GetWindowAttributes)
  Resource id:  0x380000e
X Error: GLXBadDrawable 146
  Extension:    135 (Uknown extension)
  Minor opcode: 5 (Unknown request)
  Resource id:  0x380000e
X Error: GLXBadDrawable 146
  Extension:    135 (Uknown extension)
  Minor opcode: 5 (Unknown request)
  Resource id:  0x380000e

After examining the code for the QVTKRenderWindowInteractor.py widget I decided to try subclassing it from the Qt OpenGL widget (the way the wxPython equivalent does it) instead of the plain vanilla QWidget... but it still didn't work... so I went back to default implementation and kept trying to find the problem. I fixed a silly bug in my code and things started to crash in a different way (progress!). Another couple of interweb searches uncovered a QVTKRenderWindowInteractor.py version that, like my version, used QGLWidget as its base class, so I switched back to my version and everything started working.

The result is that the interface was faster than the wxPython version (maybe because I am running KDE), and fit all my requirements. But to my horror I discovered that PyQt is GPL (Qt is LGPL which led to the confusion) and my code is [New] BSD... I really really dislike the GPL (why?) and spent a while searching the internet to see if using GPL python libraries is ok with BSD code. I even asked in #python and received a very out of character for #python but typically unhelpful IRC reply of "Ask your lawyer". Anyway as it turns out the Trolltech GPL exception allowed me to dodge the GPL bullet.

This has led me to waste several hours on annoying things like sizers not growing when they should and random crashes because I have composting on (wtf right?)... which has made me loose trust in wxPython as a toolkit and I really want... no I need this program to be rock solid. Also reading the saya blog made me realize I am not the only one having problems with wxAUI.

I don't want to imply that wxPython is garbage or anything... it's nice for creating quick and simple GUIs but the severe lack of actual documentation (especially at the fringes) has forced me to evaluate Qt as a possible replacement.

In the principle of measure twice, cut once before jumping into porting code I need to evaluate:

1. Event Model
2. Common dialogs (e.g. Color Selection, File Open/Save)
3. Existence of advanced 3rd party widgets (e.g. Scintilla)
4. Ease of writing custom widgets (like: wxPython Transfer Function Widget)
5. Existence of Qt ports of example code the app uses (like Python console)
6. Ease of integration with 3rd party toolkits (e.g. VTK)
7. Documentation

I should also start porting from the bigger pieces (VTK integration) to see if Qt is just as slow as wxAUI when it comes to VTK. Hmm maybe I'll write an article about it... and finally get a Siafoo ranking higher than David.

One could actually use the wxWidgets documentations with wxPython but when it comes to wxAUI there is basically no docs... at all. Yes I could actually post on mailing lists and support forums but that implies waiting for hours or even days for a response. Anyway I still like and will probably use wxWidgets (and wxPython) in the future... just not for this project.

Anyway, every time I upgrade the OS I loose between 3 hours and 3 months of productivity. When F9 came out it took months for the proprietary nvidia drivers to start working with the X.org 1.5 server... so I stopped upgrading instantly. F10 posed no problems for me so I planned to do a clean install (and get rid of all of the crap left over from years of upgrading through yum... ) of F11 soon after it came out (even jigdoed the DVD and played with the Preview version on VirtualBox) but clean installs suck down even more productivity, so I procrastinated on it for a while...

Last night the update-status icon in the system tray (no clue what program creates that) popped up and asked me if I wanted to update my distribution... so I clicked Yes. It downloaded all the required packages and after a reboot it started the installation procedure... it worked flawlessly. Except I lost 2+ hours because my beta version of KDE didn't work with F11... but that's my fault. I guess I won't be doing a clean install this version =/

Then I lost another hour (or two) because I couldn't find the window decorator theme I like (I had forgotten what it's called)... It has been years since I cared enough to customize the appearance of my computer (beyond a wallpaper) but I really hate the little lines in the titlebar of the default KDE 4 decorator and also how bubbly and 3Dish of the default plasma theme is:

Normally one can use KDE's Get Hot New Stuff to download plasma widgets, desktop wallpapers, and other random stuff through the interface of the control panel itself... but window decorators are actual binaries so they must be installed from source (or RPMs). After about an hour I found the theme on the OpenSUSE site... it's really nice of OpenSUSE to build RPMs for other distros. Anyway the window decorator theme is apparently called Domino and along with the Glassfied plasma theme my environment looks something like this:

Note how much cleaner everything looks.... it's even better with compositing enabled... (these are obviously VirtualBox screenshots and I don't care enough to get compositing working under them)

Translation was easy but the rotation naturally requires the use of the rotation matrix... ok that's not really that complicated but doing it right, and thus allowing for rotations around an arbitrary axis, requires that all three rotation matrices (i.e. along X, Y, Z) are added... again that's not that difficult but since there are a lot of terms things can get out of control quickly:

1m_Bounds[0][i] = x*(uX*uX*(1 - c) + c)    + y*(uX*uY*(1 - c) - uZ*s)  + z*(uX*uZ*(1 - c) + uY*s);
2m_Bounds[1][i] = x*(uX*uY*(1 - c) + uZ*s) + y*(uY*uY*(1 - c) + c)     + z*(uY*uZ*(1 - c) - uX*s);
3m_Bounds[2][i] = x*(uX*uZ*(1 - c) - uY*s) + y*(uY*uZ*(1 - c) + uX*s)  + z*(uZ*uZ*(1 - c) + c);

Anyway so I implemented it and it worked on the first try, using a single branch rotated 90 degrees. But when I tested it with a branch at 45 degrees instead of seeing a 45 degree rotated box inscribing the branch-tube I had a huge flat pizza box:

I checked the matrix and found a small bug in one of the terms but fixing it had no effect... arghh wtf?!?! So I checked the maths three more times using independent sources (MathWorld, Wikipedia, and another website) even looked at my linear algebra and physics textbooks... it was correct. Finall after I tried several different angles it dawned on me it's a bounding box which by definition is composed of the min/max coordinates along each axis so its sides always line up with the world axis... and as such the thing is supposed to look like a pizza box... what a waste of 15 minutes.

Morals (choose one):

1. Know what the correct output looks like because it may look wrong... but be right.
2. If you expect your code to produce incorrect results you'll believe it has... even when it's right.
3. When you think the output is wrong make sure it actually is before looking for problems.