On 19 Apr 2008 at 8:58, [EMAIL PROTECTED] 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 ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : https://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________
