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
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
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
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 -----------------------------------------------------------------
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
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 -----------------------------------------------------------------
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.
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.)
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
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 -----------------------------------------------------------------
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
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
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)
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
participants (5)
-
Aditya Mahajan -
Hans Hagen -
Henning Hraban Ramm -
Mojca Miklavec -
Wolfgang Schuster