[ts-gen] redirecting shim output to python script (was MacOS ...)

[Bill Pippin]

Mike,

I'm answering you first only because the answer is so simple.  For
others reading this thread --- Ric and Nils in particular --- please
understand that I need to work on releasing the shim before furthur
replies to the other posts this morning are truly to the point.

> I would certainly be willing to poke around the source code, but I am
> not too familiar with it.  Bill, are there files you would recommend
> scrutinizing?

Thanks much for the offer, and I will delighted to take you up on it in
the future.  For now, with what I believe to be your problem already
diagnosed, and a fix in place although not yet released, the fastest
approach for me is just to concentrate on getting a release out. 

By the way, to answer your question literally, the fix triggered by
your reports is an added call to setvbuf in cusp.c, so you may be
interested to know that the added init code went there.  Not so much
traditionally buggy code, rather missing computation. 

> I too am seeing lockup ... suggesting to me that the cause of the
> lockup is not at the line in "leaf.c" as Ric suspects.

True.  A process hang --- that is, an endless loop --- and an IPC,
inter-process communication hang --- livelock, or deadlock, or buffer
lag, or just waiting on events --- are distinct problems.

You can tell the difference by using the keyboard stdin to feed the shim,
or by using a shim-script, as with the no-extension four-character named 
files in the exs directory.  If there is an endless loop, the problem
remains, and if it goes away, the problem is inter-process.  I believe
you are seeing an IPC hang, and welcome reports to the contrary, although
I may not be able to respond for a while, as I deal with other messages
first.

If you want to get the shim working before I get a release out,
you may want to reconsider my post of Thu, 14 May 2009 14:59:19 EDT,
subject: Re: [ts-gen] redirecting shim output to python script.
There I wrote:

> Mike, please consider using the log file in place of the stdout for
> now.  That is, start the shim with the file option, open the log
> file, default name log/ShimText, or whatever you've renamed it via
> your config file options, and read the log lines from that file.

Or you can wait for a release, which I have been working on pulling
together.  I'd prefer to avoid making one with known bugs w.r.t. Ric's
problem, which is one reason I've delayed, but in any case what I
believe to be the fix for the problem you are seeing --- lack of line
buffering to stdin --- is already in place in the internal code I'm
working with.  You'll be able to take advantage of it as soon as I
push the next tarball.

Thanks,

Bill