[metapost] results-caching bugs

Doug McIlroy doug at cs.dartmouth.edu
Fri Oct 28 01:36:51 CEST 2011


The transcript below demonstrates the bugs.  File fig.mp is good
Tex but bad Troff (Eqn).  Mpost is run four times on that file:

1. Mpost expects Tex, finds it and successfully outputs fig.1.
2. Mpost expects Troff, finds fig.mpx and accepts relict fig.1.
3. Mpost expects Troff, finds no fig.mpx, detects bad input and 
   leaves incomplete fig.1.
4. Mpost expects Tex, finds fig.mpx and accepts garbage fig.1.

The grep after each stage searches to see whether the output
file contains "cos", an indicator that "\cos" was treated
according to the rules of Tex.

Test 4 reveals another buglet: two names, fig.mp and eqn
are run together in the diagnostic output.

Newlines have been inserted in the transcript to set off commands;
otherwise it is exactly as captured from a /bin/sh -x run.

+ cat fig.mp
beginfig(1);
	prologues := 1;
	label(btex $\cos x$ etex, (0,0));
endfig;
end;

+ rm -f fig.1 fig.mpx fig.log

+ mpost fig.mp
This is MetaPost, Version 0.993 (Web2C 7.5.6)
(fig.mp [1] )
1 output file written: fig.1
Transcript written on fig.log.

+ grep cos fig.1
(cos) cmr10 9.96265 fshow

+ mpost -T -halt-on-error fig.mp
This is MetaPost, Version 0.993 (Web2C 7.5.6)
(fig.mp [1] )
1 output file written: fig.1
Transcript written on fig.log.

+ grep cos fig.1
(cos) cmr10 9.96265 fshow

+ rm fig.mpx

+ mpost -T -halt-on-error fig.mp
This is MetaPost, Version 0.993 (Web2C 7.5.6)
(fig.mpeqn:fig.mp:3: unquoted escape
 [1] )
1 output file written: fig.1
Transcript written on fig.log.

+ grep cos fig.1

+ mpost fig.mp
This is MetaPost, Version 0.993 (Web2C 7.5.6)
(fig.mp [1] )
1 output file written: fig.1
Transcript written on fig.log.

+ grep cos fig.1

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


From: Doug McIlroy <doug at cs.dartmouth.edu>
To: metapost at tug.org
Subject: [metapost] results-caching bugs
Bug 1.
mpost apparently "optimizes" its behavior by doing nothing
if it can find output lying around that seems to have
come from the given input.  This caused me no end of
confusion when I tried, on the same input, both mpost
and mpost -T.  Unless one knows enough to remove the
outputs between commands, one gets identical results from
both.  By definition they are supposed to be different.

Bug 2.
After a failure, mpost leaves useless output lying
around. This is bad form in general.  But it's
doubly bad when it exacerbates Bug 1.  (Perhaps
this has something to do with interactivity.  I
naively respond "q" to the error prompt.)

Doug McIlroy

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

Date: Thu, 27 Oct 2011 09:18:18 +0200
From: Taco Hoekwater <taco at elvenkind.com>
To: Doug McIlroy <doug at cs.dartmouth.edu>
Cc: metapost at tug.org
Subject: Re: [metapost] results-caching bugs
Hi Doug,

I've never seen this [BUg 1] happen. What version of metapost are you using?
And if it is specific to a particular input and/or invocation, can
you post an example, please?

Yes, you may get a partial output file. This [Bug 2] happens with all the 
Knuthian programs, and is a very tricky thing to fix because the program 
does not always know whether a fatal error indeed invalidates the 
output. Also, the consensus in the (TeX) community is that partial 
output can be valuable during debugging, so it is better to leave it 
than remove it.

You could always test the return code of the executable for a succesful 
run in a script and delete the output if you do not trust it.

[Sadly, this workaround is inadequate because mpost
returns 0 to the shell in run 3.  That's the fault
of the hidden troff pipeline, not mpost itself.

--Doug]


More information about the metapost mailing list