Gaurav Saxena wrote:

When I used the sh statement above, I didn't get the output of the program *at event-time*

	You're running into stdout output buffering.. you probably
	have printf()s instead of fprintf(stderr,) for your debugging messages.

	You will probably see the same behavior if you redirect your program's
	output to a file, and try to view the contents of the file from another window,
	eg:

		./test > test.out 2>&1

	..then from another window:

		tail -f test.out

	..you'll probably only see your output when the program exits, or
	only after it prints *lots* of output (causing the buffer to automatically flush)

	Several ways to fix this; the easiest is to just always use
	fprintf(stderr, ".."); as stderr is always unbuffered.
	Good habit to get into.

	Another technique is to disable stdout buffering completely
	by adding this single line at the top of your main():

			setbuf(stdout, 0);

	..that way your printf()s will all be unbuffered, and then you don't
	have to change anything.

	Or if you like the iostream stuff, you can use cerr instead of cout,
	or if you use cout, always use 'endl' to ensure lines flush, eg:

		cout "Some text" << endl;		// endl prints a \n and flushes

observation. I cannot justify it though. From your video I felt this wasn't the expected behaviour, do you think its because I'm coding on linux ?

	This is an issue you can run into on both platforms, unix and windows,
	but situations vary.

	Unix is fairly consistent about this.

	The reason it works in gnome-terminal is because that's a "real tty",
	so stdout flushes on a per-line basis. But when writing to pipes or
	files (as in the case of fluid, the former) the C library buffers
	at BUFSIZ bytes IIRC, unless buffering is disabled (eg. with setbuf() example above)

Standing by.. btw, really good tutorial for fluid. I'm sure people are earnestly waiting for the next episode.

	Yes, wish I could get to it.