1

Hitting ctrl-c ctrl-c on the gnuplot code block returns: org-babel-ref-resolve: Reference ‘foo’ not found in this buffer

#+srcname: foo
#+begin_src python :results output raw :exports code
  import random
  out="| %s | %s |"
  for x in range(0, 10):
          pair=(random.randrange(1000), random.randrange(1000))
          print(out % pair)
#+end_src

#+RESULTS: foo
| 232 | 867 |
| 196 | 951 |
| 489 |  94 |
|   0 | 327 |
| 369 | 758 |
| 178 | 854 |
|  80 |  71 |
| 859 | 174 |
| 760 | 181 |
| 461 |  22 |

#+begin_src gnuplot :var data=foo :file gnuplot.png :exports results
  reset
  set terminal png size 500,375
  plot data u 1:2 notitle
#+end_src

Someone else seems to have no problem with the upper code example 1


Remark

Following @Tobias' answer below, I got rid of the reference issue. Though instead of a plot, I have this gnuplot message below. Interestingly, the +#RESULTS foo values don't match those in the message buffer:

Terminal type is now 'qt'
gnuplot> cd '/home/ra/'
gnuplot> data = "| 138 | 87 |
gnuplot> | 372 | 843 |
         ^
         invalid command

gnuplot> | 297 | 799 |
         ^
         invalid command
...
..
.

Footnotes

1 https://stackoverflow.com/a/9462567/1172907

  • So we had not been done yet. You should have commented my solution. I almost missed your edit. I expanded my answer and posted my modified example. With that modified version you really get a plot. – Tobias Mar 30 at 23:18
  • The comment's function mini-Markdown doesn't allow code indentation, thus I had to edit my original post in order to depict the gnuplot error message appropriately. However, thank you for your elaborations and solution. – AikenCura Mar 31 at 7:01
2

There are 2 Problems in your code.

  • 1st: Replace the obsolete srcname with name. (Some more background is given below.)

  • 2nd: Do not refer to the raw result data of the python block as gnuplot block header argument but to the table. You do that by inserting the line #+NAME: foo-table before #+RESULTS: foo and by changing the value for the input variable data of the gnuplot block from foo to foo-table.

  • Note referring to the resulting table and not to the result directly has a disadvantage. The Python block is not evaluated if you call the Gnuplot block. If you introduce an additional dummy argument to the Gnuplot block that refers to the result of the Python block the Python block is called but the table is not updated. So you have to evaluate all source blocks to get the updated result for the Gnuplot block.

Alternative for 2nd:

  • 2nd: Change your Python block such that it does return really a table and not a string. (See the doc of Python blocks at orgmode.org.) This variant does not have the update problems. The Python block is updated whenever the Gnuplot block is called and its actual results are used for the Gnuplot block.

Then your Org-file works with Org-Mode 9.1.6.

The modified Orgmode source for the first variant of 2nd is:

#+name: foo
#+begin_src python :results output raw :exports code
import random
out="| %s | %s |"
for x in range(0, 10):
    pair=(random.randrange(1000), random.randrange(1000))
    print(out % pair)
#+end_src

#+NAME: foo-table
#+RESULTS: foo
| 883 |  73 |
| 500 | 754 |
| 949 | 961 |
| 376 | 420 |
| 823 | 110 |
| 836 |  84 |
| 438 | 808 |
| 560 | 413 |
| 300 | 995 |
| 527 |  64 |

#+begin_src gnuplot :var data=foo-table :file gnuplot.png :exports results
  reset
  set terminal png size 500,375
  # plot sin(x)
  plot data u 1:2 notitle
#+end_src

#+RESULTS:
[[file:gnuplot.png]]

The Orgmode source for the second variant of 2nd is:

#+name: foo
#+begin_src python :results value :exports code
import random
v = [ 0 for i in range(0,10) ]
for i in range(0, 10):
    pair=(random.randrange(1000), random.randrange(1000))
    v[i] = pair
return(v)
#+end_src

#+RESULTS: foo
| 408 | 621 |
| 623 | 935 |
| 638 | 490 |
| 909 | 155 |
| 793 | 601 |
| 663 | 277 |
| 404 | 515 |
| 466 |  12 |
| 696 | 234 |
| 197 | 285 |

#+begin_src gnuplot :var data=foo :file gnuplot.png :exports results
  reset
  set terminal png size 500,375
  # plot sin(x)
  plot data u 1:2 notitle
#+end_src

#+RESULTS:
[[file:gnuplot.png]]

Background for replacing srcname with name

I never noted srcname up to now. But srcname is the old obsolete version of name.

Note that the post you referred to is from 2012 and therefore already 7 years old.

The following note of incompatible changes in the release notes of Orgmode 7.8:

Incompatible changes

Standardized code block keywords

Following a round of on-list discussion, many code block synonyms have been removed. You can safely move forward the following syntax:

  • call lines are specified with #+call:

  • code blocks are named with #+name:

  • results are named with #+name:, however results generated by a code block may still be labeled with #+results:, and tables named with #+tblname: will be considered to be named results

The following function may be used to update an existing Org mode buffer to the new syntax:

(defun update-org-buffer ()
  "Update an Org mode buffer to the new data, code block and call line syntax."
  (interactive)
  (save-excursion
    (flet ((to-re (lst) (concat "^[ \t]*#\\+" (regexp-opt lst t)
                                "\\(\\[\\([[:alnum:]]+\\)\\]\\)?\\:[ \t]*"))
           (update (re new)
                   (goto-char (point-min))
                   (while (re-search-forward re nil t)
                     (replace-match new nil nil nil 1))))
      (let ((old-re (to-re '("RESULTS" "DATA" "SRCNAME" "SOURCE")))
            (lob-re (to-re '("LOB")))
            (case-fold-search t))
        (update old-re "name")
        (update lob-re "call")))))

Difference between raw and interpreted source block output

The difference between raw and interpreted output of source blocks becomes clear with the following org source.

The first Elisp source block with name bar returns just a string that is formatted like a table.

The results of that table can be referenced by the block name bar. But when the result is inserted into the org buffer it is formatted like an Org-table. We name that table with #+NAME: bar-table. The second source block takes the raw result bar of the first block as first input argument and the interpreted table data bar-table as second. The second source block just formats its two input arguments as it reads them and returns the resulting string. As one sees the raw bar result is just a string while the interpreted bar-table result is a list of numbers.

#+NAME: bar
#+BEGIN_SRC emacs-lisp :results raw
"| 11 | 12 |"
#+END_SRC

#+NAME: bar-table
#+RESULTS: bar
| 11 | 12 |
| 21 | 22 |

#+BEGIN_SRC emacs-lisp :var first=bar :var second=bar-table :results drawer
(format "%S %S" first second)
#+END_SRC

#+RESULTS:
:RESULTS:
"| 11 | 12 |" ((11 12) (21 22))
:END:

What does that mean for your original problem?

The python source block returns the formatted table as a string that contains the Org-table with the calculated data. But the gnuplot source block expects the table data as list of table rows which are lists of numeric entries in turn. If that format of the input data is detected it writes it out into a temporary file and sets the value of the user-defined Gnuplot variable data to the name of that file.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.