From: Nick Dokos <nicholas.dokos@hp.com>
To: nicholas.dokos@hp.com
Cc: "Sébastien Vauban" <wxhgmqzgwmuf@spammotel.com>,
emacs-orgmode@gnu.org, "Jambunathan K" <kjambunathan@gmail.com>
Subject: Re: Re: Internal links in LaTeX export
Date: Fri, 29 Oct 2010 01:46:02 -0400 [thread overview]
Message-ID: <15827.1288331162@gamaville.dokosmarshall.org> (raw)
In-Reply-To: Message from Nick Dokos <nicholas.dokos@hp.com> of "Thu, 28 Oct 2010 23:28:35 EDT." <9528.1288322915@gamaville.dokosmarshall.org>
Nick Dokos <nicholas.dokos@hp.com> wrote:
> Thomas S. Dye <tsd@tsdye.com> wrote:
>
> > ...
> > I did hit on a revision that was neither good nor bad:
> >
> > commit 8562273b272024a630a582b0e1b94c481d8abeec
> > Author: Eric Schulte <schulte.eric@gmail.com>
> > 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 <commit>
This is all 20/20 hindsight of course, but I hope interesting
enough as a curiosity.
Nick
next prev parent reply other threads:[~2010-10-29 5:46 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-28 20:06 Internal links in LaTeX export Thomas S. Dye
2010-10-28 20:18 ` Sébastien Vauban
2010-10-28 20:44 ` Thomas S. Dye
2010-10-28 21:01 ` Jambunathan K
2010-10-28 21:19 ` Thomas S. Dye
2010-10-28 22:35 ` Nick Dokos
2010-10-29 0:20 ` Thomas S. Dye
2010-10-29 1:30 ` Jambunathan K
2010-10-29 2:04 ` Thomas S. Dye
2010-10-29 3:22 ` [SOLVED] " Jambunathan K
2010-10-29 3:58 ` Carsten Dominik
2010-10-29 5:01 ` Noorul Islam K M
2010-10-29 6:38 ` Tom Dye
2010-10-29 7:20 ` Nick Dokos
2010-10-29 7:51 ` Noorul Islam
2010-10-29 8:34 ` Nick Dokos
2010-11-13 5:55 ` [Accepted] " Carsten Dominik
2010-10-29 3:28 ` Nick Dokos
2010-10-29 5:46 ` Nick Dokos [this message]
2010-10-29 10:17 ` Jambunathan K
2010-10-30 19:56 ` suvayu ali
2010-11-02 7:35 ` Jambunathan K
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=15827.1288331162@gamaville.dokosmarshall.org \
--to=nicholas.dokos@hp.com \
--cc=emacs-orgmode@gnu.org \
--cc=kjambunathan@gmail.com \
--cc=wxhgmqzgwmuf@spammotel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).