emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Jambunathan K <kjambunathan@gmail.com>
To: nicholas.dokos@hp.com
Cc: emacs-orgmode@gnu.org
Subject: Re: Re: Internal links in LaTeX export
Date: Fri, 29 Oct 2010 15:47:12 +0530	[thread overview]
Message-ID: <81fwvpnw0n.fsf@gmail.com> (raw)
In-Reply-To: <15827.1288331162@gamaville.dokosmarshall.org> (Nick Dokos's message of "Fri, 29 Oct 2010 01:46:02 -0400")


Nick

I hunted down the bug with heuristics.

Speaking of bisections,

> 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>
>

Git bisection is wonderful. It is a bit of drag nevertheless - Tag,
Test, Tag, Test Tag, Test .... Ah, finally done (or undecided)

In the case at hand, it is clear that the issue is with either
org-latex.el (or org-exp.el). It is most likely the former because the
bug description is backend-specific.

I wish there was a way to say this:

- "do bisection on the revisions where org-latex.el changed (as opposed
   to revisions where HEAD moved)"

The candidate commits then would have reduced to 30 odd commits rather
than 851 that one had to contend with.

Hypothetically speaking, even this improved bisection would have left me
confused at somepoint because of the churn 'pdflatex & texi2dvi' churn
that pdf export process went through in recent times.

Jambunathan K.

> This is all 20/20 hindsight of course, but I hope interesting
> enough as a curiosity.
>
> Nick

  reply	other threads:[~2010-10-29 10:17 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
2010-10-29 10:17                 ` Jambunathan K [this message]
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=81fwvpnw0n.fsf@gmail.com \
    --to=kjambunathan@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=nicholas.dokos@hp.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).