On 19 Apr 2008 at 8:58, ntg-context-request@ntg.nl wrote:

...

...

...

Everything I read below says there should be a 'plain.mem' in the folder where you ran theat file in. If there really really isn't, then my only advise to you is to buy a less thieving operating system, as it seems this one steals your files before you can even have an admiring look at them. :-)

May be you are right that operating system steals files. We should do something against that.

Lutz Haseloff has send me his test (he too sees no 'mpost.mem'):

Hallo Taco,

When Hans and I tested this, it worked just fine.

Have you tested exactly my example on a windows minimal?

Does the high-level context interface work for you at all, btw?

The high-level interface seems to work.

I have no idea what is going on, and I cannot test myself, so I am even more lost than you are. MPlib firmly believes it has written a file:

Beginning to dump on file mpost.mem (mem=mpost 8.4.18) at most 736 strings of total length 3629 3326 memory locations dumped; current usage is 1021&2227 501 symbolic tokens

Yes, I know this.

There is nothing more I myself can do about it.

Do you use a sort of io-buffering in the mplib or a memory-file? When is the file flushed or closed? Wolfgang