[tex-live] mysterious mpost problem

[h h extern]

Taco Hoekwater wrote:
> Hi,
> 
> This sounds very familiar. I think I remember Hans Hagen mentioning
> (privately?) this as well, but I can't seem to find any e-mail
> regarding this any more. I hope Hans remembers.
> 
> Greetings, Taco
> 
> Werner LEMBERG wrote:
> 
>> [MetaPost 0.641 (Web2C 7.5.3)
>>  kpathsea version 3.5.3]
>>
>> Please do the following, using the attached files:
>>
>>   . Create mf2pt1.mem with `mpost --ini', using mf2pt1.mp.
>>
>>   . Run `mpost --mem=mf2pt1 nospecial.mf'.
>>
>> Now compare `nospecial.0' with `nospecial.1': The files should be
>> identical, but they aren't on my GNU/Linux box.  `nospecial.0' doesn't
>> contain any lines produced by the `special' command.
>>
>> On the other hand,
>>
>>   mpost '&mf2pt1 \input nospecial.mf'
>>
>> gives the expected result.
>>
>> AFAIK, the results should be the same, so it looks like a bug in
>> mpost.  Am I missing something?

it's already long ago that we ran into this, and discussed it; it has to do with 
the fact that those specials are collected at the mem boundary and when that 
boundary changes (due to either a change in the cnf file or due to another 
progname environment) things gets lost [strings getting lost is one side effect, 
but i think mp can even bomb]; in tex, some mem arrays can be adapted after 
format generation, like the top/bot men things, probably because the boundary 
mem areas are not used, contrary to metapost, and the problem is that in mp this 
is not stored [normally the frozen mem allocations are stored and changes in the 
cnf file have no consequence];

Hans

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
      tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                              | www.pragma-pod.nl
-----------------------------------------------------------------