Re: [O] Unexpected behaviour with gnuplot source blocks
Eric Schulte writes: #+BEGIN_SRC gnuplot :file test.eps reset ^ WRT |, I've also added the *org-babel-gnuplot-prefix* variable, which may be set to e.g., reset to reset the gnuplot process between code blocks. We have recently introduced similar functionality in ob-perl and it probably deserves a more general treatment and easier customization. Doing these things with defcustoms or defvars should be shunned, since it makes Org files using these options inherently unportable and non-self-contained. For the functionality that is implemented here, I'd think two new general header arguments are appropriate, namely :prolog and :epilog, which should take the name of a source block (same language), a literal string in quotes, the result of an inline call of another source block and inline elisp (the result of execution must be in the appropriate syntax) as an argument. We might need some friendlier way than elisp if we want to use URL (esp. file:…) in the same capacity. For session execution there may be a need to distibguish between the session start, subsequent invocations and perhaps closing of the session (we don't have that at the moment, I think). Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] Unexpected behaviour with gnuplot source blocks
Achim Gratz strom...@nexgo.de writes: Eric Schulte writes: #+BEGIN_SRC gnuplot :file test.eps reset ^ WRT |, I've also added the *org-babel-gnuplot-prefix* variable, which may be set to e.g., reset to reset the gnuplot process between code blocks. We have recently introduced similar functionality in ob-perl and it probably deserves a more general treatment and easier customization. Doing these things with defcustoms or defvars should be shunned, since it makes Org files using these options inherently unportable and non-self-contained. Agreed. For the functionality that is implemented here, I'd think two new general header arguments are appropriate, namely :prolog and :epilog, I've added prologue and epilogue header arguments. They are implemented for gnuplot and any language which uses `org-babel-expand-body:generic'. The particular case of closing the gnuplot output terminal does not use the epilogue, but rather happens automatically only in those cases in which the output is explicitly set. which should take the name of a source block (same language), a literal string in quotes, the result of an inline call of another source block and inline elisp (the result of execution must be in the appropriate syntax) as an argument. We might need some friendlier way than elisp if we want to use URL (esp. file:…) in the same capacity. For session execution there may be a need to distibguish between the session start, subsequent invocations and perhaps closing of the session (we don't have that at the moment, I think). I think standard header arguments should suffice. Thanks, Regards, Achim. -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] Unexpected behaviour with gnuplot source blocks
On 20 June 2013 18:12, Eric Schulte schulte.e...@gmail.com wrote: Why not do the following instead which would be equivalent and simpler. The output will be automatically set from the value of your :file header argument. #+begin_src gnuplot :file fig/transInc.eps reset set encoding utf8 . #+end_src That kinda works, but I think you still need to set the terminal type within the source block. Using the above the command set terminal eps gets sent to gnuplot, but you actually need set terminal postscript eps. The following works #+BEGIN_SRC gnuplot :file test.eps reset set terminal postscript eps . #+END_SRC Thanks for the help! Chris.
Re: [O] Unexpected behaviour with gnuplot source blocks
Suvayu Ali fatkasuvayu+li...@gmail.com writes: On Fri, Jun 21, 2013 at 09:02:28AM -0600, Eric Schulte wrote: I've added a customization variable to ob-gnuplot which may be used to map file extensions to terminals. Currently it just holds the mapping from eps to postscript eps ;; -*- emacs-lisp -*- (defcustom *org-babel-gnuplot-terms* '((eps . postscript eps)) List of file extensions and the associated gnuplot terminal. :group 'org-babel :type '(repeat (cons (symbol :tag File extension) (string :tag Gnuplot terminal Great idea! Thanks, I hope it is useful. If anyone knows of other good default mapping to add please let me know. I personally use pdfcairo color for pdf output. This is already the default behavior for term pdf on my system, so I don't think we need to add it to the list. I did just add some logic to ensure that output terminals are closed at the end of code blocks, which was required for a simple pdf example to work for me. Cheers, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] Unexpected behaviour with gnuplot source blocks
On Fri, Jun 21, 2013 at 10:07:39AM -0600, Eric Schulte wrote: Suvayu Ali fatkasuvayu+li...@gmail.com writes: I personally use pdfcairo color for pdf output. This is already the default behavior for term pdf on my system, so I don't think we need to add it to the list. I did just add some logic to ensure that output terminals are closed at the end of code blocks, which was required for a simple pdf example to work for me. Closing the terminal is crucial indeed! I scratched my head quite a bit when I first started using pdf output. -- Suvayu Open source is the future. It sets us free.
Re: [O] Unexpected behaviour with gnuplot source blocks
Christopher Witte ch...@witte.net.au writes: Hi all, I had some wierd behaviour with gnuplot source blocks and I'm not sure of the best way to fix it. I have gnuplot source blocks that write output files that I insert into the document using links, as such: #+begin_src gnuplot :file transInc.eps reset set encoding utf8 set output ./fig/transInc.eps . #+end_src [[fig/transInc.eps]] Why not do the following instead which would be equivalent and simpler. The output will be automatically set from the value of your :file header argument. #+begin_src gnuplot :file fig/transInc.eps reset set encoding utf8 . #+end_src and I have two documents in different directories, say 'a' and 'b' that do this. If I go to the first document in folder 'a' and export it to latex and then go to the second document in folder 'b' and also export it to latex, all the generated plots end up in 'a'. It took me a while to work it out, but this is because only one gnuplot session is started and 'reset' doesn't reset output. Killing the gnuplot buffer fixes this, but that is annoying if I frequently switch back and forth between the documents. Does setting :session to none for gnuplot fix this problem? I could use full paths, but that seams like a pain, any other suggestions? Thanks for the help, Chris. -- Eric Schulte http://cs.unm.edu/~eschulte
[O] Unexpected behaviour with gnuplot source blocks
Hi all, I had some wierd behaviour with gnuplot source blocks and I'm not sure of the best way to fix it. I have gnuplot source blocks that write output files that I insert into the document using links, as such: #+begin_src gnuplot :file transInc.eps reset set encoding utf8 set output ./fig/transInc.eps . #+end_src [[fig/transInc.eps]] and I have two documents in different directories, say 'a' and 'b' that do this. If I go to the first document in folder 'a' and export it to latex and then go to the second document in folder 'b' and also export it to latex, all the generated plots end up in 'a'. It took me a while to work it out, but this is because only one gnuplot session is started and 'reset' doesn't reset output. Killing the gnuplot buffer fixes this, but that is annoying if I frequently switch back and forth between the documents. I could use full paths, but that seams like a pain, any other suggestions? Thanks for the help, Chris.
