From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: Re: Internal links in LaTeX export Date: Fri, 29 Oct 2010 01:46:02 -0400 Message-ID: <15827.1288331162@gamaville.dokosmarshall.org> References: <54309AAF-34E2-47F9-9DF2-236DC9BBFA69@tsdye.com> <80y69i5avh.fsf@mundaneum.com> <8439CC4F-8895-43F1-BE6A-D8E5A491A908@tsdye.com> <81tyk6117u.fsf@gmail.com> <18647.1288305308@alphaville.usa.hp.com> <25705B2C-189C-47A3-B6DC-71026E1DAC09@tsdye.com> <9528.1288322915@gamaville.dokosmarshall.org> Reply-To: nicholas.dokos@hp.com Return-path: Received: from [140.186.70.92] (port=52100 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PBhn6-0002vB-MY for emacs-orgmode@gnu.org; Fri, 29 Oct 2010 01:46:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PBhn5-00015d-9g for emacs-orgmode@gnu.org; Fri, 29 Oct 2010 01:46:16 -0400 Received: from vms173011pub.verizon.net ([206.46.173.11]:63226) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PBhn5-00015Q-4x for emacs-orgmode@gnu.org; Fri, 29 Oct 2010 01:46:15 -0400 Received: from gamaville.dokosmarshall.org ([unknown] [173.76.32.106]) by vms173011.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LB1008XHEOQ4H30@vms173011.mailsrvcs.net> for emacs-orgmode@gnu.org; Fri, 29 Oct 2010 00:46:03 -0500 (CDT) In-reply-to: Message from Nick Dokos of "Thu, 28 Oct 2010 23:28:35 EDT." <9528.1288322915@gamaville.dokosmarshall.org> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: nicholas.dokos@hp.com Cc: =?ISO-8859-1?Q?S=E9bastien_Vauban?= , emacs-orgmode@gnu.org, Jambunathan K Nick Dokos wrote: > Thomas S. Dye wrote: > > > ... > > I did hit on a revision that was neither good nor bad: > > > > commit 8562273b272024a630a582b0e1b94c481d8abeec > > Author: Eric Schulte > > Date: Sat Oct 16 13:21:47 2010 -0600 > > > > ob-ref: don't forget arguments to referenced code blocks > > > > * lisp/ob-ref.el (org-babel-ref-resolve): bringing the referent > > arguments back to their params before evaluation > > > > This one puts these lines in *Messages* when I export to LaTeX > > > > executing Org code block... > > if: Symbol's value as variable is void: result-type > > > > Yeah, that was the error that stopped me cold as well, although I hit it In case it wasn't clear, that was a couple of days ago on a different bisection, while chasing another problem. > on a different commit (I think) - there must be a way to get around the > problem but it certainly makes things more difficult. I imagine the way > to go is to find a commit before this error was introduced and a commit > after it was fixed and try those with your problem: it might allow you > to bypass the problematic range (in which case, you might be able to > continue bisecting all the way to the end), or it might limit the bad > commit to this range - the latter is still valuable to know but > certainly not as definitive as "this is the bad commit". And in any > case, all of this would fall into the "advanced" appendix in the git > bisection book. > > Sorry it didn't pan out but I hope that you had fun digging, > In this instance, I actually bisected it down to the bad commit that Jambunathan K. identified (and Carsten reverted). I guess I was lucky in the sense that I pulled a couple of days ago, so HEAD was 851 commits ahead of 7.01h and the bisection proceeded as follows: release_7.01h-851-gfd9e933 - bad release_7.01h - good release_7.01h-425-gfea9072 - good release_7.01h-638-gd9e4469 - good release_7.01h-744-g3d2aec3 - bad <<<<<< release_7.01h-691-g6b9782d - good release_7.01h-717-gc9bb51e - bad release_7.01h-704-g935c310 - good release_7.01h-710-gc9b0176 - good release_7.01h-713-g8820a25 - good release_7.01h-715-gf5918bd - bad release_7.01h-714-gdf5894c - good and it identified release_7.01h-715-gf5918bd as the first bad commit. From the previous investigation, I know that the result-type error that you ran into, was introduced after commit 750 and resolved before commit 800 (using release_7.01h as the origin), so once I got to the <<<< point above, I was safe: I couldn't possibly end up in the problematic range. OTOH, if you start from say 810, the sequence would be 405, 608, 709, 759 (or so) and you end up in the problematic range, which is probably what happened to you. BTW, I got the bisection sequence (after the fact) with git bisect log and then translated the (40-hex digit SHA1 form) commits to the more readable form above using git describe This is all 20/20 hindsight of course, but I hope interesting enough as a curiosity. Nick