• State "DONE" from "TODO" 2010-03-02 Tue 14:53
• State "TODO" from "" 2010-02-21 Sun 16:53

At line 217 of org-babel.el, we rebind call-process-region so that a handler from tramp is used:

(let (
      ...
      (call-process-region-original (symbol-function 'call-process-region))
      result)
  ;; (message "params=%S" params) ;; debugging
  (flet ((call-process-region (&rest args)
                              (apply 'org-babel-tramp-handle-call-process-region args)))
    ;; ...
    ))

Currently, there is a bug in that if we try to run the tests, a number of them fail. Furthermore, afterwards, it seems that

(symbol-function 'call-process-region))

returns the rebound definition made in the flet, rather than the original definition, despite the fact that the flet has terminated.

This all needs to be fixed.

• State "TODO" from "" 2010-02-21 Sun 17:02 See reply from Michael Albinus

As an example from several such instances, consider this in ob-ruby.el:

(case result-type
  (output (org-babel-eval org-babel-ruby-command body))
  (value (let ((tmp-file (make-temp-file "org-babel-ruby-results-")))
           (org-babel-eval org-babel-ruby-command
                           (format (if (member "pp" result-params)
                                       org-babel-ruby-pp-wrapper-method
                                     org-babel-ruby-wrapper-method)
                                   body tmp-file))
           ((lambda (raw)
              (if (or (member "code" result-params)
                      (member "pp" result-params))
                  raw
                (org-babel-ruby-table-or-string raw)))
            (org-babel-eval-read-file tmp-file)))))

The prefix passed to make-temp-file is relative; if default-directory happens to be remote, then make-temp-file guarantees that the file name returned does not already exists on the local host, whereas what is wanted is a guarantee that it does not exist on thr remote host. It seems from Michael Albinu's reply below that we should in that case be passing a prefix using remote syntax, expanded against the value of temporary-file-directory appropriate for the remote host.

• State "TODO" from "" 2010-02-21 Sun 16:52

We need to extend some of the changes to some of the other languages, e.g. make sure that they construct remote file names when attemtping to read remote data, as in 010cd73feb4a1dcb2da6f9a7352a35cfb4dac00e.

• State "STARTED" from "TODO" 2010-03-03 Wed 14:37
• State "TODO" from "" 2010-02-25 Thu 18:16

E.g. if I use :file pca.png, but the working directory of the R session is "/tmp", then we need to ensure that the org file link points to the location of the file created by R.

I.e. should we create a file in /tmp or in the current directory?

• State "DONE" from "TODO" 2010-02-21 Sun 00:48
• State "TODO" from "" 2010-02-16 Tue 13:59

• State "DONE" from "TODO" 2010-02-21 Sun 00:49

• State "TODO" from "PROPOSED" 2010-02-11 Thu 14:40

A remote session can be started using tramp (the way I do it at the moment is to visit a remote file and then issue e.g. M-x R. It will run on the remote machine) or M-x ssh. This will work with :results output. However :results value currently (in the target language) writes the data to a file on the remote machine and then (in elisp) attempts to retrieve it from the local machine. Thus the necessary network data transmission is not currently attempted. Perhaps tramp can be used to achieve this?

Hmm, If there is some programmatic way to detect that the current buffer is visiting a remote machine, then it should be easy to change the code which is writing and reading to temporary files to explicitly do all such operations on the local host. [Eric]

I'm not quite clear on this. With ":results value" in (say) R, the R process has to write the return data to file. If the R process is running remotely then someone (R?, emacs?, shell?) has to transfer the data between machines. If this is to be robust across languages, then we probably want to allow the langauge processes to continue to write locally as they do currently (because the ability of languages to deal with the network transfer will vary), and therefore we would require a new data transfer stage (implemented perhaps in emacs or by standard shell utilities) in order for the data to be read into org-babel [Dan]

I currently don't ever really run anything on a remote machine, but if someone else got this going I'd be happy to help iron out the details. [Eric]

For the record, my situation is the opposite – all the data is stored remotely (and the remote machines have more appropriate computing power than my netbook), but I don't really want to run emacs over ssh, for a variety of reasons (performance, code libraries) – so having org-babel execute remotely is very desirable for me. Having said that, ':session :results output' is working quite adequately; I've only occasionally felt the need for ':results value'. [Dan]

• State "DONE" from "TODO" 2010-02-21 Sun 00:50
• State "TODO" from "" 2010-02-11 Thu 14:49

We need:

• A way to specify the machine on which a remote process should be run (and to retrieve stdout/stderr)
• A way of retrieving file contents in the case of :results value.

The second of the above should be handled by the remote-results-value case above. As for telling org-babel to start the process on a remote machine, it's not immediately clear to me how that would work.

The first thing that occurs to me is that maybe if we accept a path so that a buffer on the remote machine can be opened using tramp then we can switch to that buffer and remote execution will happen naturally in a language-agnostic way. This is a slight automation of the process described above. So something like

#+begin_src clojure :host my-other-machine:~/some-file
  (println (System/getProperties))
#+end_src

would result in Org-babel first opening a buffer with the value of :host and then running through the same execution pattern as above.