[texshop] Experimental version 4.33

[koch at uoregon.edu]

Folks,

An experimental version of TeXShop is available:

	https://pages.uoregon.edu/koch/texshop433.zip <https://pages.uoregon.edu/koch/texshop433.zip>

This is not an official release. Feel free to try it and report back.

This version should fix the bug Bruno reported on Catalina, in which the left/right arrow on the pdf toolbar vanishes. However, if this bug affected you, you may have to do a little work to get rid of the bug and see the arrows:

	a) Open a project and convert it to single page form

	b) Use "Customize Toolbar" to remove the left/right arrow from the toolbar if present.
	Then put it back there if you like.

	c) Convert back to double page mode.

	d) Repeat step b).

After this, things should work as expected. 

Second, at the TUG meeting on August 9 in Palo Alto, Frank Mittelbach reported on recent LaTeX developments. Work on improving LaTeX is again active. The LaTeX team has a large number of test files which they process before making a new release. But even with this step, unexpected results sometimes occur. So they had adopted a new step before release. They release a "dev" version of LaTeX, which appears in TeX Live. Users can test this version with their favorite documents. To enable this, TeXShop now has, in ~/Library/TeXShop/Engines/Inactive, engines for lualatex-dev, pdflatex-dev, and xelatex-dev. These work just like the current engines for lualatex, pdflatex, and xelatex except that they use the "dev" form of LaTeX.

------------------------

Finally, we know more about the "sudden halt" bug in TeXShop.  In the middle of the summer, two users sent me code which consistently exhibits the bug. THANK YOU; THANK YOU. Using these sources and various LOG statements, I was able to watch the bug occur. Each time that happened, pdflatex quit with status 13 or status 142. According to Wikipedia, status errors above 128 often are system errors of status "s" where the reported status is 128 + s. Notice that 128 + 13 = 142.

Status numbers are not set in stone; programs can be creative. But usually 13 = SIGPIPE, indicating a broken pipe, and the error often means that a program tried to write to a pipe with no reader.

Here it is helpful to know how TeXShop typesets. Since TeXShop is written in Cocoa, it does not call the system directly to run TeX. Instead a creates an NSTask, which is a Cocoa object designed to run other applications. TeXShop also creates an NSPipe (a Cocoa object to mirror an actual Unix pipe) and NSFile (a Cocoa object to read the pipe). 

Then it tells the NSTask to run, and an entirely separate program begins typesetting. TeXShop and that program are independent except that TeXShop can send the program a "halt" message and the program can write to the pipe.

TeXShop reads this pipe information indirectly. It tells the NSFile object to "read the pipe and notify when something is in the pipe buffer". This reading is done by Cocoa with no TeXShop code. When NSFile has something, it calls a routine in TeXShop called "writeTeXOutput." This small routine reads the buffer and puts that text in the console and then calls NSFile again saying "read the pipe and notify when something is in the pipe buffer". That last call is essential, because the NSFile object will only read once unless told to repeat the action.

------------------

This means that two things might go wrong. For some reason, TeXShop might tell the NSTask to stop in the middle of typesetting. I looked into that with Log statements and a search of the code available in XCode, and I don't think that is happening.

Or maybe writeTeXOutput isn't acting fast enough, and material overflows the pipe before NSFile is told to read again.

On the first day of the TUG conference, Martin Hairer wrote me from London with the same analysis and the same suspicion. He noticed that I used writeTeXOutput to parse the console information and look for errors, which "Goto Error" could later use. So he rewrote my code in a very clever way to just retrieve the data from the pipe and then call "dispatch_async(process_queue, ^{ ...}" to process the data independently, while writeTeXOutput immediately returned to waiting for more from the pipe.

His code is in version 4.33 of TeXShop.

Unfortunately, after considerable work I was able to trigger the bug even with this change, and so was Martin. But we both think things are working better now.

If you want to test this, I recommend setting three defaults:

	defaults write TeXShop DisplayLogInfo NO

	defaults write TeXShop UseTerminationHandler YES

	defaults write TeXShop RepeatTypesetOnError!3 NO

------------------------

After all this, we come to the key question. After years and years of working, why is this NSPipe suddenly failing. And why doesn't Apple, in the documentation, warn of problems with bad pipes
and explain how to work around them. There are essentially no change in the documentation
for all of this NSTask material between TeXShop in 2002 and TeXShop today, except the Termination Handler call.

-------------------------

There is one piece of good news. After adding Hairer's code, I have tried over and over again to trigger the error in the Catalina beta. I've never been successful. 

So this may be a bug which Apple introduced in High Sierra and fixed in Catalina. The only problem is that Catalina has a substantial amount of debugging code which will be removed before releasing the system, and we know that debugging code hides the bug. It is possible, but very difficult, to trigger it in XCode while debugging in Mojave.

--------------------------

Don't worry. More work will be done. But this is where we are as of the end of the TUG Palo Alto Conference.

Dick Koch









-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/texshop/attachments/20190822/8100c0fe/attachment.html>