News

Last week I’ve had to port some software I wrote to an ARM9 development board (I’ve been working on a part of digitalSTROM for the last year). I figured that this would be a mostly painless task and learned that it is — if you know which files to adjust. Thats why I’m documenting it for you all here.

The libraries I had to compile were:

• Boost
• LibXML
• LibICAL
• gsoap++
• libjs (yeah JS on a small ARM9 board, ain’t that cool?)

Boost

Well boost was a bitch to compile. Until I found a post in a mailinglist from someone who did something similar. I might have been easier with 1.37 but I’m stuck at 1.35 for now.

export PATH=/opt/emlix/picocom1/bin:$PATH
echo "using gcc : arm : arm-linux-gnueabi-g++ ;" > user-config.jam
BOOST_BUILD_PATH=. tools/jam/src/bin.linuxx86/bjam -d2 
--toolset=gcc-arm '-sBUILD=release static multi/single' link=static 
--prefix=../sysroot/ --layout=system --with-filesystem 
--debug-configuration install

The --debug-configuration command line switch was a life-safer. I discovered it a little late though.

LibXML2

LibXML2 was straight forward:

export PATH=/opt/emlix/picocom1/bin:$PATH
export CC=arm-linux-gnueabi-gcc
./configure --target=arm-linux-gnueabi --host=arm-linux-gnueabi \
--build=i586-linux --prefix=/home/patrick/test/sysroot/ \
--with-minimum --with-writer --with-sax1
make
make install

The only hassle was to find out that i had to include sax1 and writer for my program.

LibICAL

Straight forward as well:

export PATH=/opt/emlix/picocom1/bin:$PATH
export CC=arm-linux-gnueabi-gcc
./configure --target=arm-linux-gnueabi --host=arm-linux-gnueabi \
--build=i586-linux --prefix=/home/patrick/test/sysroot/ \
--without-bdb4
make
make install

gsoap

The problem with gsoap is that it needs to generate files to compile, but
it’s basically following the pattern:

export PATH=/opt/emlix/picocom1/bin:$PATH
export CC=arm-linux-gnueabi-gcc
export CXX=arm-linux-gnueabi-g++
./configure --target=arm-linux-gnueabi --host=arm-linux-gnueabi \
--build=i586-linux --prefix=/home/patrick/test/sysroot/
make

Then you’re greeted by this error message:

../../gsoap/src/soapcpp2: ../../gsoap/src/soapcpp2: cannot execute binary file

Which is obvious considering we’re compiling for ARM9. No you can either copy the files over to your board and execute them there or just call your native soapcpp2

cd wsdl
../soapcpp2 -SC -pwsdl -I../import ./wsdl.h

After that you’re compile-run should run smooth through until the end:

make
make install

SpiderMonkey (libjs)

Since SpiderMonkey is usually embedded in the Mozilla build-process it just has a simple Makefile. Either that or they’re just lazy at Mozilla. Here are the steps to compile that beast:

mkdir mozilla
cd mozilla
wget http://ftp.mozilla.org/pub/mozilla.org/js/js-1.7.0.tar.gz
tar xzf js-1.7.0.tar.gz
cd js
make -f Makefile.ref CC=arm-linux-gnueabi-gcc LD=arm-linux-gnueabi-ld

The build comes to a grinding halt since we’re having the “running ARM9 binaries on a x86 platform”-issue again. This time it might be a good advice to run these binaries your target-processor since it’s checking the size of various types. Copy over jscpucfg and run it like that:

./jscpucfg > jsautocfg.h

Continue the build:

make -f Makefile.ref CC=arm-linux-gnueabi-gcc LD=arm-linux-gnueabi-ld

Next stop: [...]jskwgen: cannot execute binary file. Again copy over jskwgen and run it on your target (it might work with your native copy if you’ve got one lying around, as far as I can tell it just generates parts of the parser):

./jskwgen > jsautokw.h

And continue the build:

make -f Makefile.ref CC=arm-linux-gnueabi-gcc LD=arm-linux-gnueabi-ld

Your binaries should be located in the Linux_All_DBG.OBJ sub-directory.

“Any man who hates dogs and babies can’t be all bad.”
– Leo Rosten, on W. C. Fields

Yesterday I’ve released version 0.02 of HTML::WikiConverter::XWiki to CPAN.

Changes:

- Fixed tests to reflect the improved block handling in HTML::WikiConverter
- Render <p> elements as blocks

Thanks to Stefan for reporting the block issue. There is still something wrong with wikifetch.pl but as it’s only a minor issue and not contained in the CPAN distribution it will have to reside in its current state for now.

While searching for an update for the “Leopard challenged” OpenVPN gui Tunnelblick, I’ve stumbled over a blog post from Justin over at Mozilla. He rebuilt Tunnelblick and included an update tun/tap module.

The link to the .dmg is located at the end of his post.

The field tm.tm_mon is zero based.

When I arrived yesterday’s evening at my flat I was greeted by two firetrucks and a police car. The first thing that came to my mind was: “my workbench is on fire” (I was experimenting with RGB-LEDs over the weekend).

Fortunately it turned out that the elevator’s motor was overheating and produced smoke. I hope it’s not due to the weather as it turns out to be a very nice week:

“By all means marry: If you get a good wife, you’ll become happy; if you get a bad one, you’ll become a philosopher.”

– Socrates

Well after a down-time (known as PHP4 vs. PHP5, the return of the clone()) I’m back up again.

Maybe it wasn’t the best idea to go to get a quick beer at the Break Even pub in Winterthur. We ended up visiting the afterwork party at the Carlton in Zurich with a charming exchange student.

Getting up today was a bitch though…

“Optimists don’t live long enough to see the danger coming”

– Myself

I’ve just upgraded this page to use the latest pre-release of Earthli Webcore. In the process I’ve broken the album section but hopfully I can sort that out with Marco.
New features include ligatures™ like ‘…’, ½ and footnotes[1].

Also various improvements to the back end, fancy new buttons and menus.

Update: Well it was just the base-path that was wrong, the albums-section as well as the “show_source”-feature are working again.

As mentioned earlier, my VHDL design didn’t fit the CPLD I’ve chosen to be used (namely the one I’ve got for free). This CPLD has 160 logic-cells while my design used 234 with not even all features implemented.
Reducing the RAM dataline-count from 24 to 16, using only two SRAMs instead of three, reduced the usage to 185 which, apparently, is still too much.

Using the chip usage analyzer I’ve seen that my communication logic used up 112 logic-cells.
I need to communicate to the PIC (micro-controller) to configure the trigger, arm the device, read back values, etc.
Since I’ve got eight lines to do so my initial idea was to send a command byte first, then multiple data bytes (clocked). This has inferred a gigantic state machine with only one transition from one to the other state.
Rewriting this piece of code to expect a command byte and a command word in the next clock-phase reduced the usage of logic-cells to a third.

Yeeehaw!

I’ve been studying for nearly three years now and have come to the conclusion that there is not one “typical” but several groups.

Lets define some attributes:

Dumb

They’ve more or less successfully completed an apprenticeship or some sort of higher school, but never really understood the matter that they were confronted with

Intelligent

Basic understanding and the ability to connect and understand things quickly

Lazy

A student with this attribute skips early lessons, does not bring the required books and rarely prepares him-/herself properly for his exams

Ambitious

These students will prepare for hours and weeks in advance of an exam do their homework and come prepared to their lessons

And recombine these attributes into a group:

The dumb-lazy ones

Their the minority on the campus. Not that they won’t try but you can just apply twice for a course. Normally you’re getting rid of them after the first year (assessment).
They won’t prepare for their exams even if they’re in great need of being properly prepared. Members of this group are often told to be victimized by World of Warcraft or IRC.

The dumb-ambitious ones

Those students are great dictionaries. Staying up late before their exams, learning every detail by heart, being prepared for those “but I’ve written int in my script” type of questions. Never getting too good marks they will turn to the teachers if their marks will approach the “fail”-level and cry their hearts out.
They won’t understand anything outside their view of field (or course material) but boast about their “in depth” knowledge (hacker tools anyone?).
Where they really bad at are the lessons in the laboratory where the metal hits the meat. Failing to connect the little parts they seldom finish any given task.

The intelligent-ambitious ones

Here are the “A-graders”. Studying well before the exam (well, before nightfall anyway) they will be prepared pretty good for any exam and got the brains to back up anything that they haven’t read.

The intelligent-lazy ones

Those are the practitioners. Using their knowledge to connect the whole picture they do fairly good but never exemplary regardless of their brains to back it up. They’re just not ambitious enough to do exemplary.
Digging deep into the matter, even if it’s not required to do so their interest lie in the practical application of the subjects.

Me?

Where do I fit in you’d ask? I’d put myself into intelligent-lazy corner, because I seldom prepare myself for my exams proper enough to do really well, but its the lab where I can spend hours debugging hard- and software problems.

Oh and one more thing, most students I came across really do love beer. Cheers!

Maybe you shouldn’t code with a hangover, but I think its not just me who’s stumped while looking at the following linker message:

linking xyz (g++)
myfile.o: In function `MyFile':
/home/patrick/projects/xyz/trunk/src/myfile.cpp:608: undefined reference to `vtable for xyz::MyFile'

This happens if you declare an overriden (virtual) function but haven’t implemented it. Thank you ld for your clarity…

Speaking of a beautiful woman “Such things makes you question the nonexistence of god”

– Myself