problem with texexec and inline metapost

problem with texexec and inline metapost

[Eckhart Guthöhrlein]

When running texexec over my input file containing a metapost graphic 
(first time, no mpgraph files exist), metapost is called after the first 
run, but then tex is not called again. Therefore, I have to call texexec 
twice to actually get the graphics in my dvi file. Accordingly, changes to 
the mp code become effective only after the second call to texexec (when 
creating pdf. - the dvi driver of course finds the updated file after the 
first run). I thought texexec would do this job for me, so perhaps there is 
a switch I didn't see yet?
When I enable \write18 and \runMPgraphicstrue, creating graphics during 
runtime works fine. But I would prefer to have \write18 disabled.
I tried 'texexec --mptex xyz', but then texexec just quits after its 
version message, doing nothing else. ?
I'm using the latest version of context/texexec together with miktex 2.1. 
Maybe I should just take a break, but I don't see what I have left to try.

Eckhart

Re: problem with texexec and inline metapost

[Hans Hagen]

At 08:01 PM 7/3/01 +0200, Eckhart Guthöhrlein wrote:
>When running texexec over my input file containing a metapost graphic 
>(first time, no mpgraph files exist), metapost is called after the first 
>run, but then tex is not called again. Therefore, I have to call texexec 
>twice to actually get the graphics in my dvi file. Accordingly, changes to 
>the mp code become effective only after the second call to texexec (when 
>creating pdf. - the dvi driver of course finds the updated file after the 
>first run). I thought texexec would do this job for me, so perhaps there is 
>a switch I didn't see yet?
>When I enable \write18 and \runMPgraphicstrue, creating graphics during 
>runtime works fine. But I would prefer to have \write18 disabled.
>I tried 'texexec --mptex xyz', but then texexec just quits after its 
>version message, doing nothing else. ?
>I'm using the latest version of context/texexec together with miktex 2.1. 
>Maybe I should just take a break, but I don't see what I have left to try.

What latest? The ones i uploaded the last few days *do* an extra pass with
external mp graphics {based on checksum calculation] but only with the
undocumented --automprun, so 

texexec --automprun yourfile.tex 

Hans
-------------------------------------------------------------------------
                                  Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                      Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
 tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------

Re: problem with texexec and inline metapost

[Eckhart Guthöhrlein]

At 08:47 04.07.2001 +0200, you wrote:
>texexec --automprun yourfile.tex

This works. Thank you!

Eckhart

Re: problem with texexec and inline metapost

[Eckhart Guthöhrlein]

At 08:47 04.07.2001 +0200, Hans Hagen wrote:
>At 08:01 PM 7/3/01 +0200, Eckhart Guthöhrlein wrote:
> >When running texexec over my input file containing a metapost graphic
> >(first time, no mpgraph files exist), metapost is called after the first
> >run, but then tex is not called again. Therefore, I have to call texexec
> >twice to actually get the graphics in my dvi file. Accordingly, changes to
> >the mp code become effective only after the second call to texexec (when
> >creating pdf. - the dvi driver of course finds the updated file after the
> >first run). I thought texexec would do this job for me, so perhaps there is
> >a switch I didn't see yet?

...

>
>What latest? The ones i uploaded the last few days *do* an extra pass with
>external mp graphics {based on checksum calculation] but only with the
>undocumented --automprun, so
>
>texexec --automprun yourfile.tex

Runtime graphics with \write18 are compiled each tex run, no matter if they 
were changed or not. A checksum calculation could speed up things 
significantly. Perhaps this is a feature worth thinking of, if it can be 
implemented with acceptable effort.

Eckhart

Re: problem with texexec and inline metapost

[Taco Hoekwater]

Eckhart Guthöhrlein wrote:
> 
> At 08:47 04.07.2001 +0200, Hans Hagen wrote:
> >At 08:01 PM 7/3/01 +0200, Eckhart Guthöhrlein wrote:
> > >When running texexec over my input file containing a metapost graphic
> > >(first time, no mpgraph files exist), metapost is called after the first
> > >run, but then tex is not called again. Therefore, I have to call texexec
> > >twice to actually get the graphics in my dvi file. Accordingly, changes to
> > >the mp code become effective only after the second call to texexec (when
> > >creating pdf. - the dvi driver of course finds the updated file after the
> > >first run). I thought texexec would do this job for me, so perhaps there is
> > >a switch I didn't see yet?
> 
> ...
> 
> >
> >What latest? The ones i uploaded the last few days *do* an extra pass with
> >external mp graphics {based on checksum calculation] but only with the
> >undocumented --automprun, so
> >
> >texexec --automprun yourfile.tex
> 
> Runtime graphics with \write18 are compiled each tex run, no matter if they
> were changed or not. A checksum calculation could speed up things
> significantly. Perhaps this is a feature worth thinking of, if it can be
> implemented with acceptable effort.

You need checksum calculation in TeX macros then, since nothing else is
called
inbetween. Possible, of course, but it might actually be slower than
calling MP
regardless of change.

Greetings, Taco

Re: problem with texexec and inline metapost

[Eckhart Guthöhrlein]

At 12:35 14.07.2001 +0200, Taco Hoekwater wrote:
> > >What latest? The ones i uploaded the last few days *do* an extra pass with
> > >external mp graphics {based on checksum calculation] but only with the
> > >undocumented --automprun, so
> > >
> > >texexec --automprun yourfile.tex
> >
> > Runtime graphics with \write18 are compiled each tex run, no matter if they
> > were changed or not. A checksum calculation could speed up things
> > significantly. Perhaps this is a feature worth thinking of, if it can be
> > implemented with acceptable effort.
>
>You need checksum calculation in TeX macros then, since nothing else is
>called
>inbetween. Possible, of course, but it might actually be slower than
>calling MP
>regardless of change.

But what about having texexec/perl calculate the checksums, writing them to 
an auxiliary file, and tex just reading them? And in any case, one can be 
sure that the mp code will not change during the same call to texexec (or 
can there be exceptions?), so that if, say, three tex runs are necessary, 
one run of mp would be sufficient. Setting some switch may be sufficient to 
achieve this.

Eckhart

Re: problem with texexec and inline metapost

[Taco Hoekwater]

Eckhart Guthöhrlein wrote:
> 
> But what about having texexec/perl calculate the checksums, writing them to
> an auxiliary file, and tex just reading them? And in any case, one can be
> sure that the mp code will not change during the same call to texexec (or
> can there be exceptions?), so that if, say, three tex runs are necessary,
> one run of mp would be sufficient. Setting some switch may be sufficient to
> achieve this.

It *can* change with a texexec, imagine using the page number in the MP 
code, for example. More serious problem: even if texexec calculates the
checksum, then how would the TeX macro code know its status without
first
calculating a checksum itself? It needs to compare two checksums: one
from
this run against the one from the previous run.

Greetings, Taco

Re: problem with texexec and inline metapost

[Hans Hagen]

At 12:38 PM 7/14/2001 +0200, you wrote:
>At 12:35 14.07.2001 +0200, Taco Hoekwater wrote:
>> > >What latest? The ones i uploaded the last few days *do* an extra pass 
>> with
>> > >external mp graphics {based on checksum calculation] but only with the
>> > >undocumented --automprun, so
>> > >
>> > >texexec --automprun yourfile.tex
>> >
>> > Runtime graphics with \write18 are compiled each tex run, no matter if 
>> they
>> > were changed or not. A checksum calculation could speed up things
>> > significantly. Perhaps this is a feature worth thinking of, if it can be
>> > implemented with acceptable effort.
>>
>>You need checksum calculation in TeX macros then, since nothing else is
>>called
>>inbetween. Possible, of course, but it might actually be slower than
>>calling MP
>>regardless of change.
>
>But what about having texexec/perl calculate the checksums, writing them 
>to an auxiliary file, and tex just reading them? And in any case, one can 
>be sure that the mp code will not change during the same call to texexec 
>(or can there be exceptions?), so that if, say, three tex runs are 
>necessary, one run of mp would be sufficient. Setting some switch may be 
>sufficient to achieve this.

actually, if you search texexec.pl for the word checksum, you will see that 
something like that is done. One pitfall is when one uses random numbers 
[context sets the mp random number in order to have control over successive 
runs]. Th eexperimental --automp will give you the functionality needed. 
With runtime graphics there is no saving to gain exept calculating a 
checksum per graphic and saving it in the tuo file. The best saving is to 
use reusable graphic or unique ones when possible [is possibel in most cases]

Hans
-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
  tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------

Re: problem with texexec and inline metapost

[Hans Hagen]

At 06:27 PM 7/14/2001 +0200, Eckhart Guthöhrlein wrote:
>At 12:57 14.07.2001 +0200, you wrote:
>>Eckhart Guthöhrlein wrote:
>> >
>> > But what about having texexec/perl calculate the checksums, writing 
>> them to
>> > an auxiliary file, and tex just reading them? And in any case, one can be
>> > sure that the mp code will not change during the same call to texexec (or
>> > can there be exceptions?), so that if, say, three tex runs are necessary,
>> > one run of mp would be sufficient. Setting some switch may be 
>> sufficient to
>> > achieve this.
>>
>>It *can* change with a texexec, imagine using the page number in the MP
>>code, for example. More serious problem: even if texexec calculates the
>>checksum, then how would the TeX macro code know its status without
>>first
>>calculating a checksum itself? It needs to compare two checksums: one
>>from
>>this run against the one from the previous run.
>
>So, why not keeping two checksums in the aux file? No, no, all right, I 
>admit that I did not think beyond my simple applications. Metapost is 
>actually quite fast, so I must agree with yoz that the additional gain of 
>speed (maybe even not...) is probably not worth the trouble. And it is 
>likely that there will be more problems than positive effects and than I 
>can imagine... So let's forget about it, it was just an idea, coming up 
>because my - until recently - preferred method texexec --automprun does 
>not work as expected at the moment (see the other thread).

much faster processing can be achieved with mp as dll and kpsea as server 
app [only have file base in mem once], which is something fptex wizard 
fabrice popineau is thinking/working about/on.

Hans
-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
  tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------

Re: problem with texexec and inline metapost

[Eckhart Guthöhrlein]

At 12:57 14.07.2001 +0200, you wrote:
>Eckhart Guthöhrlein wrote:
> >
> > But what about having texexec/perl calculate the checksums, writing them to
> > an auxiliary file, and tex just reading them? And in any case, one can be
> > sure that the mp code will not change during the same call to texexec (or
> > can there be exceptions?), so that if, say, three tex runs are necessary,
> > one run of mp would be sufficient. Setting some switch may be sufficient to
> > achieve this.
>
>It *can* change with a texexec, imagine using the page number in the MP
>code, for example. More serious problem: even if texexec calculates the
>checksum, then how would the TeX macro code know its status without
>first
>calculating a checksum itself? It needs to compare two checksums: one
>from
>this run against the one from the previous run.

So, why not keeping two checksums in the aux file? No, no, all right, I 
admit that I did not think beyond my simple applications. Metapost is 
actually quite fast, so I must agree with yoz that the additional gain of 
speed (maybe even not...) is probably not worth the trouble. And it is 
likely that there will be more problems than positive effects and than I 
can imagine... So let's forget about it, it was just an idea, coming up 
because my - until recently - preferred method texexec --automprun does not 
work as expected at the moment (see the other thread).

Eckhart