Opened 8 years ago

Closed 8 years ago

#12267 closed defect (fixed)

multiply defined labels when using sagetex with multline

Reported by: dimpase Owned by: ddrake
Priority: major Milestone: sage-5.0
Component: misc Keywords:
Cc: ddrake, novoselt Merged in: sage-5.0.beta2
Authors: Dan Drake Reviewers: Dmitrii Pasechnik
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description (last modified by ddrake)

the following, distilled from a real example:

\documentclass{article}
\usepackage{amsmath,amsthm,sagetex}
\begin{document}
\begin{sagesilent}
d=4
\end{sagesilent}
\begin{multline}
\sage{(d)}=\\ \sage{d}
\end{multline}
\end{document}

produces the following sagetex.sout file:

% This file was *autogenerated* from s.sagetex.sage with
 % sagetex.py version 2011/05/27 v2.3.1
\newlabel{@sageinline0}{{%
4}{}{}{}{}}
\newlabel{@sageinline1}{{%
4}{}{}{}{}}
\newlabel{@sageinline0}{{%
4}{}{}{}{}}
\newlabel{@sageinline1}{{%
4}{}{}{}{}}
%34f836090e6dc538159452d641440313% md5sum of corresponding .sage file (minus "goboom" and pause/unpause lines)

which clearly has spurrious parts, resulting in

...
LaTeX Warning: Label `@sageinline0' multiply defined.
LaTeX Warning: Label `@sageinline1' multiply defined.
...

when running LaTeX for the 2nd, etc times.

This is fixed by the new SageTeX spkg: http://sage.math.washington.edu/home/drake/code/sage/st/sagetex-2.3.3.p1.spkg.

Change History (18)

comment:1 follow-up: Changed 8 years ago by ddrake

This should be fixed: https://bitbucket.org/ddrake/sagetex/changeset/3840ae05d2a7

What version of Sage / SageTeX are you using?

comment:2 in reply to: ↑ 1 ; follow-up: Changed 8 years ago by dimpase

  • Milestone changed from sage-5.0 to sage-4.8
  • Status changed from new to needs_info

Replying to ddrake:

This should be fixed: https://bitbucket.org/ddrake/sagetex/changeset/3840ae05d2a7

What version of Sage / SageTeX are you using?

2011/05/27 v2.3.1, in Sage 4.8.alpha4. Apparently you have not merged that fix into Sage proper, nor even "quite" applied it on bitbucket, as cloning your repo by doing hg clone https://bitbucket.org/ddrake/sagetex from there also creates 2011/05/27 v2.3.1.

comment:3 in reply to: ↑ 2 ; follow-up: Changed 8 years ago by ddrake

Replying to dimpase:

2011/05/27 v2.3.1, in Sage 4.8.alpha4. Apparently you have not merged that fix into Sage proper, nor even "quite" applied it on bitbucket, as cloning your repo by doing hg clone https://bitbucket.org/ddrake/sagetex from there also creates 2011/05/27 v2.3.1.

That's just version numbers; when you clone the repo, you get all the changesets on bitbucket, which includes that one. I just haven't updated the version numbers, which I suppose I should have.

4.8.alpha6 includes that changeset, so I'll look to see if something else is going on.

comment:4 in reply to: ↑ 3 ; follow-up: Changed 8 years ago by dimpase

Replying to ddrake:

Replying to dimpase:

2011/05/27 v2.3.1, in Sage 4.8.alpha4. Apparently you have not merged that fix into Sage proper, nor even "quite" applied it on bitbucket, as cloning your repo by doing hg clone https://bitbucket.org/ddrake/sagetex from there also creates 2011/05/27 v2.3.1.

That's just version numbers; when you clone the repo, you get all the changesets on bitbucket, which includes that one. I just haven't updated the version numbers, which I suppose I should have.

4.8.alpha6 includes that changeset, so I'll look to see if something else is going on.

I can confirm that the bitbucket clone generates (via latex sagetex.ins) the same sagetex.sty as the one in Sage 4.8.alpha4. Thus something did not get propagated somewhere...

comment:5 in reply to: ↑ 4 ; follow-up: Changed 8 years ago by ddrake

Replying to dimpase:

Thus something did not get propagated somewhere...

No, this isn't an issue of propagation. This is a new bug. And it's very interesting. Here's part of the .sage file that gets generated:

try:
 _st_.inline(0, latex((d)))
except:
 _st_.goboom(9)
try:
 _st_.inline(1, latex(d))
except:
 _st_.goboom(9)
try:
 _st_.inline(0, latex((d)))
except:
 _st_.goboom(9)
try:
 _st_.inline(1, latex(d))
except:
 _st_.goboom(9)

It does just d, and then (d). Intriguing.

What I do know is the those environments in the AMS classes evaluate their arguments in very strange ways, so this may be hard to pin down without knowing that code very well (which I certainly don't).

comment:6 in reply to: ↑ 5 Changed 8 years ago by ddrake

Replying to ddrake:

It does just d, and then (d). Intriguing.

*facepalm* Uh, not if I look again at your .tex file...nevermind about that.

comment:7 Changed 8 years ago by ddrake

Aha!

I can equal Rob Beezer's one-character patch. In fact, just a single bit needs to be changed: an = must be < (ASCII 0x3D to 0x3C; the least-significant bit gets flipped).

The problem is in my check to see if we've seen this label before; I didn't imagine that someone would (legitimately) use the same label twice in a single line. So inline() needs to check if the label it's asked to write is *less than or equal to*, instead of just equal to, the maximum label we've already written.

comment:8 follow-up: Changed 8 years ago by ddrake

This should be fixed by https://bitbucket.org/ddrake/sagetex/changeset/6cc763c2b649.

You can try this yourself: in $SAGE_ROOT/local/lib/python/site-packages/sagetex.py, go to line 81 and change the == to <=.

I suppose I should prep a new spkg and get that merged. Let me look into that.

comment:9 in reply to: ↑ 8 Changed 8 years ago by dimpase

Replying to ddrake:

This should be fixed by https://bitbucket.org/ddrake/sagetex/changeset/6cc763c2b649.

You can try this yourself: in $SAGE_ROOT/local/lib/python/site-packages/sagetex.py, go to line 81 and change the == to <=.

I suppose I should prep a new spkg and get that merged. Let me look into that.

OK, it looks good (and works with my "real" latex file). One thing about the new package: it would be good if the date and version in .sty file reflect the reality better than presently --- as you mention yourself in a comment above.

comment:10 Changed 8 years ago by ddrake

  • Authors set to Dan Drake
  • Status changed from needs_info to needs_review

While working on this, I uncovered a more serious bug: I was using a single variable (max_counter_seen) but had two different label names -- sageinline and sagecmdline. So after doing, say, 5 "inlines", max_counter_seen would be 5, and then if you did a sagecmdline, it would see a counter of 1 and not do anything!

So, we need to keep track of the label name as well as the maximum counter we've seen.

I also improved the version mismatch checking so that it works with arbitrarily old versions of sagetex.sty, so in particular people with Debian's TeXLive 2009 packages will be warned of version mismatches. This fixes #8035.

New spkg: http://sage.math.washington.edu/home/drake/code/sage/st/sagetex-2.3.3.p1.spkg.

comment:11 Changed 8 years ago by ddrake

  • Description modified (diff)
  • Owner changed from jason to ddrake

comment:12 follow-up: Changed 8 years ago by ddrake

Here are the key patches to look at to review the changes:

https://bitbucket.org/ddrake/sagetex/changeset/38ad59143e7e for new version checking. The new system does not rely on special bits written to the .sage file; rather, the SageTeX module looks for keyword arguments -- and if it doesn't get them, it knows it has an old version.

https://bitbucket.org/ddrake/sagetex/changeset/1603bbb82390 for the new label stuff. I now use a (special subclass of) dictionary to keep track of the counters and their corresponding labels. (You'll need to use "side-by-side view to look at py-and-sty.dtx, for some reason.)

comment:13 Changed 8 years ago by novoselt

  • Cc novoselt added

comment:14 in reply to: ↑ 12 ; follow-up: Changed 8 years ago by dimpase

  • Status changed from needs_review to positive_review

Replying to ddrake:

Here are the key patches to look at to review the changes:

https://bitbucket.org/ddrake/sagetex/changeset/38ad59143e7e for new version checking. The new system does not rely on special bits written to the .sage file; rather, the SageTeX module looks for keyword arguments -- and if it doesn't get them, it knows it has an old version.

https://bitbucket.org/ddrake/sagetex/changeset/1603bbb82390 for the new label stuff. I now use a (special subclass of) dictionary to keep track of the counters and their corresponding labels. (You'll need to use "side-by-side view to look at py-and-sty.dtx, for some reason.)

Looks good to me, positive review.

While I am at is, it occurred to me: how about integrating installing the (La)TeX part of the spkg into the corresponding subtree of TeX Live. Indeed, texconfig conf | grep TEXMFLOCAL provides you with the location of the local portion of texmf, where one can put the stuff as you please (provided you have the right permissions, of course --- otherwise one can use TEXMFHOME location instead), and them run texhash...

comment:15 Changed 8 years ago by novoselt

  • Reviewers set to Dmitrii Pasechnik

Personally, I think that the best way to use SageTeX is to copy sagetex.sty into the folder with the main *.tex file. This eliminates or at least reduces issues with version incompatibility and allows easy distribution of such papers - you can send everything in that folder to your colleague and it will compile without necessity to have Sage or SageTeX installed.

comment:16 in reply to: ↑ 14 ; follow-up: Changed 8 years ago by ddrake

Replying to dimpase:

While I am at is, it occurred to me: how about integrating installing the (La)TeX part of the spkg into the corresponding subtree of TeX Live. Indeed, texconfig conf | grep TEXMFLOCAL provides you with the location of the local portion of texmf, where one can put the stuff as you please (provided you have the right permissions, of course --- otherwise one can use TEXMFHOME location instead), and them run texhash...

That's a nice idea, but doing that automatically poses several problems: first, Sage does not mess with anything outside SAGE_ROOT when building. Second, while it wouldn't be too difficult to get TEXMFLOCAL and install, that directory tree will likely be owned by root, and we could try to run sudo...but would that work on Solaris?

I could write a little script that automates that installation. Does that sound like a good idea? Although I do wonder how users will find the script...

comment:17 in reply to: ↑ 16 Changed 8 years ago by dimpase

Replying to ddrake:

Replying to dimpase:

While I am at is, it occurred to me: how about integrating installing the (La)TeX part of the spkg into the corresponding subtree of TeX Live. Indeed, texconfig conf | grep TEXMFLOCAL provides you with the location of the local portion of texmf, where one can put the stuff as you please (provided you have the right permissions, of course --- otherwise one can use TEXMFHOME location instead), and them run texhash...

That's a nice idea, but doing that automatically poses several problems: first, Sage does not mess with anything outside SAGE_ROOT when building. Second, while it wouldn't be too difficult to get TEXMFLOCAL and install, that directory tree will likely be owned by root, and we could try to run sudo...but would that work on Solaris?

I could write a little script that automates that installation. Does that sound like a good idea? Although I do wonder how users will find the script...

Sage itself has install_scripts(). Maybe the script you propose should be a part of it?

comment:18 Changed 8 years ago by jdemeyer

  • Merged in set to sage-5.0.beta2
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.