Re: [O] Erroneous "No such file or directory" with babel and remote dir

[Nick Dokos]

Loris Bennett <address@hidden> wrote:

> Achim Gratz <address@hidden> writes:
> 
> > Loris Bennett writes:
> >> OK, I must have goofed.  What I did after starting the bisection was
> >>
> >> - run 'make autoload'
> >> - open test file in emacs with minimal .emacs
> >> - test
> >> - end emacs
> >> - mark bisection good or bad
> >>
> >> I then repeated this for the next commit.
> >
> > This would be the correct thing to do, yes.
> >
> >> Is something missing here, or did I just incorrectly mark a commit?
> >
> > I really don't know, I'm just guessing… :-)
> >
> > It may be more informative if you traced the invocation of the remote
> > execution in both a failing and a working version in the debugger and
> > look for any differences as the arguments are cobbled together.  Once
> > you find where an how these diverge it would be much easier to find the
> > code that is responsible for it (if it wasn't glaringly obvious from the
> > trace already).
> >
> >
> > Regards,
> > Achim.
> 
> So just as a reminder:
> 
> Back in the days of release_7.01h, the following used to work:
> 
> ,------------------------------------------
> | #+begin_src sh :dir /address@hidden:
> | hostname
> | #+end_src
> `------------------------------------------
> 
> Currently it produces the error:
> 
> ,---------------------------------------------------
> | apply: Wrong type argument: number-or-marker-p, ""
> `---------------------------------------------------
> 
> I have had another go at bisecting this problem and came up with this:
> 
> ,-------------------------------------------------------------------------------------------------------------
> | 9c878a8290c071fbe5e97bc33c300ef2f07d6153 is the first bad commit
> | commit 9c878a8290c071fbe5e97bc33c300ef2f07d6153
> | Author: Dan Davison <address@hidden>
> | Date:   Mon Aug 30 09:34:05 2010 -0700
> | 
> |     babel: Fix temporary file processing in the remote execution case.
> |     
> |         * ob.el (org-babel-temp-file): Don't use babel temporary
> |         directory in remote case; use make-temp-file with remote file
> |         name so that temp file is guaranteed not to exist previously
> |         on remote machine.
> |         (org-babel-tramp-localname): New function to return local name
> |         portion of possibly remote file specification
> |     
> |         * ob-R.el (org-babel-R-evaluate-external-process): Respond to
> |         changes in `org-babel-temp-file'; pass local file name to
> |         remote R process.
> |         (org-babel-R-evaluate-session) Respond to
> |         changes in `org-babel-temp-file'; pass local file name to
> |         remote R process.
> | 
> | :040000 040000 b31e072cf6b2951e95b7956d907303e7a04a8cfd 
> 5f794ada52cceb0614fe7962a399f7e549759003 M      lisp
> `-------------------------------------------------------------------------------------------------------------
> 
> Does that help anyone any further?
> 

I don't think so: afaict, both 7.01h (which did not contain this patch)
and 7.02 (which did) do the right thing (at least with your simple
script above). Something else broke it.

[I've been wrong about these things before so before Achim asks, I
did

  git tag --contains 9c878a8290c071fbe5e97bc33c300ef2f07d6153

and used its output as a basis of the above statement. I think (hope?)
it's correct.]

> Loris
> 
> PS: I am amazed there aren't any more peasants like myself with torches
> and pitchforks beating on the gates of Castle Org about this - remote
> execution is/was such great feature!
> 

Agreed, but Dan Davison (the principal contributor of the remoting code)
is gone from Castle Org (as you put it), Eric S. is busy, and nobody
else has stepped up to the plate. I've made fitful attempts to debug it,
but have had no success: I've never looked at the code in detail and I
don't have much time either.

So how about becoming a resident of Castle Org rather than beating on
the gates? There's glory galore if you fix it - and you get to scratch
your itch too :-)

Nick