stringify looks trivial, there’s no shared state nor there is any static data, so I thought that I could call stringify from several threads at the same time. I don’t think there’s any guarantee about thread safety of ostringstream’s operator<< but it looked like a safe assumption. Well, incorrect.

operator<< calls vsnprintf, which should be thread-safe by itself. However, OSX's vsnprintf ultimately calls localeconv_l, which is not thread-safe. And, you end up with something like this:

#0 0x96f734a9 in malloc_error_break ()
#1 0x96f6e497 in szone_error ()
#2 0x96e98503 in szone_free ()
#3 0x96e9836d in free ()
#4 0x96e97f24 in localeconv_l ()
#5 0x96e93335 in __vfprintf ()
#6 0x96ecb9b5 in vsnprintf ()
#7 0x0144615e in std::__convert_from_v ()
#8 0x01437d2a in std::num_put<char, std::ostreambuf_iterator<char, std::char_traits > >::_M_insert_float ()
#9 0x0143803d in std::num_put<char, std::ostreambuf_iterator<char, std::char_traits > >::do_put ()
#10 0x0144ab6a in std::ostream::_M_insert ()
#11 0x0000fb25 in std::basic_ostringstream<char, std::char_traits, std::allocator >::str () at sstream:217
...

Which means there’s no way of converting stuff to human readable in a thread-safe manner. I’m not sure whether I’m missing something or not… but this looks very fishy. I ended up adding a stupid big mutex around my stringify calls, but that looks more like a workaround that a final solution to the problem. Plus, this doesn’t protect ANY other uses of iostream’s operator<< such as loggers.

Ok… looks like that wasn’t a very accurate diagnostic. This is going to be more annoying than I thought.

— ferdy

With semi-strong current and some wind it managed to follow a very nice path across some waypoints:

The trajectory between p2 and the shore was done manually using a joystick. Interestingly enough, that path is less nice than those done by the autonomous control.

I hope to be able to post more niceties soon.

— ferdy

It is hilarious that you have to run a Windows executable to download a copy of Windows XP.

Chicken and egg?… Yeah, that’s clever.

One point for you Suckrosoft.

Since I haven’t really done anything in OpenGL beyond stupid examples and helloworld-like programs and given that I don’t have much time to devote to this task I decided to use an existing framework. Among Irrlicht, OpenSceneGraph and Ogre. I decided to give OpenSceneGraph a try, for no particular reason.

Unfortunately, it took a while to get it working under OSX… it needs something like this. I use MacPorts for this kind of stuff under OSX:

fixOpenSceneGraph()
{
	local lib_dir=/opt/local/lib
	pushd ${lib_dir} > /dev/null
	echo pushd ${lib_dir}
	for i in libosg*.dylib* libOpenThreads*.dylib* ; do
		echo install_name_tool -id ${lib_dir}/${i} ${i}
		otool -L ${i} | sed -e 1d | while read f ; do
			if [[ ${f} =~ ^libosg ]] || [[ ${f} =~ ^libOpenThreads ]] ; then
				l=${f%% *}
				echo install_name_tool -change ${l} ${lib_dir}/${l} ${i}
			fi
		done
	done
	popd > /dev/null
	echo popd
	port contents OpenSceneGraph |
		sed -n -e '/^[[:space:]]*\/opt\/local\/bin\//p' -e '/\.so/p' |
		while read f ; do
		otool -L ${f} | sed -e 1d | while read d ; do
			if [[ ${d} =~ ^libosg ]] || [[ ${d} =~ ^libOpenThreads ]] ; then
				l=${d%% *}
				echo install_name_tool -change ${l} ${lib_dir}/${l} ${f}
			fi
		done
	done
}

It wasn’t fun to figure that out (thank you CMake)…

Anyway, I think I’ll stick to OpenSceneGraph until it annoys me enough. For now, I managed to do what I wanted in less than 2 hours, which is pretty good when you have a stupidly tight schedule.

— ferdy

If there’s a case when it doesn’t, provide a sample input and explain why it happens.

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
	float f[argc - 1];
	for (int i = 1; i < argc; i++)
		f[i - 1] = atof(argv[i]);
	float r1 = 0;
	for (int i = 0; i < argc - 1; i++)
		r1 += f[i];
	float r2 = 0;
	for (int i = argc - 2; i >= 0; i--)
		r2 += f[i];
	return r1 != r2;
}

As usual, I’ll post the solution in a couple of days or when someone gets it right (which is always the case :))

— fpereda

Update: correct typo spotted by Snaury.

Some parts of the fractal are quite interesting and different from other fractals derived from the Mandelbrot set. Here are some pictures using gmandel:

— fpereda

Good luck to everybody. I hope some people understand the real needs of Gentoo and where it should go. Even if I’m not planning to come back to Gentoo (either as a user or as a developer), I certainly hope the best for it.

Cheers.

— ferdy

’nuff said!

Mood: Extremelly happy.

— ferdy

Also, Ricardo Cervera (you don’t have an url these days, you do?) sent me Introduction to Algorithms which I’ve been skimming through. Really nice book, of course. — Thanks.

As part of one of the research projects I’m involved, I just started reading/studying Aircraft control and simulation. Fortunately, it is not hurting as much as I expected. Though it is not for the faint of heart.

— ferdy

Tomorrow morning I’m heading ESA’s ESTEC to attend the first workshop of this year’s RexusBexus campaign. We’ll be there until friday. We’ve worked quite hard and are hoping to get selected for the next phase. Even if we are continuing our research even if we don’t get accepted, it is a great opportunity to test the thing.

Given that I really hate checking luggage at airports I was planning to travel as light as possible. Not needing lots of computing power the Eee came as the best candidate to carry around. I haven’t really done much with it than using it to go to University and back home so this is going to be its firs big test. I get to see whether this netbook thing really works for me, though I think it will.

We’ll see how it works…

— ferdy