[tex-live] Re: Please enable ipc in tex

[Jonathan Fine]

"David Kastrup" <dak at gnu.org> wrote in message
news:x51xjuvz7b.fsf at lola.goethe.zz...
> "Jonathan Fine" <J.Fine at open.ac.uk> writes:
>
> > Please, if not already done, would you build TeX with
> >   configure --enable-ipc
> >
> > Here is why:
> >
> > Ordinarily, TeX buffers its output dvi file.
> > Tom Rokicki made changes here on the NeXT platform.
> > This allowed dvi files to be previewed while TeX was still running.
> >
> > --enable-ipc adds these changes to the system dependent part of TeX.
> > This adds a command line flag --ipc, whic turns off buffering.
> >
> > The texd project, and also dvipng and PyX, use this when available.
> > (All 3 projects are on sourceforge.)
>
> dvipng uses this, really?  I am not sure about that.  While dvipng
> can work on a pipe in real time, it would not take a look at the
> socket from the ipc flag unless I am mistaken, and the socket
> interaction is necessary, isn't it?

The socket remarks might be a distraction to what is, in my opinion,
a simple request.  David might be relying on inaccurate documentation
(see below).

As stated above,
  tex --ipc
turns off buffering of the output dvi file.

For dvipng to work efficiently "in real time", this buffering must be
turned off.  Otherwise you have to wait for it to come out of the
pipe.

For "real time" and interactive applications, the output buffering is
a real pain.  It can even be thought of as an example of premature
optimization.
   http://c2.com/cgi/wiki?PrematureOptimization


> Maybe it would be a good idea to add a separate option to web2c that
> merely flushes the DVI buffer at the end of each page without fiddling
> around with sockets?  I don't think that many programs exist that
> actually need the socket.  The buffer flushing should be sufficient
> in most cases, right?

As stated above,
  tex --ipc
does precisely what David suggests.

I don't recall exactly what --enable-ipc adds to TeX beside this.

> It would also have the advantage of compiling and working without
> additional library dependencies on probably pretty much every
> platform.  So one would not get into the constant "should it be
> enabled or disabled" hassle that the --ipc option is suffering from.

To summarize, I am suggesting:
1.  No new code on Unix/Linux platforms
2.  Enabling of existing code on Unix/Linux platforms
3.  No divergence between Debian and TeX live on this matter
    (on Unix/Linux platforms)
4.  On Windows and other platforms, --ipc turns off buffering

BTW, here is the Debian change request:
  http://lists.debian.org/debian-tetex-maint/2001/06/msg00107.html

Here is another request for this change:

http://www.mail-archive.com/debian-tetex-maint@lists.debian.org/msg02029.html

I think the sockets side of --enable-ipc is a distraction.

The info page at:
  http://www.fifi.org/cgi-bin/info2www?(web2c)tex+invocation
reads
==
`-ipc'
`-ipc-start'
     With either option, TeX writes its DVI output to a socket as well
     as to the usual `.dvi' file.  With `-ipc-start', TeX also opens a
     server program at the other end to read the output.
==

This is, I think, wrong.  The --ipc option does not, so far as I can
tell, actually cause writing to a socket.

However, I'm not at this moment in a position to check this.


> Olaf, what do you think?
I'd like to join in on this request.


Jonathan