\bufferprefix in MKIV

\bufferprefix in MKIV

[Mojca Miklavec]

Dear Hans,

one of the latest versions of MKIV breaks the following code:
    \edef\GNUPLOTfile  {\bufferprefix gnuplot-\GNUPLOTnumber}%
since \bufferprefix is not defined any more. Is there any reason for
that? In particular ...

meta-ini.mkiv:  {\bufferprefix mprun.#1}
page-app.mkiv:  {\immediate\openout\scratchwrite=\bufferprefix\@@texdim.tmp
page-app.mkiv:  {\readlocfile{\bufferprefix\@@texdim.tmp}\donothing\donothing}
page-app.mkiv:   \executesystemcommand{texexec
\bufferprefix\@@texapp.tex --once --batch}%
page-app.mkiv:     \executesystemcommand{dvips \bufferprefix\@@texapp}%
page-app.mkiv:     \executesystemcommand{ps2pdf
\bufferprefix\@@texapp.ps \bufferprefix\@@texapp.pdf}%
page-app.mkiv:%      \executesystemcommand{texmfstart pstopdf
\bufferprefix\@@texapp.ps \bufferprefix\@@texapp.pdf}%
page-app.mkiv:        [\bufferprefix\@@texapp.\ifdone eps\else pdf\fi]

Thanks,
    Mojca
___________________________________________________________________________________
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  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: \bufferprefix in MKIV

[Wolfgang Schuster]

Am 26.01.2011 um 17:46 schrieb Mojca Miklavec:

> Dear Hans,
> 
> one of the latest versions of MKIV breaks the following code:
>    \edef\GNUPLOTfile  {\bufferprefix gnuplot-\GNUPLOTnumber}%
> since \bufferprefix is not defined any more. Is there any reason for
> that? In particular ...

MkIV stores the buffer content in memory and therefore no external
file was generated which needed a protected name with \bufferprefix.

When you save a buffer with \savebuffer[…] context adds \jobname
as prefix to the file, therefore you can use \jobname in \GNUPLOTfile.

You should also take a look into Adityas filter module.

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  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: \bufferprefix in MKIV

[Mojca Miklavec]

On Wed, Jan 26, 2011 at 23:53, Wolfgang Schuster wrote:
> Am 26.01.2011 um 17:46 schrieb Mojca Miklavec:
>
>> Dear Hans,
>>
>> one of the latest versions of MKIV breaks the following code:
>>    \edef\GNUPLOTfile  {\bufferprefix gnuplot-\GNUPLOTnumber}%
>> since \bufferprefix is not defined any more. Is there any reason for
>> that? In particular ...
>
> MkIV stores the buffer content in memory and therefore no external
> file was generated which needed a protected name with \bufferprefix.
>
> When you save a buffer with \savebuffer[…] context adds \jobname
> as prefix to the file, therefore you can use \jobname in \GNUPLOTfile.

I see that the line
    core-fil.mkiv:\def\bufferprefix{\ifprotectbuffers\jobname-\fi}
has recently disappeared from ConTeXt (after 14th January in any case).

Well ... I can use "\jobname-" of course. I only didn't know if the
change was intentional or not, in particular because the command is
still referenced in quite some mkiv files.

Mojca
___________________________________________________________________________________
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  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: \bufferprefix in MKIV

[Hans Hagen]

On 26-1-2011 11:53, Wolfgang Schuster wrote:
>
> Am 26.01.2011 um 17:46 schrieb Mojca Miklavec:
>
>> Dear Hans,
>>
>> one of the latest versions of MKIV breaks the following code:
>>     \edef\GNUPLOTfile  {\bufferprefix gnuplot-\GNUPLOTnumber}%
>> since \bufferprefix is not defined any more. Is there any reason for
>> that? In particular ...
>
> MkIV stores the buffer content in memory and therefore no external
> file was generated which needed a protected name with \bufferprefix.

Indeed, I'm in the process of removing some of these 'no longer needed 
features', sorry for the noise.

Hans



-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
                                              | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
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  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: \bufferprefix in MKIV

[Aditya Mahajan]

On Wed, 26 Jan 2011, Wolfgang Schuster wrote:

>
> Am 26.01.2011 um 17:46 schrieb Mojca Miklavec:
>
>> Dear Hans,
>>
>> one of the latest versions of MKIV breaks the following code:
>>    \edef\GNUPLOTfile  {\bufferprefix gnuplot-\GNUPLOTnumber}%
>> since \bufferprefix is not defined any more. Is there any reason for
>> that? In particular ...
>
> You should also take a look into Adityas filter module.

On a unrelated note, I have been thinking if I can extend the filter 
module to take care of features provided by lilypond and gnuplot modules. 
IIUC, in both these modules, the input is transformed before being written 
to an output file, then an external filter is run and the output is read 
back again. If we  restrict ourselves to MkIV, then the transforming the 
input can be done in a lua function; the filter module already takes care 
of the rest of the book-keeping.

Do you think that it makes sense to have such a feature? Then you could 
just define the gnuplot module as:

\usemodule[filter]

\defineexternalfilter[GNUPLOT]
    [filter={gnuplot --appropriate options},
     conitnue=yes,
     transformation=thirddata.GNUPLOT.transformation,
    ]

where thirddata.GNUPLOT.transformation is a lua function that does all the 
fancy processing.

What do you think?

Aditya
___________________________________________________________________________________
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  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: \bufferprefix in MKIV

[Hans Hagen]

On 27-1-2011 8:08, Aditya Mahajan wrote:

> where thirddata.GNUPLOT.transformation is a lua function that does all
> the fancy processing.

What exactly does it replace then? preprocessing in gnuplot and lilypond?

Hans

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
                                              | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
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  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: \bufferprefix in MKIV

[Aditya Mahajan]

On Thu, 27 Jan 2011, Hans Hagen wrote:

> On 27-1-2011 8:08, Aditya Mahajan wrote:
>
>> where thirddata.GNUPLOT.transformation is a lua function that does all
>> the fancy processing.
>
> What exactly does it replace then? preprocessing in gnuplot and lilypond?

Yes... the preprocessing can be done more cleanly in lua. And these module 
will not have to do the book-keeping of creating external files and 
running programs on them. In addition, you get all the features of the 
filter module. So one could set the output directory:

     \setupGNUPLOT[directory=gnuplot]

will create all temporary files in a 'gnuplot' directory.

If a figure depends on an external data-set, you can choose to always run 
gnuplot on it.

     %by default only rerun if the file has changed
     \setupGNUPLOT[continue=yes]


     \startGNUPLOT[continue=no]
      ... read from data-set
     \stopGNUPLOT


etc. Not to mention less maintenance for everyone.
___________________________________________________________________________________
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  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: \bufferprefix in MKIV

[Mojca Miklavec]

On Fri, Jan 28, 2011 at 00:37, Aditya Mahajan wrote:
>
> etc. Not to mention less maintenance for everyone.

Well ... I do almost-zero-maintainance as must be apparent from the
logs if anyone keeps them :) :) :)

We can take a look together to see if the modules can be made to work
nicely with each other.

Mojca

(But ... the gnuplot module needs to keep working for MKII. I don't
want to sacrifice that.)
___________________________________________________________________________________
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  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: \bufferprefix in MKIV

[Aditya Mahajan]

On Fri, 28 Jan 2011, Mojca Miklavec wrote:

> On Fri, Jan 28, 2011 at 00:37, Aditya Mahajan wrote:
>>
>> etc. Not to mention less maintenance for everyone.
>
> Well ... I do almost-zero-maintainance as must be apparent from the
> logs if anyone keeps them :) :) :)

:)

> We can take a look together to see if the modules can be made to work
> nicely with each other.

Lets take this off-list.
>
> (But ... the gnuplot module needs to keep working for MKII. I don't
> want to sacrifice that.)

Can you send me the latest version of the gnuplot module? 
Aditya
___________________________________________________________________________________
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  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: \bufferprefix in MKIV

[Hans Hagen]

On 28-1-2011 12:49, Mojca Miklavec wrote:
> On Fri, Jan 28, 2011 at 00:37, Aditya Mahajan wrote:
>>
>> etc. Not to mention less maintenance for everyone.
>
> Well ... I do almost-zero-maintainance as must be apparent from the
> logs if anyone keeps them :) :) :)
>
> We can take a look together to see if the modules can be made to work
> nicely with each other.
>
> Mojca
>
> (But ... the gnuplot module needs to keep working for MKII. I don't
> want to sacrifice that.)

just make two modules then and freeze the mkii one; it's painful to have 
all that testing for version code in there and cripple the mkiv support 
by that

Hans

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
                                              | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
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  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: \bufferprefix in MKIV

[Mojca Miklavec]

On Thu, Jan 27, 2011 at 20:08, Aditya Mahajan wrote:
>
> On a unrelated note, I have been thinking if I can extend the filter module
> to take care of features provided by lilypond and gnuplot modules. IIUC, in
> both these modules, the input is transformed before being written to an
> output file

It is not really transformed, at least not in the case of gnuplot. At
the moment it is composed out of three parts (so it should be easier
to handle):
a) set term <nameofterminal> <options>; set output
<jobname-gnuplot-number-term.extension>
b) everything inside \startGNUPLOTinclusions ...
\stopGNUPLOTinclusions (that could be covered by continue=yes to some
extent)
c) everything inside \startGNUPLOTscript ... \stopGNUPLOTscript

But if I was to rewrite the code for MKIV, I would try to pipe input
to gnuplot and pipe it back to ConTeXt to avoid zillions of
intermediate files (and maybe also to make it slightly faster).

> then an external filter is run and the output is read back
> again. If we  restrict ourselves to MkIV, then the transforming the input
> can be done in a lua function; the filter module already takes care of the
> rest of the book-keeping.
>
> Do you think that it makes sense to have such a feature? Then you could just
> define the gnuplot module as:
>
> \usemodule[filter]
>
> \defineexternalfilter[GNUPLOT]
>   [filter={gnuplot --appropriate options},
>    conitnue=yes,
>    transformation=thirddata.GNUPLOT.transformation,
>   ]

What exactly would the transformation do? Append the first line (set
terminal etc.)?

Other functionality of current module includes features such as
   \setupGNUPLOTterminal[context][width=10cm,height=7cm,dashed=no]
but that is not part of your work.

Mojca
___________________________________________________________________________________
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  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: \bufferprefix in MKIV

[Henning Hraban Ramm]

Am 2011-01-27 um 20:08 schrieb Aditya Mahajan:

> On a unrelated note, I have been thinking if I can extend the filter  
> module to take care of features provided by lilypond and gnuplot  
> modules. IIUC, in both these modules, the input is transformed  
> before being written to an output file, then an external filter is  
> run and the output is read back again. If we  restrict ourselves to  
> MkIV, then the transforming the input can be done in a lua function;  
> the filter module already takes care of the rest of the book-keeping.
>
> Do you think that it makes sense to have such a feature? Then you  
> could just define the gnuplot module as:
>
> \usemodule[filter]
>
> \defineexternalfilter[GNUPLOT]
>   [filter={gnuplot --appropriate options},
>    conitnue=yes,
>    transformation=thirddata.GNUPLOT.transformation,
>   ]
>
> where thirddata.GNUPLOT.transformation is a lua function that does  
> all the fancy processing.
>
> What do you think?

I already replaced the LilyPond module by a filter setup, see
http://wiki.contextgarden.net/LilyPond

It doesn't work completely the same, but good enough.
And since every user has different needs, the filter approach is more  
flexible and thus better than a bunch of hardcoded setup options.


Greetlings from Lake Constance!
Hraban
---
http://www.fiee.net/texnique/
http://wiki.contextgarden.net
https://www.cacert.org (I'm an assurer)

___________________________________________________________________________________
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  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Re: \bufferprefix in MKIV

[Aditya Mahajan]

On Fri, 28 Jan 2011, Henning Hraban Ramm wrote:

> Am 2011-01-27 um 20:08 schrieb Aditya Mahajan:
>
>> On a unrelated note, I have been thinking if I can extend the filter module 
>> to take care of features provided by lilypond and gnuplot modules. IIUC, in 
>> both these modules, the input is transformed before being written to an 
>> output file, then an external filter is run and the output is read back 
>> again. If we  restrict ourselves to MkIV, then the transforming the input 
>> can be done in a lua function; the filter module already takes care of the 
>> rest of the book-keeping.
>> 
>> Do you think that it makes sense to have such a feature? Then you could 
>> just define the gnuplot module as:
>> 
>> \usemodule[filter]
>> 
>> \defineexternalfilter[GNUPLOT]
>>  [filter={gnuplot --appropriate options},
>>   conitnue=yes,
>>   transformation=thirddata.GNUPLOT.transformation,
>>  ]
>> 
>> where thirddata.GNUPLOT.transformation is a lua function that does all the 
>> fancy processing.
>> 
>> What do you think?
>
> I already replaced the LilyPond module by a filter setup, see
> http://wiki.contextgarden.net/LilyPond
>
> It doesn't work completely the same, but good enough.
> And since every user has different needs, the filter approach is more 
> flexible and thus better than a bunch of hardcoded setup options.

Making the interface configurable is not too difficult. Here[1] is an 
example that replicates the main functionality of the gnuplot module (a 
separate inclusions environment and named figures, using the pdf 
terminal). I will also look at the functionality of the lilypond module in 
detail and see if I can replicate all features.

[1]: https://github.com/adityam/filter/blob/dev/tests/gnuplot.tex

Aditya
___________________________________________________________________________________
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  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________