Unexpected behaviour with gnuplot source blocks

Unexpected behaviour with gnuplot source blocks

[Christopher Witte]

[-- Attachment #1: Type: text/plain, Size: 983 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1251 bytes --]

Re: Unexpected behaviour with gnuplot source blocks

[Eric Schulte]

Christopher Witte <chris@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

Re: Unexpected behaviour with gnuplot source blocks

[Christopher Witte]

[-- Attachment #1: Type: text/plain, Size: 695 bytes --]

On 20 June 2013 18:12, Eric Schulte <schulte.eric@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.

[-- Attachment #2: Type: text/html, Size: 1240 bytes --]

Re: Unexpected behaviour with gnuplot source blocks

[Eric Schulte]

Christopher Witte <chris@witte.net.au> writes:

> On 20 June 2013 18:12, Eric Schulte <schulte.eric@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".
>

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"))))

If anyone knows of other good default mapping to add please let me know.

>
> The following works
>
> #+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.

Thanks for the feedback.

> 
>   set terminal postscript eps
>   .....
> #+END_SRC
>
> Thanks for the help!
> Chris.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: Unexpected behaviour with gnuplot source blocks

[Suvayu Ali]

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!

> If anyone knows of other good default mapping to add please let me know.
> 

I personally use "pdfcairo color" for pdf output.

-- 
Suvayu

Open source is the future. It sets us free.

Re: Unexpected behaviour with gnuplot source blocks

[Eric Schulte]

Suvayu Ali <fatkasuvayu+linux@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: Unexpected behaviour with gnuplot source blocks

[Suvayu Ali]

On Fri, Jun 21, 2013 at 10:07:39AM -0600, Eric Schulte wrote:
> Suvayu Ali <fatkasuvayu+linux@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: Unexpected behaviour with gnuplot source blocks

[Achim Gratz]

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: Unexpected behaviour with gnuplot source blocks

[Eric Schulte]

Achim Gratz <Stromeko@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