zaterdag, december 18, 2004
So, the create a DVD-Video the output of ffmpeg can be fed directly to dvdauthor, no de-re-multiplexing of MPEG streams is necessary. And what's even better, on my Athlon XP 2000+ system, its encoding is faster then real-time; encoding to DVD-Video compliant MPEG-2 only took 75% of the running time of the video.
dinsdag, september 21, 2004
vrijdag, juli 30, 2004
dinsdag, juni 22, 2004
some more pictures of Poekie
We had saved him twice before, but aparantly I couldn't save him this time :-(
We found him as a kitten and fed him and gave him a home. For years, everything went fine, until last summer when he got bitten by a rat. He almost died from the infection... We didn't notice that he had a wound, because his fur is so thick and he didn't complain much about it. Just the lack of appetite disturbed me.
Now, apparantly last night he crossed the street and got hit by a car.
maandag, juni 21, 2004
donderdag, juni 17, 2004
When you're working on a project which involves modifying Linux kernel code, you'll have to be able to debug the Linux kernel. This is harder then debugging normal userspace applications. But luckily, the Linux community has provided some decent tools such as the various kernel debuggers and f.e. DProbes.
When you're programming RTAI, and you're bitten by an RTAI kernel bug, you're in big trouble. The Linux kernel debugging tools in general don't just work together with RTAI's ADEOS patch. So, there's no real tool to aid you. The best thing that might happen if something goes wrong is a kernel Oops, which you can try to trace and fix (See this Oops tracing howto).
Unfortunately, some bugs are really mean. They might cause a crash without an Oops or they might for example give you no backtrace at all.
One possibility for debugging such ugly beasts is a PC emulator such as Bochs. The Bochs PC-emulator has an integrated debugger. Unfortunately, Bochs is really slow. Some say, the emulation system runs about two hundred times slower then your real system.
Nevertheless, I tried to use it to debug RTAI/LXRT applications, but unfortunately, RTAI/LXRT applications don't run stable yet using Bochs.
too much had changed (9 versions) and apparantly I made a mistake somewhere...
The next try took a lot more work, because I ported to every successive version from 1.3-OCI to 1.4.1-DOC. So, from OCI's 1.3 release to the DOC group at Washinton University 1.3, to 1.3.1 DOC, and with every version in between to the final 1.3.x release of the DOC group 1.3.6-DOC. Then the porting continued to the major new DOC group release 1.4.0 and finally to 1.4.1-DOC.
Now, to be able to merge, I'll have to port it to the 1.4.2 CVSUP tree version. And ofcourse, test it extensively.
woensdag, mei 05, 2004
Now, I have been playing around with about a dozen Blender objects moving around and rotating according to the coordinates specified by a CORBA server feeding events. So, it seems to work now. There still are some issues though.
I rendered this silly Blender-CORBA animation to a video.
dinsdag, mei 04, 2004
If I make the code just a little bit more general, it should be possible to animate any Blender scene just by writing a CORBA Event Service supplier supplying various attributes for Blender objects.
Last Sunday I experimented with using CORBA from within Blender's Python scripting environment. Yesterday, I extended these simple scripts to use the EventService to receive its updated data.
Unfortunately, there appear to be some problems with Blenders Python scripts. For example, even though a particular script ran successfully several times, then suddenly, Blender complained about syntax errors. There were no modifications between the runs and there was no syntax error :-(
donderdag, april 29, 2004
I'm being flooded with futex(0xbffff510, FUTEX_WAIT, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) messages from strace.
The problem seems to be resolved in TAO 1.4 but using 1.3 is easier since that's the version I'm also using on RTAI. To be able to run a CORBA application, I now have to keep compiling the IDL files with different versions of TAO, which is pretty annoying. So either I start testing the TAO 1.4 port I've been working on monday or I'll have to figure out what is causing the problems with Linux 2.6 and TAO 1.3. Using the old threading library doesn't seem to help. I should reboot using a 2.4 kernel to make sure I'm not hallucinating.
vrijdag, maart 05, 2004
failing. I assumed the mistake was ACE's, and debugged it for hours.
Unfortunately, the bug wasn't in ACE, but in the new POSIX threading library for
GNU/Linux (NPTL). This was rather disappointing to me, since I had read nothing
but good about the new threading implementation. The problem occurred because on
thread creation, NPTL just ignores the thread attributes. So, selecting a
scheduler or priority on thread creation doesn't work at all.
Furthermore, I noticed, that the new threading library only allowed me to create
255 threads, while LinuxThreads allowed me to create 1532 concurrent threads.
This is even stranger, as I have read reports on using 100k concurrent threads
with this new threading implementation. Apparantly, somethings wrong here, but I
can't figure out what could be causing this.
And, when I was trying to report these issues to the NPTL developers, I couldn't
find their mailinglist. I could find people referring to it, but I couldn't find
the address :-) Now, for some reason it's called the phil-list... not quiet easy
to associate this with a new threading lib.
maandag, januari 12, 2004
I just ported the gettimeofday_rt I wrote for the previous release of RTAI to the newest RTAI 3.0. It works just fine for the ACE test! :-) Now, there are just some minor issues related to the prefered style of linking... Next up, is the porting of ACE's debug framework.
zondag, januari 11, 2004
One thing that's still missing from the RTAI Kilauea tree, is a decent gettimeofday function. I've added an implementation to the stable RTAI tree (Stromboli) earlier, so I'll just have to port that one to Kilauea. Without that patch, some ACE/TAO tests will definitely fail.
Other than that, the ACE debugging code has to be ported as soon as possible. Don't know if it's best to shove the data through a real-time FIFO or to just implement is using rt_printk.
A few weeks ago, our TAO/ACE RTAI (Stromboli) port was starting to show some results. The CORBA benchmarking application I wrote about a year ago, worked on RTAI, both in soft and in hard realtime.
Last week, I started porting our TAO/ACE code to the new RTAI tree, called Kilauea. And about three hours ago, I ran all my (collocated) benchmarking code without any crashes! :-)
Furthermore, the official Collocation test included in TAO also works on RTAI 3.0 in hard realtime without any problems! Yay! :-)
I'm using the benchmarking results to create some charts which I'll post later on, to illustrate the achievable performance with TAO/RTAI.