From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: Erroneous "No such file or directory" with babel and remote dir Date: Wed, 14 Nov 2012 00:04:11 -0500 Message-ID: <7557.1352869451@alphaville> References: <87y5kiq71h.fsf@slate.zedat.fu-berlin.de> <87vcfapgfy.fsf@bzg.ath.cx> <87a9wd56i6.fsf@slate.zedat.fu-berlin.de> <878vbwhczx.fsf@Rainer.invalid> <87a9wc1uki.fsf@slate.zedat.fu-berlin.de> <87vcf0ft1s.fsf@Rainer.invalid> <87mx0chswg.fsf@slate.zedat.fu-berlin.de> <87r4pnpehe.fsf@Rainer.invalid> <87fw4dlei8.fsf@slate.zedat.fu-berlin.de> Reply-To: nicholas.dokos@hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([208.118.235.92]:42349) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYV97-0007Px-SS for emacs-orgmode@gnu.org; Wed, 14 Nov 2012 00:04:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TYV94-0003dy-Qi for emacs-orgmode@gnu.org; Wed, 14 Nov 2012 00:04:17 -0500 Received: from g5t0006.atlanta.hp.com ([15.192.0.43]:22656) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYV94-0003ds-Jh for emacs-orgmode@gnu.org; Wed, 14 Nov 2012 00:04:14 -0500 In-Reply-To: Message from "Loris Bennett" of "Tue\, 13 Nov 2012 16\:16\:31 +0100." <87fw4dlei8.fsf@slate.zedat.fu-berlin.de> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Loris Bennett Cc: Achim Gratz , emacs-orgmode@gnu.org Loris Bennett wrote: > Achim Gratz writes: >=20 > > 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=E2=80=A6 :-) > > > > 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. >=20 > So just as a reminder: >=20 > Back in the days of release_7.01h, the following used to work: >=20 > ,------------------------------------------ > | #+begin_src sh :dir /loris@othercomputer: > | hostname > | #+end_src > `------------------------------------------ >=20 > Currently it produces the error: >=20 > ,--------------------------------------------------- > | apply: Wrong type argument: number-or-marker-p, "" > `--------------------------------------------------- >=20 > I have had another go at bisecting this problem and came up with this: >=20 > ,------------------------------------------------------------------------= ------------------------------------- > | 9c878a8290c071fbe5e97bc33c300ef2f07d6153 is the first bad commit > | commit 9c878a8290c071fbe5e97bc33c300ef2f07d6153 > | Author: Dan Davison > | Date: Mon Aug 30 09:34:05 2010 -0700 > |=20 > | babel: Fix temporary file processing in the remote execution case. > |=20=20=20=20=20 > | * 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 > |=20=20=20=20=20 > | * 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. > |=20 > | :040000 040000 b31e072cf6b2951e95b7956d907303e7a04a8cfd 5f794ada52cceb0= 614fe7962a399f7e549759003 M lisp > `------------------------------------------------------------------------= ------------------------------------- >=20 > Does that help anyone any further? >=20 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 >=20 > 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! >=20 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