Because I needed to port the clisp package onto the armv7hl build of openSUSE I had to work on the package configuration itself and at some point I decided to actually have a look into clisp itself.
What I’ve learned for instance so far, is that mathematical operations (and any other function) can easily be expressed with lists in Polish notation:

[1]> ( + 1 1 )
2

Also the packages of mine can be checked out here, and as soon as it builds cleanly at least for all the platforms and architectures the original one did, I’ll submit it again. For now you can get clisp for openSUSE-12.3 and later armv7hl here: https://build.opensuse.org/project/show?project=home%3Aleviathanch%3Abranches%3Adevel%3Alanguages%3Amisc

Also for relaxation, have a look at the why does the chicken cross the road answers. I especially like Anderson Consulting 😉
http://www.madore.org/~david/misc/chicken.html

EDIT: The problem doesn’t occur anymore under openSUSE 12.3 and newer as it appears.

leviathan@shagira:~/rpmbuild/BUILD/clisp-2.49/build> LANG=C ./lisp.run
STACK size: 98222 [0x401bff00 0x40160048]
C_CODE_ALIGNMENT is wrong. &EVAL-WHEN = 0x5f2d1.
Add -falign-functions=4 to CFLAGS in the Makefile.

Especially when you take into consideration, that I just did this:

gcc -falign-functions=4 -g -march=armv7-a -mfloat-abi=hard -mthumb -mabi=aapcs-linux \
-g -DSAFETY=3 -DNO_GENERATIONAL_GC -DNO_MULTIMAP_FILE -DNO_SINGLEMAP -Wa,--noexecstack \
-W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations \
-Wno-sign-compare -Wno-format-nonliteral -falign-functions=4 -g -O0 -DDEBUG_OS_ERROR \
-DDEBUG_SPVW -DDEBUG_BYTECODE -DSAFETY=3 -DENABLE_UNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES \
-I. -Wl,-z,noexecstack  -Wl,--export-dynamic spvw.o spvwtabf.o spvwtabs.o spvwtabo.o \
eval.o control.o encoding.o pathname.o stream.o socket.o io.o funarg.o array.o hashtabl.o \
list.o package.o record.o weak.o sequence.o charstrg.o debug.o error.o misc.o time.o predtype.o \
symbol.o lisparit.o i18n.o foreign.o unixaux.o built.o ariarm.o modules.o /usr/lib/libreadline.so \
-lncurses -ldl /usr/lib/libavcall.a /usr/lib/libcallback.a  -L/usr/lib -lsigsegv libgnu_cl.a -o lisp.run

As I see it, the compiler produces a “broken” aka wrongly optimized executable…

leviathan@shagira:~/rpmbuild/BUILD/clisp-2.49/build> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/armv7hl-suse-linux-gnueabi/4.7/lto-wrapper
Target: armv7hl-suse-linux-gnueabi
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man 
--libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,fortran,obj-c++,java --enable-checking=release 
--with-gxx-include-dir=/usr/include/c++/4.7 --enable-ssp --disable-libssp --disable-libitm --disable-plugin 
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap 
--with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch 
--enable-version-specific-runtime-libs --enable-linker-build-id --program-suffix=-4.7 --enable-linux-futex 
--without-system-libunwind --with-arch=armv7-a --with-tune=cortex-a9 --with-float=hard --with-abi=aapcs-linux
--with-fpu=vfpv3-d16 --disable-sjlj-exceptions --build=armv7hl-suse-linux-gnueabi
Thread model: posix
gcc version 4.7.1 20120723 [gcc-4_7-branch revision 189773] (SUSE Linux)

Hi Folks
Today I’ll tell you how you can implement crypto root with keyfile on your openSUSE
First you will need the following patch (tinkered together for my own setup):
http://ftp.o2s.ch/pub/patches/mkinitrd/crypto_root_luks_mkinitrd.patch

Then you’ll have to apply it and update your initrd:

sudo su
cd
wget http://ftp.o2s.ch/pub/patches/mkinitrd/crypto_root_luks_mkinitrd.patch
cd /
patch -p0 < /root/crypto_root_luks_mkinitrd.patch
mkinitrd -d /dev/mapper/root -f "udev dm storage luks lvm2" -m usb_storage

Next you add the new default boot parameters for grub in /etc/default/grub
In order to do so open the file and look for GRUB_CMDLINE_LINUX_DEFAULT
add the following variables in order to unlock your root partition at bootup
luks_root_keydev=UUID=?? luks_root_keyfile=?? luks_root=UUID=?? luks=root
(replace the ?? by values which fit your setup)

Howdy how:
Just now I got okular to recognize pinch zoom gesture (two finger zooming) after I packaged Christian Spielberger’s Qt4.8 branch with Xinput2.2 support and patches okular a little bit.
Under Tegra it’s still a bit laggy, but I guess that’s some rendering issue.
Have a look at:
https://build.opensuse.org/project/show?project=home%3Aleviathanch%3AMultitouch
Of course you may feel free to convert my packages into Debian/ArchLinux/what ever. ones in order to spread this functionality onto other distros.
RootFS-images will follow

1. You can burn your fingers on stepper motors.
2. My extruder has a problem.

Explanation:
The extruder from Wolfgang is translating many steps into a few powerful ones by using gears.
The problem is that the small gear on the motor’s shaft is only fixed by a small  headless screw
which becomes loose after a while.
This just happened during a very complicated print, which of course went wrong because of it.
Also because I’m not possessing my own set of compatible screw drivers for this kind of screw
I’ll have to wait until my colleague who has this kind of equipment has finished his last exam tomorrow.
Just when it started to be fun printing things… I really have to work on my Karma as it seems.

Now my RepRap really qualifies itself as “self replicating” from which the Rep in RepRap comes from. (Self replicating rapid prototyper)
It just printed spare parts for itself.
Yepee 😀

Today I tried to print thing 27405 from thingiverse (http://www.thingiverse.com/thing:27405) on the PrusaMendel in the CCCZH lab.
The result is shown in the provided image.
After some tweaking of temperatures and speed I finally managed to make it print perfectly!
While bigger objects still are producing some strings when it’s going to the end, smaller objects are printing fine now.
Turning the temperature to 190°C for the first layer and 185°C for all the other layers, and also reducing the extruder multiplier down to 1.0 made all problems go away. Finally!
Now I just have to figure out how to make Slic3r in ReplicatorG do support material.

I actually wasn’t sure if the RepRap wasn’t gonna burn like hell while being left alone printing in the hackerspace but it made it’s job well and printed the whole Hilbert-Knot without any incident.
During my trip to the hackerspace I already had nightmare imaginations of what might have happened to the machine.
I was quite delighted to find out that none of them had happened.
On the contrary: I now even have figured out the optimum feedrates needed to print overhanging objects which are enough dense.
I think I’ll try to print a rainbow dash soon.