Opened 9 years ago
Closed 9 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 )
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: ↓ 2 Changed 9 years ago by
comment:2 in reply to: ↑ 1 ; follow-up: ↓ 3 Changed 9 years ago by
- 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: ↓ 4 Changed 9 years ago by
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: ↓ 5 Changed 9 years ago by
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: ↓ 6 Changed 9 years ago by
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 9 years ago by
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 9 years ago by
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: ↓ 9 Changed 9 years ago by
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 9 years ago by
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 9 years ago by
- 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 9 years ago by
- Description modified (diff)
- Owner changed from jason to ddrake
comment:12 follow-up: ↓ 14 Changed 9 years ago by
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 9 years ago by
- Cc novoselt added
comment:14 in reply to: ↑ 12 ; follow-up: ↓ 16 Changed 9 years ago by
- 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 9 years ago by
- 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: ↓ 17 Changed 9 years ago by
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 runtexhash
...
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 9 years ago by
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 runtexhash
...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 9 years ago by
- Merged in set to sage-5.0.beta2
- Resolution set to fixed
- Status changed from positive_review to closed
This should be fixed: https://bitbucket.org/ddrake/sagetex/changeset/3840ae05d2a7
What version of Sage / SageTeX are you using?