Looking for ANSI/VT100 code replacement.

[Dan Nelson]

In the last episode (May 21), alexander said:
> Ohh...sorry for not telling you this. Yes. The app works alright when
> executed from the console. But my problem is with xterm or Eterm.
> They don't handle VT100 very well. I've added a nanosleep after each
> VT100 output but that didn't solve the issue. In fact Eterm or xterm
> might not update the value for as long as 5-8 seconds. I tested
> burncd's code and it uses fprintf to update the bytes it sends. And
> that works perfectly under Eterm and xterm.

5 seconds?  Do you have heavy packet loss between the server and your
xterm?
 
> The app needs to handle at least 40000h updates in 10 seconds. But as
> you said I can break that down to ~ 100 updates per second. However I
> don't think that that's going to do much of a different with the
> delays I'm experiencing under Eterm/xterm.

Cut it down to 1 or 2 updates per second, then.  If this is a progress
indicator, you don't need more than that.  If you don't want to spend
time getting timestamps, just print your counter every 64k updates. 
that'll give you a little over 1 update per second.
 
> The app is used to upload data to another device. Under the console
> the upload time is ~ 11.5 seconds. Under Eterm it is ~ 25 seconds.
> That's why I really want to get rid of the VT100 stuff.
> 
> The nanosleep delay I'm using is 0,00050000. I also disabled all the
> nanosleep syscalls, but Eterm/xterm still lags awfully. Plus the
> cursor jumps forth and back.

If you're worried about running time, adding sleeps is definitely not
the right way to speed it up :)

-- 
	Dan Nelson
	dnelson at allantgroup.com