Bug: Can't execute C code block from remote directory [9.0.5 (release_9.0.5-401-g86ff11 @ /Users/xcy/src/org-mode/lisp/)]

Bug: Can't execute C code block from remote directory [9.0.5 (release_9.0.5-401-g86ff11 @ /Users/xcy/src/org-mode/lisp/)]

[Chunyang Xu]

Hi.

My computer is running Mac OS, I would like to run some C code from my
VPS which is running GNU/Linux Ubuntu. For example,

#+BEGIN_SRC C :dir /ssh:xuchunyang.me:
puts("Hello, World!");
#+END_SRC

but when I execute this code block with C-c C-c, it popups *Org-Babel
Error Output* and here is its contents

/bin/sh: 1: /ssh:xuchunyang.me:/tmp/C-bin-18285iKe: not found

However, the file does exist and produce the desired output

#+BEGIN_SRC sh :dir /ssh:xuchunyang.me:
/tmp/C-bin-18285U4c
#+END_SRC

#+RESULTS:
| Hello | World! |


--
Emacs  : GNU Emacs 26.0.50 (build 10, x86_64-apple-darwin16.4.0, NS appkit-1504.81 Version 10.12.3 (Build 16D32))
 of 2017-03-28
Package: Org mode version 9.0.5 (release_9.0.5-401-g86ff11 @ /Users/xcy/src/org-mode/lisp/)

Scatter-gather idea

[Bob Newell]

Org-mode has nearly everything that other outlining tools have, and
generally much, much more. But one thing that is missing (and
there's been sporadic traffic about this) is convenient
scatter-gather. BrainStorm WFO has this; it's not like I'm going to
start using it as an alternative, but such a feature might be nice in
org-mode.

The Emacs way is to write it yourself, and I'm thinking about that. But
I wanted to try out the concept and see if it's of interest, or for that
matter, more trouble than it's worth.

You can do something like this on the Agenda screen, but that's not a
general solution at all. What about an "ordinary" org mode file. So
here's the flow I envision.

1. You "mark" a series of headline entries with, say,
   'org-sg-mark'. Perhaps it would look like this when marked:
   
   ** ! interesting headline

   Yes, this disturbs the existing text. But the marking has to be
   somehow visual.

2. You give a command like 'org-sg-gather' and the marked headlines are
   gathered up, moved (just like archiving) to a file (for which you're
   prompted) or maybe, optionally to the top or bottom of the current
   buffer. The marks are then cleared.

3. 'org-sg-clear' clears a single mark; 'org-sg-clear-all' clears them all.

Potential problems:

1. As mentioned, text is disturbed at least temporarily.

2. Incomplete operation sequences leave marks in place, when they might
   be useless.

3. If the gathered headlines are at different levels, the resulting
   gathered outline will not be sensible and will require manual fixing.

Comments welcome. This doesn't look especially difficult to code, but
does it make sense and is it of any use?

-- 
Bob Newell
Honolulu, Hawai`i
* Via Gnus/BBDB/Org/Emacs/Linux *

Re: Scatter-gather idea

[John Kitchin]

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

You don't need those temporary marks I think. Just store the positions in a
variable or use overlays or text properties. You could even make a speed
key to run the mark command.

It could be implemented from a helm command pretty easily too. You can
easily make multiple selections with helm.

Point 3 is a tough one. You might provide a numeric prefix arg that makes
all levels the same. That may be easier to manually adjust.


On Sat, Apr 1, 2017 at 1:28 PM Bob Newell <bobnewell@bobnewell.net> wrote:

> Org-mode has nearly everything that other outlining tools have, and
> generally much, much more. But one thing that is missing (and
> there's been sporadic traffic about this) is convenient
> scatter-gather. BrainStorm WFO has this; it's not like I'm going to
> start using it as an alternative, but such a feature might be nice in
> org-mode.
>
> The Emacs way is to write it yourself, and I'm thinking about that. But
> I wanted to try out the concept and see if it's of interest, or for that
> matter, more trouble than it's worth.
>
> You can do something like this on the Agenda screen, but that's not a
> general solution at all. What about an "ordinary" org mode file. So
> here's the flow I envision.
>
> 1. You "mark" a series of headline entries with, say,
>    'org-sg-mark'. Perhaps it would look like this when marked:
>
>    ** ! interesting headline
>
>    Yes, this disturbs the existing text. But the marking has to be
>    somehow visual.
>
> 2. You give a command like 'org-sg-gather' and the marked headlines are
>    gathered up, moved (just like archiving) to a file (for which you're
>    prompted) or maybe, optionally to the top or bottom of the current
>    buffer. The marks are then cleared.
>
> 3. 'org-sg-clear' clears a single mark; 'org-sg-clear-all' clears them all.
>
> Potential problems:
>
> 1. As mentioned, text is disturbed at least temporarily.
>
> 2. Incomplete operation sequences leave marks in place, when they might
>    be useless.
>
> 3. If the gathered headlines are at different levels, the resulting
>    gathered outline will not be sensible and will require manual fixing.
>
> Comments welcome. This doesn't look especially difficult to code, but
> does it make sense and is it of any use?
>
> --
> Bob Newell
> Honolulu, Hawai`i
> * Via Gnus/BBDB/Org/Emacs/Linux *
>
> --
John

-----------------------------------
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

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

Re: Scatter-gather idea

[Bob Newell]

Thanks for the feedback. As to the question, what is scatter-gather? --
It's the idea of gathering up scattered pieces of text and consolidating
them in another place, whether elsewhere in the same buffer or
in another file.

Using tags would work, and I've done something similar in my home-brew
code for a fiction writing environment (I gather scattered comment
blocks). So would non-visible marks, although when brainstorming you may
want visible indicators of selected headlines.

Something like '** ! headine' doesn't really destroy org syntax in any
way, but it does add extra text to a headline (of course, so does a
tag). I'll certainly look at the suggested alternatives, especially helm.

In any case I'll think this through quite a bit more before developing a
prototype. 

-- 
Bob Newell
Honolulu, Hawai`i
* Via Gnus/BBDB/Org/Emacs/Linux *

Re: Scatter-gather idea

[Samuel Wales]

can you provide a use case?

for me, i have long wanted to mark a set of tasks with a tag in the
outline or agenda, then have /links/ to them gathered in one place, at
a uniform level.

that is probably less ambitious than your plan.

-- 
The Kafka Pandemic: <http://thekafkapandemic.blogspot.com>

The disease DOES progress. MANY people have died from it. And ANYBODY
can get it at any time.

"You’ve really gotta quit this and get moving, because this is murder
by neglect." ---
<http://www.meaction.net/2017/02/03/pwme-people-with-me-are-being-murdered-by-neglect>.

Re: Scatter-gather idea

[Bob Newell]

Samuel Wales <samologist@gmail.com> writes:

> can you provide a use case?

A simple use case: you're brainstorming, making org-mode headline
entries as fast as you can think or type. After a while you notice that
a number of entries seem to be related and might actually be better
considered as a spin-off. So you want to gather up all of those entries
and send them off in bulk to a different org file.

Or even simpler: you want to group together a bunch of scattered
headlines that you now see as being related. Yes, you can do this by
moving each one around individually, but I'd like a faster method---
just mark them and relocate them all at once to the top or bottom of the
buffer.

> for me, i have long wanted to mark a set of tasks with a tag in the
> outline or agenda, then have /links/ to them gathered in one place, at
> a uniform level.

This sounds quite useful, actually.

-- 
Bob Newell
Honolulu, Hawai`i
* Via Gnus/BBDB/Org/Emacs/Linux *

Re: Scatter-gather idea

[Yasushi SHOJI]

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

Hi Bob,

On Mon, Apr 3, 2017 at 1:34 PM, Bob Newell <bobnewell@bobnewell.net> wrote:
>
> A simple use case: you're brainstorming, making org-mode headline
> entries as fast as you can think or type. After a while you notice that
> a number of entries seem to be related and might actually be better
> considered as a spin-off. So you want to gather up all of those entries
> and send them off in bulk to a different org file.

mark them with tags, and do org-tags-view.  Or, you can use regex or other
criteria if you like.

If you want to refile them to a org file, mark entries you want to refile
with
org-agenda-bulk-mark and do org-agenda-bulk-action and 'r' to select
a file.

http://orgmode.org/manual/Agenda-commands.html#Agenda-commands
--
           yashi

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

Re: Scatter-gather idea

[Nick Dokos]

Yasushi SHOJI <yasushi.shoji@gmail.com> writes:

> Hi Bob,
>
> On Mon, Apr 3, 2017 at 1:34 PM, Bob Newell <bobnewell@bobnewell.net> wrote:
>>
>> A simple use case: you're brainstorming, making org-mode headline
>> entries as fast as you can think or type. After a while you notice that
>> a number of entries seem to be related and might actually be better
>> considered as a spin-off. So you want to gather up all of those entries
>> and send them off in bulk to a different org file.
>
> mark them with tags, and do org-tags-view.  Or, you can use regex or other
> criteria if you like.
>

That was my first thought too: I didn't think any extra functionality is needed.

> If you want to refile them to a org file, mark entries you want to refile with
> org-agenda-bulk-mark and do org-agenda-bulk-action and 'r' to select
> a file.
>
> http://orgmode.org/manual/Agenda-commands.html#Agenda-commands
> --
>            yashi
>

-- 
Nick

Re: Scatter-gather idea

[Bob Newell]

>> mark them with tags, and do org-tags-view.  Or, you can use regex or other
>> criteria if you like.
>>
>
> That was my first thought too: I didn't think any extra functionality is needed.

I looked into this earlier but agenda bulk marking doesn't seem to work
in an arbitrary org-mode buffer; it must be an agenda buffer, and you
can only mark certain entries.

The tag idea may be the best way. Thanks to all for the replies.

-- 
Bob Newell
Honolulu, Hawai`i
* Via Gnus/BBDB/Org/Emacs/Linux *

Re: Scatter-gather idea

[Nick Dokos]

Bob Newell <bobnewell@bobnewell.net> writes:

>>> mark them with tags, and do org-tags-view.  Or, you can use regex or other
>>> criteria if you like.
>>>
>>
>> That was my first thought too: I didn't think any extra functionality is needed.
>
> I looked into this earlier but agenda bulk marking doesn't seem to work
> in an arbitrary org-mode buffer; it must be an agenda buffer, and you
> can only mark certain entries.
>
> The tag idea may be the best way. Thanks to all for the replies.

Yes, sorry: I was talking about tags, not about agenda bulk-marking. Although you
can add an arbitrary org file to the agend with `C-c [', do what you need to do,
and then remove it with `C-c ]'.
-- 
Nick

Re: Scatter-gather idea

[John Kitchin]

I am sympathetic to not wanting to use tags here. It would be tedious to
tag them all, and then remove them (my opinion of course;). Here is some
code that you can "mark" headlines with a speed command (M on a headline
start) or interactively. This just stores a marker to the headline in a
global variable. Then, use M-x scatter-gather to put them all into one
temporary buffer. From there you can manipulate them any way you want,
and save the result anyway you want. You could modify scatter-gather to
either copy or move the headlines.

You could also use overlays to indicate a headline had been marked, and
make some convenience functions to remove headlines from the list, but I
leave those for exercises ;)

This code is lightly tested.

#+BEGIN_SRC emacs-lisp
(defvar scatter-gather-markers '()
  "List of markers where headlines are for gathering.")

(defun scatter-gather-mark-heading ()
  "Add the current headline to `scatter-gather-markers'."
  (interactive)
  (unless (org-at-heading-p)
    (outline-previous-heading))
  (add-to-list 'scatter-gather-markers (point-marker)))


(defun scatter-gather ()
  "Gather marked headlines into a temporary buffer"
  (interactive)
  (when scatter-gather-markers
    (switch-to-buffer-other-window (get-buffer-create "*scatter-gather*"))
    (loop for marker in (reverse scatter-gather-markers)
	  do
	  (insert (with-current-buffer (marker-buffer marker)
		    (save-excursion
		      (goto-char (marker-position marker))
		      (org-mark-subtree)
		      (buffer-substring (point) (mark))))))
    (setq scatter-gather-markers '())))

(add-to-list 'org-speed-commands-user (cons "M" 'scatter-gather-mark-heading))
#+END_SRC


Nick Dokos writes:

> Bob Newell <bobnewell@bobnewell.net> writes:
>
>>>> mark them with tags, and do org-tags-view. Or, you can use regex or other
>>>> criteria if you like.
>>>>
>>>
>>> That was my first thought too: I didn't think any extra functionality is needed.
>>
>> I looked into this earlier but agenda bulk marking doesn't seem to work
>> in an arbitrary org-mode buffer; it must be an agenda buffer, and you
>> can only mark certain entries.
>>
>> The tag idea may be the best way. Thanks to all for the replies.
>
> Yes, sorry: I was talking about tags, not about agenda bulk-marking. Although you
> can add an arbitrary org file to the agend with `C-c [', do what you need to do,
> and then remove it with `C-c ]'.


--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: Scatter-gather idea

[Daniel Clemente]

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

On Mon, Apr 3, 2017 at 6:34 AM, Bob Newell <bobnewell@bobnewell.net> wrote:

>
> Or even simpler: you want to group together a bunch of scattered
> headlines that you now see as being related. Yes, you can do this by
> moving each one around individually, but I'd like a faster method---
> just mark them and relocate them all at once to the top or bottom of the
> buffer.
>

 If you need it fast and simple, and you're in an agenda view, you can use
M-up, M-down to reorder the headlines you see, and this doesn't modify
anything else, just the visual order in this agenda. Then when all the
tasks you want are at the top, you can copy/paste them, or mark them and
move them, etc.

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

Re: Scatter-gather idea

[Bingo]

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

On April 1, 2017 10:57:41 PM GMT+05:30, Bob Newell <bobnewell@bobnewell.net> wrote:
>Org-mode has nearly everything that other outlining tools have, and
>generally much, much more. But one thing that is missing (and
>there's been sporadic traffic about this) is convenient
>scatter-gather. BrainStorm WFO has this; it's not like I'm going to
>start using it as an alternative, but such a feature might be nice in
>org-mode.
>
>The Emacs way is to write it yourself, and I'm thinking about that. But
>I wanted to try out the concept and see if it's of interest, or for
>that
>matter, more trouble than it's worth.
>
>You can do something like this on the Agenda screen, but that's not a
>general solution at all. What about an "ordinary" org mode file. So
>here's the flow I envision.
>
>1. You "mark" a series of headline entries with, say,
>   'org-sg-mark'. Perhaps it would look like this when marked:
>   
>   ** ! interesting headline
>
>   Yes, this disturbs the existing text. But the marking has to be
>   somehow visual.
>
>2. You give a command like 'org-sg-gather' and the marked headlines are
>   gathered up, moved (just like archiving) to a file (for which you're
>   prompted) or maybe, optionally to the top or bottom of the current
>   buffer. The marks are then cleared.
>
>3. 'org-sg-clear' clears a single mark; 'org-sg-clear-all' clears them
>all.
>
>Potential problems:
>
>1. As mentioned, text is disturbed at least temporarily.
>
>2. Incomplete operation sequences leave marks in place, when they might
>   be useless.
>
>3. If the gathered headlines are at different levels, the resulting
>  gathered outline will not be sensible and will require manual fixing.
>
>Comments welcome. This doesn't look especially difficult to code, but
>does it make sense and is it of any use?
>
>-- 
>Bob Newell
>Honolulu, Hawai`i
>* Via Gnus/BBDB/Org/Emacs/Linux *

What is scatter-gather ? What is the purpose for which it is done? Google tells me about a vectored I/O method, which is not what i guess you are talking about.

That would help clarify why you chose an org-syntax demolishing "!"  instead of a tag.

For myself i have coded a dirty elisp to extract and randomly order some specific marked headlines. But for this, tags work better because i don't want to mark all my headlines (hundreds) every time i dump this out.


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

Re: Bug: Can't execute C code block from remote directory [9.0.5 (release_9.0.5-401-g86ff11 @ /Users/xcy/src/org-mode/lisp/)]

[Chunyang Xu]

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


Here is a patch which can fix the issue.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-ob-C-Fix-remote-executing.patch --]
[-- Type: text/x-patch, Size: 799 bytes --]

From e42b22f74c2f04a4d8e7eec0a6bdacbd08bebf12 Mon Sep 17 00:00:00 2001
From: Chunyang Xu <mail@xuchunyang.me>
Date: Mon, 3 Apr 2017 14:46:51 +0800
Subject: [PATCH] ob-C: Fix remote executing

* lisp/ob-C.el (org-babel-C-execute): Process remote bin file.

TINYCHANGE
---
 lisp/ob-C.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/ob-C.el b/lisp/ob-C.el
index 795bcb2b7..e54e17492 100644
--- a/lisp/ob-C.el
+++ b/lisp/ob-C.el
@@ -161,7 +161,7 @@ or `org-babel-execute:C++' or `org-babel-execute:D'."
 	   (org-babel-eval
 	    (pcase org-babel-c-variant
 	      ((or `c `cpp)
-	       (concat tmp-bin-file cmdline))
+	       (concat (org-babel-process-file-name tmp-bin-file) cmdline))
 	      (`d
 	       (format "%s %s %s %s"
 		       org-babel-D-compiler
-- 
2.12.0


[-- Attachment #3: Type: text/plain, Size: 597 bytes --]


Chunyang Xu writes:

> Hi.
>
> My computer is running Mac OS, I would like to run some C code from my
> VPS which is running GNU/Linux Ubuntu. For example,
>
> #+BEGIN_SRC C :dir /ssh:xuchunyang.me:
> puts("Hello, World!");
> #+END_SRC
>
> but when I execute this code block with C-c C-c, it popups *Org-Babel
> Error Output* and here is its contents
>
> /bin/sh: 1: /ssh:xuchunyang.me:/tmp/C-bin-18285iKe: not found
>
> However, the file does exist and produce the desired output
>
> #+BEGIN_SRC sh :dir /ssh:xuchunyang.me:
> /tmp/C-bin-18285U4c
> #+END_SRC
>
> #+RESULTS:
> | Hello | World! |

Re: Bug: Can't execute C code block from remote directory [9.0.5 (release_9.0.5-401-g86ff11 @ /Users/xcy/src/org-mode/lisp/)]

[Nicolas Goaziou]

Hello,

Chunyang Xu <mail@xuchunyang.me> writes:

> Here is a patch which can fix the issue.

Thank you.

> From e42b22f74c2f04a4d8e7eec0a6bdacbd08bebf12 Mon Sep 17 00:00:00 2001
> From: Chunyang Xu <mail@xuchunyang.me>
> Date: Mon, 3 Apr 2017 14:46:51 +0800
> Subject: [PATCH] ob-C: Fix remote executing
>
> * lisp/ob-C.el (org-babel-C-execute): Process remote bin file.
>
> TINYCHANGE
> ---
>  lisp/ob-C.el | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lisp/ob-C.el b/lisp/ob-C.el
> index 795bcb2b7..e54e17492 100644
> --- a/lisp/ob-C.el
> +++ b/lisp/ob-C.el
> @@ -161,7 +161,7 @@ or `org-babel-execute:C++' or `org-babel-execute:D'."
>  	   (org-babel-eval
>  	    (pcase org-babel-c-variant
>  	      ((or `c `cpp)
> -	       (concat tmp-bin-file cmdline))
> +	       (concat (org-babel-process-file-name tmp-bin-file) cmdline))

I see that `tmp-bin-file' is used a couple other times in the body.
Would it make sense to wrap the initial binding within
`org-babel-process-file-name' instead of doing it only for this
occurrence?

Regards,

-- 
Nicolas Goaziou

Re: Bug: Can't execute C code block from remote directory [9.0.5 (release_9.0.5-401-g86ff11 @ /Users/xcy/src/org-mode/lisp/)]

[Chunyang Xu]

Nicolas Goaziou writes:

> Hello,
>
> Chunyang Xu <mail@xuchunyang.me> writes:
>
>> Here is a patch which can fix the issue.
>
> Thank you.
>
>> From e42b22f74c2f04a4d8e7eec0a6bdacbd08bebf12 Mon Sep 17 00:00:00 2001
>> From: Chunyang Xu <mail@xuchunyang.me>
>> Date: Mon, 3 Apr 2017 14:46:51 +0800
>> Subject: [PATCH] ob-C: Fix remote executing
>>
>> * lisp/ob-C.el (org-babel-C-execute): Process remote bin file.
>>
>> TINYCHANGE
>> ---
>>  lisp/ob-C.el | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/lisp/ob-C.el b/lisp/ob-C.el
>> index 795bcb2b7..e54e17492 100644
>> --- a/lisp/ob-C.el
>> +++ b/lisp/ob-C.el
>> @@ -161,7 +161,7 @@ or `org-babel-execute:C++' or `org-babel-execute:D'."
>>  	   (org-babel-eval
>>  	    (pcase org-babel-c-variant
>>  	      ((or `c `cpp)
>> -	       (concat tmp-bin-file cmdline))
>> +	       (concat (org-babel-process-file-name tmp-bin-file) cmdline))
>
> I see that `tmp-bin-file' is used a couple other times in the body.
> Would it make sense to wrap the initial binding within
> `org-babel-process-file-name' instead of doing it only for this
> occurrence?

Both ways look OK to me. `tmp-bin-file' is used only twice and invoking
`org-babel-process-file-name' is cheap. And converting `tmp-bin-file'
from remote to local name only when 100% necessary (i.e. within
`org-babel-eval') looks more logical to me. On the other hand,
`tmp-bin-file' as a remote file name is useless, thus the way you
suggested is reasonable as well.

> Regards,

Re: Bug: Can't execute C code block from remote directory [9.0.5 (release_9.0.5-401-g86ff11 @ /Users/xcy/src/org-mode/lisp/)]

[Nicolas Goaziou]

Hello,

Chunyang Xu <mail@xuchunyang.me> writes:

> Nicolas Goaziou writes:
>
>> Hello,
>>
>> Chunyang Xu <mail@xuchunyang.me> writes:
>>
>>> Here is a patch which can fix the issue.
>>
>> Thank you.
>>
>>> From e42b22f74c2f04a4d8e7eec0a6bdacbd08bebf12 Mon Sep 17 00:00:00 2001
>>> From: Chunyang Xu <mail@xuchunyang.me>
>>> Date: Mon, 3 Apr 2017 14:46:51 +0800
>>> Subject: [PATCH] ob-C: Fix remote executing
>>>
>>> * lisp/ob-C.el (org-babel-C-execute): Process remote bin file.
>>>
>>> TINYCHANGE
>>> ---
>>>  lisp/ob-C.el | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/lisp/ob-C.el b/lisp/ob-C.el
>>> index 795bcb2b7..e54e17492 100644
>>> --- a/lisp/ob-C.el
>>> +++ b/lisp/ob-C.el
>>> @@ -161,7 +161,7 @@ or `org-babel-execute:C++' or `org-babel-execute:D'."
>>>  	   (org-babel-eval
>>>  	    (pcase org-babel-c-variant
>>>  	      ((or `c `cpp)
>>> -	       (concat tmp-bin-file cmdline))
>>> +	       (concat (org-babel-process-file-name tmp-bin-file) cmdline))
>>
>> I see that `tmp-bin-file' is used a couple other times in the body.
>> Would it make sense to wrap the initial binding within
>> `org-babel-process-file-name' instead of doing it only for this
>> occurrence?
>
> Both ways look OK to me. `tmp-bin-file' is used only twice and invoking
> `org-babel-process-file-name' is cheap. And converting `tmp-bin-file'
> from remote to local name only when 100% necessary (i.e. within
> `org-babel-eval') looks more logical to me. On the other hand,
> `tmp-bin-file' as a remote file name is useless, thus the way you
> suggested is reasonable as well.

OK. Would you mind sending a patch doing the latter, along with a code
comment explaining why `org-babel-process-file-name' is needed?

Regards,

-- 
Nicolas Goaziou