Re: Arrow head filling patch, and "port.trm"

[Chris K <gnu...@li...>]

Ethan A Merritt wrote:
> On Saturday 01 April 2006 02:24 pm, you wrote:
> 
> I think the thread messages arrived here out of order.
> After I responded to the first in which I saw the "set term fd <fd>"
> proposal, I saw two more with the same proposal and no mention of
> my first response.  But they may well have been sent earlier and
> arrived later.

I wrote the response to your first message last night, and did not push send
until today, alongside me second response.  I plead staying up till 3AM and
temporary incapacity.

>  
>>> If you need a communication channel aside from stdin/stdout,
>>> create a named pipe and use "set output" to pass its name.
>> Why on earth might it matter whether I use mkfifo or a pipe like that?
> 
> Because if it's a named pipe, it can be used with the existing
> "set output" mechanism for 2-way communication. There are several
> old threads discussing this, and I think at least one bit of sample
> code on the web site showing how this can be used to drive gnuplot
> from python code.
>  

Now that is something that might be very useful in the future.  Right now
"port.trm" gets no feedback from the client.   The client can only send gnuplot
"set term port option badger 10 snake 1 badger 3" to communicate back.

A two-way pipe from the port.trm code and the client would be a much more
complicated protocol.  I have no clear idea what I want to "say", so I can't
implement that yet.  But it could be needed for getting font metrics or the
extent of text blocks.  I still have not done enhanced text.

I have used gnuplot.py and scipy to drive gnuplot to display my data.  But they
did not use a special terminal.  They were more of a front end than a back end.
 Cairo has made it easy to do both at once.

The use of a file descriptor / pipe / named fifo allows the front-end and
back-end to be separable concepts, loosely coupled.  This flexibility was not
provided by the other terminals, so I wrote port.trm.

>> It's not like I'm doing something crazy like serving the results via https.
> 
> Passing a file descriptor by number via stdin to another process sounds
> crazy to me.  If it's a child process you might as well just
> let it inherit the file descriptor directly, similar to the piping 
> between gnuplot and gnuplot_x11.  If it's not a child  process, let's just
> say there is some question whether the number will be of any use.

I was not sufficiently clear.  It will be a child process.  It does just inherit
the open file descriptor.  But rather than hard-code which integer, or use an
environment variable, or a command line parameter, I had thought to make the
port.trm take a new option "set term port fd 5".  But now I know "set out
'/dev/fd/5'" works just as well.

> If for some reason you don't want to create a named pipe,
> then on current linux systems you could try
> 	set output "/proc/${pid}/fd/whatever"

With the pid...that would be ugly.  Thus the child process idea.

> To me that seems ugly also, but less ugly than passing a bare number
> via stdin. I haven't ever tried this however, so I am not sure what
> extra wrinkles (buffering? permissions?) might arise.

I did the experiment before I wrote port.trm; it works for haskell calling a
test program "hi-n".  This is the haskell code (which sends the bare number 'w'
as ascii):

> main = do
>   (r,w) <- createPipe
>   (toChild,fromChild,fromChildErr,child) <- runInteractiveProcess "./hi-n" []
Nothing Nothing
>   hPutStrLn toChild (show w)
>   hFlush toChild

I did indeed need to call hFlush.  But that was not hard to figure out.  The c
code is a snippet that reads 'w' and uses write/fdopen/fprintf to verify that it
can send text to the parent process.

> 
>> It's not like I'm doing something crazy like encoding the results in
>> XML.  That's svg.trm's job.
> 
> Heh.
> So, given the date, you think someone should start writing
> a flash.trm instead?
> 

That would be an excellent project for someone else.  I have never created any
flash / director / shockwave / blink-tag code.

-- 
Chris