Sage: Ticket #9107: Nested class name mangling can be wrong in case of double nesting
https://trac.sagemath.org/ticket/9107
<p>
In the following class tree:
</p>
<pre class="wiki">class Bla(UniqueRepresentation):
class Bla1(UniqueRepresentation):
class Bla11:
Pass
class Bla2:
class Bla21:
Pass
</pre><p>
The names are set to
</p>
<pre class="wiki"> sage: Bla.Bla1.__name__
'Bla.Bla1'
sage: Bla.Bla2.__name__
'Bla.Bla2'
sage: Bla.Bla2.Bla21.__name__
'Bla.Bla2.Bla21'
</pre><p>
But
</p>
<pre class="wiki"> sage: Bla.Bla1.Bla11.__name__
'Bla1.Bla11'
</pre><p>
whereas one would expect <code>'Bla.Bla1.Bla11'</code>
This breaks a lot of doc in categories and in particular in functorial constructions.
</p>
<p>
<span class="underline">Apply</span>
</p>
<ul><li><a class="attachment" href="https://trac.sagemath.org/attachment/ticket/9107/trac9107_nesting_nested_classes.patch" title="Attachment 'trac9107_nesting_nested_classes.patch' in Ticket #9107">trac9107_nesting_nested_classes.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/9107/trac9107_nesting_nested_classes.patch" title="Download"></a>
</li><li><a class="attachment" href="https://trac.sagemath.org/attachment/ticket/9107/trac_9107_fix_cross_reference.patch" title="Attachment 'trac_9107_fix_cross_reference.patch' in Ticket #9107">trac_9107_fix_cross_reference.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/9107/trac_9107_fix_cross_reference.patch" title="Download"></a>
</li></ul>en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/9107
Trac 1.1.6SimonKingFri, 02 Sep 2011 16:06:38 GMTcc set
https://trac.sagemath.org/ticket/9107#comment:1
https://trac.sagemath.org/ticket/9107#comment:1
<ul>
<li><strong>cc</strong>
<em>SimonKing</em> added
</li>
</ul>
TicketSimonKingWed, 02 May 2012 14:42:54 GMTdependencies set
https://trac.sagemath.org/ticket/9107#comment:2
https://trac.sagemath.org/ticket/9107#comment:2
<ul>
<li><strong>dependencies</strong>
set to <em>#12808</em>
</li>
</ul>
<p>
I think we should make this depend on <a class="closed ticket" href="https://trac.sagemath.org/ticket/12808" title="enhancement: Optimize ClassCallMetaClass using Cython (closed: fixed)">#12808</a>, because it cythonises nested classes.
</p>
<p>
Here is my analysis:
</p>
<ol><li>In sage.misc.nested_class.modify_for_nested_pickling, only those attributes of a class are (recursively) renamed that are instances of type or of <code>ClassType</code>. However, ironically, instances of <code>NestedClassMetaclass</code> are ignored.
</li><li>It is verified that the name of the to-be-changed class is identical with its name as an attribute of the calling class. But the renaming breaks the identity.
</li></ol>
TicketSimonKingWed, 02 May 2012 16:37:49 GMTstatus changed; author set
https://trac.sagemath.org/ticket/9107#comment:3
https://trac.sagemath.org/ticket/9107#comment:3
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
<li><strong>author</strong>
set to <em>Simon King</em>
</li>
</ul>
<p>
I think the attached patch solves the problem. I get:
</p>
<pre class="wiki">sage: class Bla(UniqueRepresentation):
....: class Bla1(UniqueRepresentation):
....: class Bla11:
....: pass
....: class Bla2:
....: class Bla21:
....: pass
....:
sage: Bla.Bla1.Bla11
<class __main__.Bla.Bla1.Bla11 at 0x46e7808>
</pre><p>
The change is in <code>modify_for_nested_pickle</code>, which is called recursively. The idea is that the function should have an extra argument <code>first_run</code>, that is True by default. If the extra argument is False, then it is assumed that it is not applied for the first time.
</p>
<p>
Here: Since Bla.Bla1 is an instance of <code>NestedClassMetaclass</code>, <code>modify_for_nested_pickle</code> is called on <code>Bla.Bla1.Bla11</code>, resulting in <code>Bla.Bla1.Bla11.__name__=='Bla1.Bla11'</code>. However, since Bla is an instance of <code>NestedClassMetaclass</code> as well, the function is applied to <code>Bla.Bla1</code> and thus recursively to <code>Bla.Bla1.Bla11</code> another time.
</p>
<p>
Now, without my patch, in the second run, <code>modify_for_nested_pickle</code> would be confused by the fact that <code>Bla.Bla1.__dict__</code> lists <code>Bla.Bla1.Bla11</code> under the name <code>Bla11</code>, but <code>Bla11.__name__=='Bla1.Bla11'</code>. With my patch, <code>modify_for_nested_pickle</code> expects exactly that naming scheme, and is thus changing <code>Bla.Bla1.Bla11.__name__</code> into <code>"Bla.Bla1.Bla11"</code>.
</p>
<p>
Much BlaBla, but I think it works...
</p>
<p>
<strong><span class="underline">Potential problems</span></strong>
</p>
<pre class="wiki">sage: module = sys.modules['__main__']
sage: getattr(module, 'Bla1.Bla11')
<class __main__.Bla.Bla1.Bla11 at 0x46e7808>
sage: getattr(module, 'Bla.Bla1.Bla11')
<class __main__.Bla.Bla1.Bla11 at 0x46e7808>
</pre><p>
Hence, Bla.Bla1.Bla11 is listed in the module under two different names. If you think it is bad, then one could probably modify the function when first_run is false, such that the name given in the first run is erased from the module.
</p>
<p>
Moreover, the reviewer will likely find a speed regression, when excessively creating nested unique representations. But that's hardly realistic...
</p>
TicketSimonKingWed, 02 May 2012 16:46:54 GMT
https://trac.sagemath.org/ticket/9107#comment:4
https://trac.sagemath.org/ticket/9107#comment:4
<p>
Another problem: Source inspection does not work yet in the following example.
</p>
<pre class="wiki">sage: cython_code = [
... "from sage.structure.unique_representation import UniqueRepresentation",
... "class A1(UniqueRepresentation):",
... " class B1(UniqueRepresentation):",
... " class C1: pass",
... " class B2:",
... " class C2: pass"]
sage: import os
sage: cython(os.linesep.join(cython_code))
sage: A1.B1.C1??
Error getting source: class A1.B1.C1 has no attribute '__class__'
Type: classobj
String Form: _mnt_local_king__sage_temp_mpc622_6475_tmp_0_spyx_0.A1.B1.C1
Namespace: Interactive
Loaded File: /mnt/local/king/.sage/temp/mpc622/6475/spyx/_mnt_local_king__sage_temp_mpc622_6475_tmp_0_spyx/_mnt_local_king__sage_temp_mpc622_6475_tmp_0_spyx_0.so
Source File: /mnt/local/king/.sage/temp/mpc622/6475/spyx/_mnt_local_king__sage_temp_mpc622_6475_tmp_0_spyx/_mnt_local_king__sage_temp_mpc622_6475_tmp_0_spyx_0.so
</pre><p>
Even <a class="closed ticket" href="https://trac.sagemath.org/ticket/11768" title="enhancement: Get source code for parent/element classes of categories (closed: fixed)">#11768</a> does not solve the problem.
</p>
<p>
Shall that be dealt with on a different ticket? Or in one go?
</p>
<p>
Probably on a different ticket, since I just find that even source inspection for A1 (which has a usual name) does not work...
</p>
TicketSimonKingThu, 03 May 2012 16:16:56 GMT
https://trac.sagemath.org/ticket/9107#comment:5
https://trac.sagemath.org/ticket/9107#comment:5
<p>
For the record: If <a class="needs_work ticket" href="https://trac.sagemath.org/ticket/11791" title="enhancement: Introspection for interactively defined classes with metaclass (needs_work)">#11791</a> is applied after this ticket, source inspection in the example above works (and is doctested).
</p>
TicketSimonKingMon, 13 Aug 2012 13:10:22 GMT
https://trac.sagemath.org/ticket/9107#comment:6
https://trac.sagemath.org/ticket/9107#comment:6
<p>
Is there a reviewer to fix name mangling of nested classes (needed in the category framework)?
</p>
TicketsaliolaThu, 23 Aug 2012 01:01:17 GMT
https://trac.sagemath.org/ticket/9107#comment:7
https://trac.sagemath.org/ticket/9107#comment:7
<p>
This patch also fixes an issue that came up in <a class="closed ticket" href="https://trac.sagemath.org/ticket/8899" title="enhancement: Implement non commutative symmetric functions (closed: fixed)">#8899</a> regarding documentation of nested classes not appearing in the reference manual.
</p>
<p>
See here for a description of the issue, see the <a class="ext-link" href="https://groups.google.com/d/topic/sage-combinat-devel/gWVx1It60ao/discussion"><span class="icon"></span>thread on sage-combinat-devel</a>.
</p>
<p>
See here for the confirmation that this works: <a class="ext-link" href="http://trac.sagemath.org/sage_trac/ticket/8899#comment:31"><span class="icon"></span>http://trac.sagemath.org/sage_trac/ticket/8899#comment:31</a>
</p>
TicketvbraunTue, 27 Nov 2012 10:42:39 GMTstatus changed; reviewer set
https://trac.sagemath.org/ticket/9107#comment:8
https://trac.sagemath.org/ticket/9107#comment:8
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
<li><strong>reviewer</strong>
set to <em>Volker Braun</em>
</li>
</ul>
<p>
LGTM!
</p>
TicketjdemeyerWed, 19 Dec 2012 15:37:28 GMT
https://trac.sagemath.org/ticket/9107#comment:9
https://trac.sagemath.org/ticket/9107#comment:9
<p>
This causes trouble when building the documentation from scratch (i.e. after deleting 'devel/sage/doc/output`):
</p>
<pre class="wiki">/usr/local/src/sage-5.5.rc1/local/lib/python2.7/site-packages/sage/categories/algebras_with_basis.py:docstring of sage.categories.algebras_with_basis.AlgebrasWithBasis.CartesianProducts.ParentMethods.one_from_cartesian_product_of_one_basis:3: WARNING: more than one target found for cross-reference u'one_basis': sage.combinat.sf.new_kschur.KBoundedSubspaceBases.ParentMethods.one_basis, sage.categories.algebras_with_basis.AlgebrasWithBasis.ParentMethods.one_basis, sage.combinat.ncsf_qsym.generic_basis_code.BasesOfQSymOrNCSF.ParentMethods.one_basis, sage.algebras.steenrod.steenrod_algebra.SteenrodAlgebra_generic.one_basis, sage.categories.examples.with_realizations.SubsetAlgebra.Fundamental.one_basis, sage.combinat.root_system.weyl_characters.WeightRing.one_basis, sage.categories.monoids.Monoids.Algebras.ParentMethods.one_basis, sage.categories.examples.hopf_algebras_with_basis.MyGroupAlgebra.one_basis, sage.categories.algebras_with_basis.AlgebrasWithBasis.TensorProducts.ParentMethods.one_basis, sage.algebras.affine_nil_temperley_lieb.AffineNilTemperleyLiebTypeA.one_basis, sage.categories.examples.algebras_with_basis.FreeAlgebra.one_basis, sage.combinat.symmetric_group_algebra.SymmetricGroupAlgebra_n.one_basis, sage.algebras.iwahori_hecke_algebra.IwahoriHeckeAlgebraT.one_basis, sage.algebras.group_algebra_new.GroupAlgebra.one_basis, sage.combinat.sf.sfa.SymmetricFunctionsBases.ParentMethods.one_basis, sage.combinat.root_system.weyl_characters.WeylCharacterRing.one_basis, sage.combinat.combinatorial_algebra.CombinatorialAlgebra.one_basis
</pre>
TicketjdemeyerWed, 19 Dec 2012 15:38:07 GMTstatus changed
https://trac.sagemath.org/ticket/9107#comment:10
https://trac.sagemath.org/ticket/9107#comment:10
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_work</em>
</li>
</ul>
TicketSimonKingSat, 19 Jan 2013 18:30:18 GMT
https://trac.sagemath.org/ticket/9107#comment:11
https://trac.sagemath.org/ticket/9107#comment:11
<p>
Jeroen, can you elaborate a bit what went wrong?
</p>
TicketSimonKingSat, 19 Jan 2013 20:27:44 GMT
https://trac.sagemath.org/ticket/9107#comment:12
https://trac.sagemath.org/ticket/9107#comment:12
<p>
Aha, now I see that the very long single line contains warnings about cross references that were not found. I'll try to identify them.
</p>
TicketSimonKingSat, 19 Jan 2013 20:33:29 GMT
https://trac.sagemath.org/ticket/9107#comment:13
https://trac.sagemath.org/ticket/9107#comment:13
<p>
Aha, here is an example:
</p>
<p>
The docstring of <code>sage.categories.algebras_with_basis.AlgebrasWithBasis.CartesianProducts.ParentMethods.one_from_cartesian_product_of_one_basis</code> is as follows:
</p>
<pre class="wiki"> @cached_method # todo: reinstate once #5843 is fixed
def one_from_cartesian_product_of_one_basis(self):
"""
Returns the one of this cartesian product of algebras, as per ``Monoids.ParentMethods.one``
It is constructed as the cartesian product of the ones of the
summands, using their :meth:`.one_basis` methods.
This implementation does not require multiplication by
scalars nor calling cartesian_product. This might help keeping
things as lazy as possible upon initialization.
...
</pre><p>
Could this simply be a misspelling? Note that it is written
</p>
<pre class="wiki">:meth:`.one_basis`
</pre><p>
but should certainly be
</p>
<pre class="wiki">:meth:`one_basis`
</pre><p>
If that's the case for the other warnings as well, then my patch would just uncover mistakes that happened earlier.
</p>
TicketjhpalmieriSat, 19 Jan 2013 20:49:19 GMT
https://trac.sagemath.org/ticket/9107#comment:14
https://trac.sagemath.org/ticket/9107#comment:14
<p>
The same issue arose in <a class="closed ticket" href="https://trac.sagemath.org/ticket/13851" title="enhancement: Add SAT Solver Interface to Reference Manual (closed: fixed)">#13851</a> (see <a class="ext-link" href="http://trac.sagemath.org/sage_trac/ticket/13851#comment:10"><span class="icon"></span>comment 10</a>). I'm not sure why those dots are there, and I personally think they should be removed, but someone intentionally put them there.
</p>
TicketSimonKingSat, 19 Jan 2013 20:54:54 GMT
https://trac.sagemath.org/ticket/9107#comment:15
https://trac.sagemath.org/ticket/9107#comment:15
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:14" title="Comment 14">jhpalmieri</a>:
</p>
<blockquote class="citation">
<p>
The same issue arose in <a class="closed ticket" href="https://trac.sagemath.org/ticket/13851" title="enhancement: Add SAT Solver Interface to Reference Manual (closed: fixed)">#13851</a> (see <a class="ext-link" href="http://trac.sagemath.org/sage_trac/ticket/13851#comment:10"><span class="icon"></span>comment 10</a>). I'm not sure why those dots are there, and I personally think they should be removed, but someone intentionally put them there.
</p>
</blockquote>
<p>
I think the dot is simply wrong - or is it ignored by Sphinx?
</p>
<p>
Actually here it is even worse. The text is documentation of a functorial construction, but refers to a parent method - that can't possibly work without an explicit reference to the method which must include the class which the method belongs to.
</p>
TicketSimonKingSat, 19 Jan 2013 21:12:29 GMTattachment set
https://trac.sagemath.org/ticket/9107
https://trac.sagemath.org/ticket/9107
<ul>
<li><strong>attachment</strong>
set to <em>trac_9107_fix_cross_reference.patch</em>
</li>
</ul>
<p>
Fix a cross reference in some functorial construction
</p>
TicketSimonKingSat, 19 Jan 2013 21:13:25 GMTstatus changed
https://trac.sagemath.org/ticket/9107#comment:16
https://trac.sagemath.org/ticket/9107#comment:16
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
Does the second patch fix the problem? I am now explicitly referring to the <code>one_basis</code> method of <code>AlgebrasWithBasis.ParentMethods</code>.
</p>
TickethivertWed, 20 Mar 2013 15:25:03 GMTstatus, reviewer changed
https://trac.sagemath.org/ticket/9107#comment:17
https://trac.sagemath.org/ticket/9107#comment:17
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
<li><strong>reviewer</strong>
changed from <em>Volker Braun</em> to <em>Volker Braun, Florent Hivert</em>
</li>
</ul>
<p>
Hi Simon,
</p>
<p>
I again hit this one compiling the doc. Your patches look all good to me, including the one problem.
</p>
<p>
Thanks,
</p>
<p>
Florent
</p>
TicketjdemeyerThu, 21 Mar 2013 06:36:57 GMTstatus changed
https://trac.sagemath.org/ticket/9107#comment:18
https://trac.sagemath.org/ticket/9107#comment:18
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
Applying this patch causes the PDF docbuilder to hang after it's done building all documents. All documents are built but there are still 6 (I'm building with <code>MAKE="make -j6"</code>) child processes which are stuck in the <code>multiprocessing.Pool</code> code. Interrupting those child processes simply causes new child processes to start which are then stuck again. It might be a bug in <code>multiprocessing.Pool</code> which is somehow triggered, I have no idea...
</p>
TicketjdemeyerThu, 21 Mar 2013 06:38:33 GMT
https://trac.sagemath.org/ticket/9107#comment:19
https://trac.sagemath.org/ticket/9107#comment:19
<p>
Perhaps an instance of <a class="closed ticket" href="https://trac.sagemath.org/ticket/14323" title="defect: libGAP messes with Python subprocesses (closed: fixed)">#14323</a> (wild guess)?
</p>
TicketjdemeyerSun, 24 Mar 2013 12:31:50 GMT
https://trac.sagemath.org/ticket/9107#comment:20
https://trac.sagemath.org/ticket/9107#comment:20
<p>
No, <a class="closed ticket" href="https://trac.sagemath.org/ticket/14323" title="defect: libGAP messes with Python subprocesses (closed: fixed)">#14323</a> doesn't help.
</p>
TicketSimonKingWed, 22 May 2013 11:06:20 GMT
https://trac.sagemath.org/ticket/9107#comment:21
https://trac.sagemath.org/ticket/9107#comment:21
<p>
Jeroen, does the problem persist with the new doc builder? I have just applied the two patches, and succeeded with <code>export MAKE="make -j2"</code> followed by <code>make</code>.
</p>
<p>
However, there is continuation by <code>...</code> that needs fixing.
</p>
TicketSimonKingWed, 22 May 2013 12:56:57 GMTattachment set
https://trac.sagemath.org/ticket/9107
https://trac.sagemath.org/ticket/9107
<ul>
<li><strong>attachment</strong>
set to <em>trac9107_nesting_nested_classes.patch</em>
</li>
</ul>
TicketSimonKingWed, 22 May 2013 13:00:25 GMTstatus, description changed
https://trac.sagemath.org/ticket/9107#comment:22
https://trac.sagemath.org/ticket/9107#comment:22
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/9107?action=diff&version=22">diff</a>)
</li>
</ul>
<p>
Building the docs works for me, and the <code>...</code> should be fixed now. Hence: Needs review!
</p>
<p>
Apply trac9107_nesting_nested_classes.patch trac_9107_fix_cross_reference.patch
</p>
TicketjdemeyerWed, 22 May 2013 15:05:04 GMT
https://trac.sagemath.org/ticket/9107#comment:23
https://trac.sagemath.org/ticket/9107#comment:23
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:22" title="Comment 22">SimonKing</a>:
</p>
<blockquote class="citation">
<p>
Building the docs works for me
</p>
</blockquote>
<p>
Also the PDF docs?
</p>
TicketjdemeyerWed, 22 May 2013 15:08:05 GMT
https://trac.sagemath.org/ticket/9107#comment:24
https://trac.sagemath.org/ticket/9107#comment:24
<p>
There is a problem with latex and the fact that the docbuilder <em>hangs</em> is a bug in the new docbuilder: <a class="closed ticket" href="https://trac.sagemath.org/ticket/14626" title="defect: Docbuilder hangs if latex fails (closed: fixed)">#14626</a>
</p>
<pre class="wiki">! LaTeX Error: Too deeply nested.
See the LaTeX manual or LaTeX Companion for explanation.
Type H <return> for immediate help.
...
l.27819 \begin{Verbatim}[commandchars=\\\{\}]
?
Implicit mode ON; LaTeX internals redefined
(/usr/share/texmf-texlive/tex/latex/ltxmisc/url.sty
(/usr/share/texmf-texlive/tex/latex/base/t1enc.def)
! Emergency stop.
...
l.27819 \begin{Verbatim}[commandchars=\\\{\}]
! ==> Fatal error occurred, no output PDF file produced!
Transcript written on categories.log.
)make[1]: *** [categories.pdf] Error 1
</pre>
TicketjdemeyerWed, 22 May 2013 15:10:38 GMTstatus changed
https://trac.sagemath.org/ticket/9107#comment:25
https://trac.sagemath.org/ticket/9107#comment:25
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
TicketSimonKingWed, 22 May 2013 15:23:15 GMT
https://trac.sagemath.org/ticket/9107#comment:26
https://trac.sagemath.org/ticket/9107#comment:26
<p>
Yes, I did not consider the pdf docs.
</p>
<p>
If I understand correctly, we have two problems. The first problem is that with this patch, <code>LaTeX</code> is produced that can not be processed because it is two deeply nested. The second problem is independent, namely if latex fails, then the docbuilder hangs.
</p>
<p>
Do you have any clue what object is being processed when things hang?
</p>
TicketjdemeyerWed, 22 May 2013 15:29:04 GMT
https://trac.sagemath.org/ticket/9107#comment:27
https://trac.sagemath.org/ticket/9107#comment:27
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:26" title="Comment 26">SimonKing</a>:
</p>
<blockquote class="citation">
<p>
The second problem is independent, namely if latex fails, then the docbuilder hangs.
</p>
</blockquote>
<p>
Which is <a class="closed ticket" href="https://trac.sagemath.org/ticket/14626" title="defect: Docbuilder hangs if latex fails (closed: fixed)">#14626</a> and indeed has nothing to do with this ticket.
</p>
<blockquote class="citation">
<p>
Do you have any clue what object is being processed when things hang?
</p>
</blockquote>
<p>
Not yet, I will reproduce the <code>.tex</code> file and then it should be clear.
</p>
TicketjdemeyerWed, 22 May 2013 15:48:01 GMT
https://trac.sagemath.org/ticket/9107#comment:28
https://trac.sagemath.org/ticket/9107#comment:28
<p>
Offending <code>.tex</code> file: <a class="ext-link" href="http://boxen.math.washington.edu/home/jdemeyer/badlatex/categories.tex"><span class="icon"></span>http://boxen.math.washington.edu/home/jdemeyer/badlatex/categories.tex</a>
</p>
<p>
The relevant lines are
</p>
<pre class="wiki">\begin{fulllineitems}
\phantomsection\label{sage/categories/sets_cat:sage.categories.sets_cat.Sets.WithRealizations.ParentMethods}\pysigline{\strong{class }\bfcode{ParentMethods}}~\index{Sets.WithRealizations.ParentMethods.Realizations (class in sage.categories.sets\_cat)}
\begin{fulllineitems}
\phantomsection\label{sage/categories/sets_cat:sage.categories.sets_cat.Sets.WithRealizations.ParentMethods.Realizations}\pysiglinewithargsret{\strong{class }\bfcode{Realizations}}{\emph{parent\_with\_realization}}{}
Bases: {\hyperref[sage/categories/realizations:sage.categories.realizations.Category_realization_of_parent]{\code{sage.categories.realizations.Category\_realization\_of\_parent}}}
TESTS:
\begin{Verbatim}[commandchars=\\\{\}]
\PYG{g+gp}{sage: }\PYG{k+kn}{from} \PYG{n+nn}{sage.categories.realizations} \PYG{k+kn}{import} \PYG{n}{Category\PYGZus{}realization\PYGZus{}of\PYGZus{}parent}
\PYG{g+gp}{sage: }\PYG{n}{A} \PYG{o}{=} \PYG{n}{Sets}\PYG{p}{(}\PYG{p}{)}\PYG{o}{.}\PYG{n}{WithRealizations}\PYG{p}{(}\PYG{p}{)}\PYG{o}{.}\PYG{n}{example}\PYG{p}{(}\PYG{p}{)}\PYG{p}{;} \PYG{n}{A}
\PYG{g+go}{The subset algebra of \PYGZob{}1, 2, 3\PYGZcb{} over Rational Field}
\PYG{g+gp}{sage: }\PYG{n}{C} \PYG{o}{=} \PYG{n}{A}\PYG{o}{.}\PYG{n}{Realizations}\PYG{p}{(}\PYG{p}{)}\PYG{p}{;} \PYG{n}{C}
\PYG{g+go}{Category of realizations of The subset algebra of \PYGZob{}1, 2, 3\PYGZcb{} over Rational Field}
\PYG{g+gp}{sage: }\PYG{n+nb}{isinstance}\PYG{p}{(}\PYG{n}{C}\PYG{p}{,} \PYG{n}{Category\PYGZus{}realization\PYGZus{}of\PYGZus{}parent}\PYG{p}{)}
\PYG{g+go}{True}
\PYG{g+gp}{sage: }\PYG{n}{C}\PYG{o}{.}\PYG{n}{parent\PYGZus{}with\PYGZus{}realization}
\PYG{g+go}{The subset algebra of \PYGZob{}1, 2, 3\PYGZcb{} over Rational Field}
\PYG{g+gp}{sage: }\PYG{n}{TestSuite}\PYG{p}{(}\PYG{n}{C}\PYG{p}{)}\PYG{o}{.}\PYG{n}{run}\PYG{p}{(}\PYG{p}{)}
\end{Verbatim}
\index{super\_categories() (sage.categories.sets\_cat.Sets.WithRealizations.ParentMethods.Realizations method)}
\begin{fulllineitems}
\phantomsection\label{sage/categories/sets_cat:sage.categories.sets_cat.Sets.WithRealizations.ParentMethods.Realizations.super_categories}\pysiglinewithargsret{\bfcode{super\_categories}}{}{}
EXAMPLES:
\begin{Verbatim}[commandchars=\\\{\}] %% PROBLEM IS THIS LINE %%
\PYG{g+gp}{sage: }\PYG{n}{A} \PYG{o}{=} \PYG{n}{Sets}\PYG{p}{(}\PYG{p}{)}\PYG{o}{.}\PYG{n}{WithRealizations}\PYG{p}{(}\PYG{p}{)}\PYG{o}{.}\PYG{n}{example}\PYG{p}{(}\PYG{p}{)}\PYG{p}{;} \PYG{n}{A}
\PYG{g+go}{The subset algebra of \PYGZob{}1, 2, 3\PYGZcb{} over Rational Field}
\PYG{g+gp}{sage: }\PYG{n}{A}\PYG{o}{.}\PYG{n}{Realizations}\PYG{p}{(}\PYG{p}{)}\PYG{o}{.}\PYG{n}{super\PYGZus{}categories}\PYG{p}{(}\PYG{p}{)}
\PYG{g+go}{[Category of realizations of sets]}
\end{Verbatim}
\end{fulllineitems}
\end{fulllineitems}
\index{facade\_for() (sage.categories.sets\_cat.Sets.WithRealizations.ParentMethods method)}
</pre>
TicketjdemeyerWed, 22 May 2013 15:54:55 GMT
https://trac.sagemath.org/ticket/9107#comment:29
https://trac.sagemath.org/ticket/9107#comment:29
<p>
<strong>before</strong> this patch (good):
</p>
<pre class="wiki">\phantomsection\label{sage/categories/sets_cat:sage.categories.sets_cat.Sets.WithRealizations.ParentMethods}\pysigline{\bfcode{ParentMethods}}
alias of \code{WithRealizations.ParentMethods}
</pre><p>
<strong>after</strong> this patch (bad):
</p>
<pre class="wiki">\phantomsection\label{sage/categories/sets_cat:sage.categories.sets_cat.Sets.WithRealizations.ParentMethods.Realizations}\pysiglinewithargsret{\strong{class }\bfcode{Realizations}}{\emph{parent\_with\_realization}}{}
Bases: {\hyperref[sage/categories/realizations:sage.categories.realizations.Category_realization_of_parent]{\code{sage.categories.realizations.Category\_realization\_of\_parent}}}
</pre>
TicketSimonKingWed, 22 May 2013 19:35:19 GMT
https://trac.sagemath.org/ticket/9107#comment:30
https://trac.sagemath.org/ticket/9107#comment:30
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:29" title="Comment 29">jdemeyer</a>:
</p>
<blockquote class="citation">
<p>
<strong>before</strong> this patch (good):
</p>
<pre class="wiki">\phantomsection\label{sage/categories/sets_cat:sage.categories.sets_cat.Sets.WithRealizations.ParentMethods}\pysigline{\bfcode{ParentMethods}}
alias of \code{WithRealizations.ParentMethods}
</pre><p>
<strong>after</strong> this patch (bad):
</p>
<pre class="wiki">\phantomsection\label{sage/categories/sets_cat:sage.categories.sets_cat.Sets.WithRealizations.ParentMethods.Realizations}\pysiglinewithargsret{\strong{class }\bfcode{Realizations}}{\emph{parent\_with\_realization}}{}
Bases: {\hyperref[sage/categories/realizations:sage.categories.realizations.Category_realization_of_parent]{\code{sage.categories.realizations.Category\_realization\_of\_parent}}}
</pre></blockquote>
<p>
Three questions:
</p>
<ol><li>Why is it bad? I don't see why latex should have a problem with it.
</li><li>Isn't the "good" output without my patch just plain wrong? After all, we do have
<pre class="wiki">sage: sage.categories.sets_cat.Sets.WithRealizations.ParentMethods.Realizations.__bases__
(sage.categories.realizations.Category_realization_of_parent,)
</pre>and also <code>sage.categories.sets_cat.Sets.WithRealizations.ParentMethods.Realizations</code> is certainly <em>not</em> simply an alias of <code>WithRealizations.ParentMethods</code>.
</li><li>Can you also point me to the code that created the latex output?
</li></ol>
TicketjhpalmieriWed, 22 May 2013 22:21:48 GMT
https://trac.sagemath.org/ticket/9107#comment:31
https://trac.sagemath.org/ticket/9107#comment:31
<p>
When I build the pdf docs, it works. On what machine do you see the failure? If it's on sage.math, it might have to do with the fact that the LaTeX installation is quite old...
</p>
<p>
Edit: maybe I'm seeing the failure now. Never mind.
</p>
TicketSimonKingThu, 23 May 2013 05:32:38 GMT
https://trac.sagemath.org/ticket/9107#comment:32
https://trac.sagemath.org/ticket/9107#comment:32
<p>
OK, I see it, too.
</p>
<pre class="wiki">../../sage -docbuild reference pdf
...
Output written on tensor.pdf (24 pages, 144532 bytes).
Transcript written on tensor.log.
Build finished. The built documents can be found in /home/simon/SAGE/prerelease/sage-5.9.rc0/devel/sage/doc/output/pdf/en/reference/tensor
</pre><p>
and then it hangs.
</p>
<p>
Nevertheless, I have no clue what is happening here. See my three questions in <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:30" title="Comment 30">comment:30</a>.
</p>
TicketjdemeyerThu, 23 May 2013 08:03:29 GMT
https://trac.sagemath.org/ticket/9107#comment:33
https://trac.sagemath.org/ticket/9107#comment:33
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:30" title="Comment 30">SimonKing</a>:
</p>
<blockquote class="citation">
<ol><li>Why is it bad?
</li></ol></blockquote>
<p>
I just used "bad" because <code>latex</code> doesn't compile it correctly.
</p>
<blockquote class="citation">
<ol start="3"><li>Can you also point me to the code that created the latex output?
</li></ol></blockquote>
<p>
I guess that's Sphinx, but I don't know much about it.
</p>
TicketSimonKingThu, 23 May 2013 09:35:49 GMT
https://trac.sagemath.org/ticket/9107#comment:34
https://trac.sagemath.org/ticket/9107#comment:34
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:33" title="Comment 33">jdemeyer</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:30" title="Comment 30">SimonKing</a>:
</p>
<blockquote class="citation">
<ol><li>Why is it bad?
</li></ol></blockquote>
<p>
I just used "bad" because <code>latex</code> doesn't compile it correctly.
</p>
</blockquote>
<p>
That was my question: Why does <code>latex</code> not compile it correctly?
</p>
<p>
And we should keep in mind that the old output has simply been wrong.
</p>
TicketjhpalmieriThu, 23 May 2013 19:20:36 GMT
https://trac.sagemath.org/ticket/9107#comment:35
https://trac.sagemath.org/ticket/9107#comment:35
<p>
I think that the first line in the LaTeX error message is correct:
</p>
<pre class="wiki">! LaTeX Error: Too deeply nested.
</pre><p>
I think that there are too many levels of nesting of lists (from the <code>fulllineitems</code> environment). If I comment out the <code>Verbatim</code> environment that it's complaining about, I don't get an error message any more.
</p>
TicketSimonKingThu, 23 May 2013 20:35:57 GMT
https://trac.sagemath.org/ticket/9107#comment:36
https://trac.sagemath.org/ticket/9107#comment:36
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:35" title="Comment 35">jhpalmieri</a>:
</p>
<blockquote class="citation">
<p>
I think that the first line in the LaTeX error message is correct:
</p>
<pre class="wiki">! LaTeX Error: Too deeply nested.
</pre><p>
I think that there are too many levels of nesting of lists (from the <code>fulllineitems</code> environment). If I comment out the <code>Verbatim</code> environment that it's complaining about, I don't get an error message any more.
</p>
</blockquote>
<p>
Please, where is the nesting? I suppose by "comment out the <code>Verbatim</code> environment that it's complaining about", you mean one of two <code>Verbatim</code> environments that were cited in <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:28" title="Comment 28">comment:28</a>.
</p>
<p>
The first is
</p>
<pre class="wiki">\begin{Verbatim}[commandchars=\\\{\}]
\PYG{g+gp}{sage: }\PYG{k+kn}{from} \PYG{n+nn}{sage.categories.realizations} \PYG{k+kn}{import} \PYG{n}{Category\PYGZus{}realization\PYGZus{}of\PYGZus{}parent}
\PYG{g+gp}{sage: }\PYG{n}{A} \PYG{o}{=} \PYG{n}{Sets}\PYG{p}{(}\PYG{p}{)}\PYG{o}{.}\PYG{n}{WithRealizations}\PYG{p}{(}\PYG{p}{)}\PYG{o}{.}\PYG{n}{example}\PYG{p}{(}\PYG{p}{)}\PYG{p}{;} \PYG{n}{A}
\PYG{g+go}{The subset algebra of \PYGZob{}1, 2, 3\PYGZcb{} over Rational Field}
\PYG{g+gp}{sage: }\PYG{n}{C} \PYG{o}{=} \PYG{n}{A}\PYG{o}{.}\PYG{n}{Realizations}\PYG{p}{(}\PYG{p}{)}\PYG{p}{;} \PYG{n}{C}
\PYG{g+go}{Category of realizations of The subset algebra of \PYGZob{}1, 2, 3\PYGZcb{} over Rational Field}
\PYG{g+gp}{sage: }\PYG{n+nb}{isinstance}\PYG{p}{(}\PYG{n}{C}\PYG{p}{,} \PYG{n}{Category\PYGZus{}realization\PYGZus{}of\PYGZus{}parent}\PYG{p}{)}
\PYG{g+go}{True}
\PYG{g+gp}{sage: }\PYG{n}{C}\PYG{o}{.}\PYG{n}{parent\PYGZus{}with\PYGZus{}realization}
\PYG{g+go}{The subset algebra of \PYGZob{}1, 2, 3\PYGZcb{} over Rational Field}
\PYG{g+gp}{sage: }\PYG{n}{TestSuite}\PYG{p}{(}\PYG{n}{C}\PYG{p}{)}\PYG{o}{.}\PYG{n}{run}\PYG{p}{(}\PYG{p}{)}
\end{Verbatim}
</pre><p>
the second is
</p>
<pre class="wiki">\begin{Verbatim}[commandchars=\\\{\}] %% PROBLEM IS THIS LINE %%
\PYG{g+gp}{sage: }\PYG{n}{A} \PYG{o}{=} \PYG{n}{Sets}\PYG{p}{(}\PYG{p}{)}\PYG{o}{.}\PYG{n}{WithRealizations}\PYG{p}{(}\PYG{p}{)}\PYG{o}{.}\PYG{n}{example}\PYG{p}{(}\PYG{p}{)}\PYG{p}{;} \PYG{n}{A}
\PYG{g+go}{The subset algebra of \PYGZob{}1, 2, 3\PYGZcb{} over Rational Field}
\PYG{g+gp}{sage: }\PYG{n}{A}\PYG{o}{.}\PYG{n}{Realizations}\PYG{p}{(}\PYG{p}{)}\PYG{o}{.}\PYG{n}{super\PYGZus{}categories}\PYG{p}{(}\PYG{p}{)}
\PYG{g+go}{[Category of realizations of sets]}
\end{Verbatim}
</pre><p>
I suppose <code>%% PROBLEM IS THIS LINE %%</code> in the second environment was Jeroen's addition.
</p>
<p>
So, what is "too deeply nested"? I can't believe that such a short piece of text has even enough characters to nest too deeply for latex!
</p>
TicketjhpalmieriThu, 23 May 2013 23:25:05 GMT
https://trac.sagemath.org/ticket/9107#comment:37
https://trac.sagemath.org/ticket/9107#comment:37
<p>
If I take the file categories.tex in <code>SAGE_ROOT/devel/sage/doc/output/latex/en/reference/categories/</code> and truncate it just before the line starting <code>\index{facade\_for() ...</code>, then I need to add in a few lines of the form
</p>
<pre class="wiki">\end{fulllineitems}
</pre><p>
to get it to compile (after I comment out the last Verbatim block before the line <code>\index{facade\_for() ...</code>). So there are several <code>fulllineitems</code> environments nested within each other. Maybe too many, and maybe that's the problem. That's my current guess.
</p>
TicketjdemeyerTue, 13 Aug 2013 15:35:53 GMTmilestone changed
https://trac.sagemath.org/ticket/9107#comment:38
https://trac.sagemath.org/ticket/9107#comment:38
<ul>
<li><strong>milestone</strong>
changed from <em>sage-5.11</em> to <em>sage-5.12</em>
</li>
</ul>
TickettscrimThu, 22 Aug 2013 19:13:24 GMT
https://trac.sagemath.org/ticket/9107#comment:39
https://trac.sagemath.org/ticket/9107#comment:39
<p>
Hey Nicolas and Simon,
</p>
<p>
The problem comes from the fact that there is a 4 level deep class nesting with a method (which is 5 levels deep) in the <code>Sets.WithRealizations.ParentMethods.Realizations.super_categories</code>. I've tried moving this subclass into a separate class, and this solves the pdf build issue but introduces some doctesting errors. I don't think there is a to extend the nesting level since that is a latex thing, nor do I think we should try since 4 nested classes is a lot IMO. I'm guessing beforehand because of the improper naming, latex did the environments differently...?
</p>
<p>
Anyways the fix for the pdf build is to remove a level (or two) of class nesting.
</p>
<p>
Best,<br />
Travis
</p>
<p>
Edit: Here are the errors I get when I move <code>Sets.WithRealizations</code> out as a separate class and then assign it into <code>Sets</code>:
</p>
<pre class="wiki">sage -t ../categories/sets_cat.py
**********************************************************************
File "../categories/sets_cat.py", line 1408, in sage.categories.sets_cat.ParentMethodsForWithRealizations.realizations
Failed example:
A.realizations()
Expected:
[The subset algebra of {1, 2, 3} over Rational Field in the Fundamental basis, The subset algebra of {1, 2, 3} over Rational Field in the In basis, The subset algebra of {1, 2, 3} over Rational Field in the Out basis]
Got:
[The subset algebra of {1, 2, 3} over Rational Field in the Fundamental basis, The subset algebra of {1, 2, 3} over Rational Field in the In basis, The subset algebra of {1, 2, 3} over Rational Field in the Out basis, The subset algebra of {1, 2, 3} over Rational Field in the realization Blah]
**********************************************************************
File "../categories/sets_cat.py", line 1428, in sage.categories.sets_cat.ParentMethodsForWithRealizations.facade_for
Failed example:
A.facade_for()
Expected:
[The subset algebra of {1, 2, 3} over Rational Field in the Fundamental basis, The subset algebra of {1, 2, 3} over Rational Field in the In basis, The subset algebra of {1, 2, 3} over Rational Field in the Out basis]
Got:
[The subset algebra of {1, 2, 3} over Rational Field in the Fundamental basis, The subset algebra of {1, 2, 3} over Rational Field in the In basis, The subset algebra of {1, 2, 3} over Rational Field in the Out basis, The subset algebra of {1, 2, 3} over Rational Field in the realization Blah]
**********************************************************************
2 items had failures:
1 of 8 in sage.categories.sets_cat.ParentMethodsForWithRealizations.facade_for
1 of 3 in sage.categories.sets_cat.ParentMethodsForWithRealizations.realizations
[241 tests, 2 failures, 0.76 s]
----------------------------------------------------------------------
sage -t ../categories/sets_cat.py # 2 doctests failed
----------------------------------------------------------------------
</pre><p>
Any ideas why moving the class out of the nesting doesn't work?
</p>
TicketSimonKingThu, 22 Aug 2013 19:27:35 GMT
https://trac.sagemath.org/ticket/9107#comment:40
https://trac.sagemath.org/ticket/9107#comment:40
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:39" title="Comment 39">tscrim</a>:
</p>
<blockquote class="citation">
<p>
I don't think there is a to extend the nesting level since that is a latex thing,
</p>
</blockquote>
<p>
Shame on LaTeX!
</p>
<blockquote class="citation">
<p>
Anyways the fix for the pdf build is to remove a level (or two) of class nesting.
</p>
</blockquote>
<p>
What exactly are we talking about? <code>Sets.WithRealizations.ParentMethods.Realizations</code>?
</p>
<p>
Interestingly, there is the comment
</p>
<pre class="wiki"># Do we really want this feature?
</pre><p>
So, can we do without this feature? Nicolas?
</p>
TickettscrimFri, 23 Aug 2013 04:02:07 GMT
https://trac.sagemath.org/ticket/9107#comment:41
https://trac.sagemath.org/ticket/9107#comment:41
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:40" title="Comment 40">SimonKing</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:39" title="Comment 39">tscrim</a>:
</p>
<blockquote class="citation">
<p>
Anyways the fix for the pdf build is to remove a level (or two) of class nesting.
</p>
</blockquote>
<p>
What exactly are we talking about? <code>Sets.WithRealizations.ParentMethods.Realizations</code>?
</p>
</blockquote>
<p>
Yes. Removing a level of nesting allowed the pdf for categories to build for me.
</p>
TicketnthieryFri, 23 Aug 2013 08:52:45 GMT
https://trac.sagemath.org/ticket/9107#comment:42
https://trac.sagemath.org/ticket/9107#comment:42
<p>
Thanks much Travis for investigating!
</p>
<p>
I agree that there should be a recommendation for not nesting classes
too deep, for the sake of readability. But having a hard arbitrary
limit -- especially that small -- is annoying. Shame on LaTeX. Of
course, one can always spin off a subtree of nested classes into a
separate tree, but there are cases where one has a deep tree with very
few lines and no natural splitting point. For example, <a class="closed ticket" href="https://trac.sagemath.org/ticket/10963" title="enhancement: Axioms and more functorial constructions (closed: fixed)">#10963</a>
introduces
</p>
<pre class="wiki"> DistributiveMagmasAndAdditiveMagmas.AdditiveAssociative.AdditiveCommutative.AdditiveUnital.AdditiveInverse
</pre><p>
Hmm. Altogether, I would call this a LaTeX arbitrary hard
limitation. Luckily there seems to be an easy solution to increase
this limitation to something large enough to cover our current use
cases, namely to use the package enumitem [1]. By itself, it brings
the nesting level to 6, and we could even increase it further (10
should be really safe) using \setlistdepth<a class="report" href="https://trac.sagemath.org/report/9">{9}</a>.
</p>
<p>
I have attached the little latex file I used for testing.
</p>
<p>
What do you think? Shall we add enumitems to the list of latex
packages loaded by Sphinx? Is this standard enough, or shall we add
enumitem.sty to the Sage distribution?
</p>
<p>
Cheers,
</p>
<blockquote>
<p>
Nicolas
</p>
</blockquote>
<p>
[1] <a class="ext-link" href="http://stackoverflow.com/questions/1935952/maximum-nesting-level-of-lists-in-latex"><span class="icon"></span>http://stackoverflow.com/questions/1935952/maximum-nesting-level-of-lists-in-latex</a>
</p>
TicketnthieryFri, 23 Aug 2013 08:53:11 GMTattachment set
https://trac.sagemath.org/ticket/9107
https://trac.sagemath.org/ticket/9107
<ul>
<li><strong>attachment</strong>
set to <em>test-deep-itemize-nesting.tex</em>
</li>
</ul>
TicketjdemeyerFri, 23 Aug 2013 09:02:52 GMT
https://trac.sagemath.org/ticket/9107#comment:43
https://trac.sagemath.org/ticket/9107#comment:43
<p>
<code>enumitem.sty</code> looks pretty standard, so I'd say it's fine to use it.
</p>
TicketSimonKingFri, 23 Aug 2013 10:31:04 GMT
https://trac.sagemath.org/ticket/9107#comment:44
https://trac.sagemath.org/ticket/9107#comment:44
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:43" title="Comment 43">jdemeyer</a>:
</p>
<blockquote class="citation">
<p>
<code>enumitem.sty</code> looks pretty standard, so I'd say it's fine to use it.
</p>
</blockquote>
<p>
... which means there should be a separate ticket for adding it?
</p>
TicketjdemeyerFri, 23 Aug 2013 11:28:29 GMT
https://trac.sagemath.org/ticket/9107#comment:45
https://trac.sagemath.org/ticket/9107#comment:45
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:44" title="Comment 44">SimonKing</a>:
</p>
<blockquote class="citation">
<p>
... which means there should be a separate ticket for adding it?
</p>
</blockquote>
<p>
Adding an <code>\usepackage{}</code> somewhere (don't ask me where) should be trivial enough that it can be done on this ticket.
</p>
TicketSimonKingFri, 23 Aug 2013 11:55:58 GMT
https://trac.sagemath.org/ticket/9107#comment:46
https://trac.sagemath.org/ticket/9107#comment:46
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:45" title="Comment 45">jdemeyer</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:44" title="Comment 44">SimonKing</a>:
</p>
<blockquote class="citation">
<p>
... which means there should be a separate ticket for adding it?
</p>
</blockquote>
<p>
Adding an <code>\usepackage{}</code> somewhere (don't ask me where) should be trivial enough that it can be done on this ticket.
</p>
</blockquote>
<p>
So, whom *do* we ask?
</p>
TickettscrimFri, 23 Aug 2013 15:31:26 GMT
https://trac.sagemath.org/ticket/9107#comment:47
https://trac.sagemath.org/ticket/9107#comment:47
<p>
Me; I just did this with Ben on <a class="closed ticket" href="https://trac.sagemath.org/ticket/14787" title="enhancement: Statistics on generalized Young walls (closed: fixed)">#14787</a>. You need to add it to <code>doc/common/conf.py</code>, and we also added it to <code>misc/latex.py</code>, which might be some overkill, but it doesn't really hurt to be extra safe here.
</p>
TicketSimonKingFri, 23 Aug 2013 19:39:18 GMT
https://trac.sagemath.org/ticket/9107#comment:48
https://trac.sagemath.org/ticket/9107#comment:48
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:47" title="Comment 47">tscrim</a>:
</p>
<blockquote class="citation">
<p>
Me; I just did this with Ben on <a class="closed ticket" href="https://trac.sagemath.org/ticket/14787" title="enhancement: Statistics on generalized Young walls (closed: fixed)">#14787</a>. You need to add it to <code>doc/common/conf.py</code>, and we also added it to <code>misc/latex.py</code>, which might be some overkill, but it doesn't really hurt to be extra safe here.
</p>
</blockquote>
<p>
Are you saying that the problem is fixed by <a class="closed ticket" href="https://trac.sagemath.org/ticket/14787" title="enhancement: Statistics on generalized Young walls (closed: fixed)">#14787</a>? Then I suggest to add it as dependency.
</p>
TickettscrimFri, 23 Aug 2013 23:44:41 GMT
https://trac.sagemath.org/ticket/9107#comment:49
https://trac.sagemath.org/ticket/9107#comment:49
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:48" title="Comment 48">SimonKing</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:47" title="Comment 47">tscrim</a>:
</p>
<blockquote class="citation">
<p>
Me; I just did this with Ben on <a class="closed ticket" href="https://trac.sagemath.org/ticket/14787" title="enhancement: Statistics on generalized Young walls (closed: fixed)">#14787</a>. You need to add it to <code>doc/common/conf.py</code>, and we also added it to <code>misc/latex.py</code>, which might be some overkill, but it doesn't really hurt to be extra safe here.
</p>
</blockquote>
<p>
Are you saying that the problem is fixed by <a class="closed ticket" href="https://trac.sagemath.org/ticket/14787" title="enhancement: Statistics on generalized Young walls (closed: fixed)">#14787</a>? Then I suggest to add it as dependency.
</p>
</blockquote>
<p>
Sorry, that was phrased badly. Ben and I added a latex package to the pdf builder in <a class="closed ticket" href="https://trac.sagemath.org/ticket/14787" title="enhancement: Statistics on generalized Young walls (closed: fixed)">#14787</a>, but it was not <code>enumitem.sty</code>.
</p>
TicketzabrockiMon, 26 Aug 2013 21:16:07 GMTcc changed
https://trac.sagemath.org/ticket/9107#comment:50
https://trac.sagemath.org/ticket/9107#comment:50
<ul>
<li><strong>cc</strong>
<em>zabrocki</em> added
</li>
</ul>
TicketnthieryTue, 27 Aug 2013 11:04:52 GMT
https://trac.sagemath.org/ticket/9107#comment:51
https://trac.sagemath.org/ticket/9107#comment:51
<p>
For the record: someone else got a similar issue when using sphinx [1], and suggested the same fix. Alas this fix does not seem to be enough. I am still getting a "Too deeply nested" with the attached file categories.tex (obtained by reducing that produced by sphinx). I am working on reducing it further.
</p>
<p>
[1] <a class="ext-link" href="http://mail.scipy.org/pipermail/ipython-user/2012-May/010144.html"><span class="icon"></span>http://mail.scipy.org/pipermail/ipython-user/2012-May/010144.html</a>
</p>
TicketnthieryTue, 27 Aug 2013 11:05:54 GMTattachment set
https://trac.sagemath.org/ticket/9107
https://trac.sagemath.org/ticket/9107
<ul>
<li><strong>attachment</strong>
set to <em>categories.tex</em>
</li>
</ul>
TicketSimonKingTue, 27 Aug 2013 11:11:36 GMT
https://trac.sagemath.org/ticket/9107#comment:52
https://trac.sagemath.org/ticket/9107#comment:52
<p>
Hi Nicolas,
</p>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:51" title="Comment 51">nthiery</a>:
</p>
<blockquote class="citation">
<p>
For the record: someone else got a similar issue when using sphinx [1], and suggested the same fix. Alas this fix does not seem to be enough.
</p>
</blockquote>
<p>
What exactly did you do? Change sphinx.sty, as in the source you are giving? Or change doc/common/conf.py and misc/latex.py, as advised by Travis in <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:47" title="Comment 47">comment:47</a>?
</p>
<p>
Could it be that the following comment from <a class="ext-link" href="http://mail.scipy.org/pipermail/ipython-user/2012-May/010144.html"><span class="icon"></span>the page you are citing</a> applies?
</p>
<pre class="wiki">However this requires version 3.0 of enumitem, which doesn't yet ship
with many linux latex distributions.
</pre>
TicketnthieryTue, 27 Aug 2013 12:36:17 GMT
https://trac.sagemath.org/ticket/9107#comment:53
https://trac.sagemath.org/ticket/9107#comment:53
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:52" title="Comment 52">SimonKing</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:51" title="Comment 51">nthiery</a>:
</p>
<blockquote class="citation">
<p>
For the record: someone else got a similar issue when using sphinx [1], and suggested the same fix. Alas this fix does not seem to be enough.
</p>
</blockquote>
<p>
What exactly did you do? Change sphinx.sty, as in the source you are giving? Or change doc/common/conf.py and misc/latex.py, as advised by Travis in <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:47" title="Comment 47">comment:47</a>?
</p>
</blockquote>
<p>
I changed conf.py which properly added it to the generated
categories.tex file (see the top of that file).
</p>
<blockquote class="citation">
<p>
Could it be that the following comment from <a class="ext-link" href="http://mail.scipy.org/pipermail/ipython-user/2012-May/010144.html"><span class="icon"></span>the page you are citing</a> applies?
</p>
<pre class="wiki">However this requires version 3.0 of enumitem, which doesn't yet ship
with many linux latex distributions.
</pre></blockquote>
<p>
I have 3.5.2 ...
</p>
TicketSimonKingTue, 27 Aug 2013 12:53:53 GMT
https://trac.sagemath.org/ticket/9107#comment:54
https://trac.sagemath.org/ticket/9107#comment:54
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:53" title="Comment 53">nthiery</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:52" title="Comment 52">SimonKing</a>:
</p>
<blockquote class="citation">
<p>
What exactly did you do? Change sphinx.sty, as in the source you are giving? Or change doc/common/conf.py and misc/latex.py, as advised by Travis in <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:47" title="Comment 47">comment:47</a>?
</p>
</blockquote>
<p>
I changed conf.py which properly added it to the generated
categories.tex file (see the top of that file).
</p>
</blockquote>
<p>
Hm. Then, we are back to the question: What the heck is going wrong? Could we
perhaps ask on some <code>LaTeX</code> forum about the problem? I mean, if we have a tex
file that does not compile, even though nesting should not be the problem any
more, then I think <code>LaTeX</code> people should be made aware.
</p>
TicketSimonKingTue, 27 Aug 2013 12:56:29 GMT
https://trac.sagemath.org/ticket/9107#comment:55
https://trac.sagemath.org/ticket/9107#comment:55
<p>
How can one test <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/9107/categories.tex" title="Attachment 'categories.tex' in Ticket #9107">categories.tex</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/9107/categories.tex" title="Download"></a>? I can not run pdflatex on it, because it can't find <code>sphinxmanual.cls</code>. Where do I get this file (and probably other files) from?
</p>
TicketSimonKingTue, 27 Aug 2013 14:55:09 GMT
https://trac.sagemath.org/ticket/9107#comment:56
https://trac.sagemath.org/ticket/9107#comment:56
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:55" title="Comment 55">SimonKing</a>:
</p>
<blockquote class="citation">
<p>
How can one test <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/9107/categories.tex" title="Attachment 'categories.tex' in Ticket #9107">categories.tex</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/9107/categories.tex" title="Download"></a>? I can not run pdflatex on it, because it can't find <code>sphinxmanual.cls</code>. Where do I get this file (and probably other files) from?
</p>
</blockquote>
<p>
When I do <code>declare -x TEXINPUTS=.:$SAGE_ROOT/local/lib/python2.7/site-packages/Sphinx-1.1.2-py2.7.egg/sphinx/texinputs/</code> then it does find sphinxmanual.cls, but the next attempt to call pdflatex on categories.tex fails as well. This time, it can't find <code>report.cls</code>.
</p>
<p>
So, please tell me how one is supposed to run pdflatex on this file, so that I can reproduce the problem.
</p>
TicketnthieryWed, 28 Aug 2013 09:23:49 GMT
https://trac.sagemath.org/ticket/9107#comment:57
https://trac.sagemath.org/ticket/9107#comment:57
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:56" title="Comment 56">SimonKing</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:55" title="Comment 55">SimonKing</a>:
</p>
<blockquote class="citation">
<p>
How can one test <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/9107/categories.tex" title="Attachment 'categories.tex' in Ticket #9107">categories.tex</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/9107/categories.tex" title="Download"></a>? I can not run pdflatex on it, because it can't find <code>sphinxmanual.cls</code>. Where do I get this file (and probably other files) from?
</p>
</blockquote>
</blockquote>
<blockquote class="citation">
<p>
When I do <code>declare -x TEXINPUTS=.:$SAGE_ROOT/local/lib/python2.7/site-packages/Sphinx-1.1.2-py2.7.egg/sphinx/texinputs/</code> then it does find sphinxmanual.cls, but the next attempt to call pdflatex on categories.tex fails as well. This time, it can't find <code>report.cls</code>.
</p>
</blockquote>
<p>
You are missing a : at the end of TEXINPUT to let latex use its own library (report.cls is a standard class).
</p>
<p>
Or you can just be lazy and put the categories.tex file in the directory
</p>
<pre class="wiki"> <SAGE>/devel/sage/doc/output/latex/en/reference/categories
</pre><p>
and run pdflatex from there.
</p>
TicketSimonKingWed, 28 Aug 2013 09:43:54 GMT
https://trac.sagemath.org/ticket/9107#comment:58
https://trac.sagemath.org/ticket/9107#comment:58
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:57" title="Comment 57">nthiery</a>:
</p>
<blockquote class="citation">
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:56" title="Comment 56">SimonKing</a>:
</p>
<blockquote class="citation">
<p>
When I do <code>declare -x TEXINPUTS=.:$SAGE_ROOT/local/lib/python2.7/site-packages/Sphinx-1.1.2-py2.7.egg/sphinx/texinputs/</code> then it does find sphinxmanual.cls, but the next attempt to call pdflatex on categories.tex fails as well. This time, it can't find <code>report.cls</code>.
</p>
</blockquote>
<p>
You are missing a : at the end of TEXINPUT to let latex use its own library (report.cls is a standard class).
</p>
</blockquote>
<p>
Nope. After
</p>
<pre class="wiki">declare -x TEXINPUTS=.:~/SAGE/prerelease/sage-5.11.beta3/local/lib/python2.7/site-packages/Sphinx-1.1.2-py2.7.egg/sphinx/texinputs/:
</pre><p>
<code>pdflatex categories.tex</code> results in
</p>
<pre class="wiki">! Undefined control sequence.
<recently read> \setlistdepth
l.19 \setlistdepth
{9}
?
! Emergency stop.
<recently read> \setlistdepth
l.19 \setlistdepth
{9}
! ==> Fatal error occurred, no output PDF file produced!
</pre><blockquote class="citation">
<p>
Or you can just be lazy and put the categories.tex file in the directory
</p>
<pre class="wiki"> <SAGE>/devel/sage/doc/output/latex/en/reference/categories
</pre><p>
and run pdflatex from there.
</p>
</blockquote>
<p>
Nope, because this folder doesn't exist. Do I need to attempt building the pdf documentation first?
</p>
TicketSimonKingWed, 28 Aug 2013 09:45:45 GMT
https://trac.sagemath.org/ticket/9107#comment:59
https://trac.sagemath.org/ticket/9107#comment:59
<p>
PS: Changing
</p>
<pre class="wiki">\RequirePackage{enumitem}
</pre><p>
into
</p>
<pre class="wiki">\usepackage{enumitem}
</pre><p>
did not help.
</p>
TicketSimonKingWed, 28 Aug 2013 10:24:17 GMT
https://trac.sagemath.org/ticket/9107#comment:60
https://trac.sagemath.org/ticket/9107#comment:60
<p>
Aha. The log shows:
</p>
<pre class="wiki">enumitem 2009/05/18 v2.2 Customized lists
</pre><p>
and I guess that's too old.
</p>
TicketSimonKingWed, 28 Aug 2013 10:41:56 GMT
https://trac.sagemath.org/ticket/9107#comment:61
https://trac.sagemath.org/ticket/9107#comment:61
<p>
OK, after getting a more recent version of the enumitem package, I first get a "too deeply nested" error on <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/9107/categories.tex" title="Attachment 'categories.tex' in Ticket #9107">categories.tex</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/9107/categories.tex" title="Download"></a>. However, after doing
</p>
<pre class="wiki">\setlistdepth{10}
</pre><p>
(and not just depth 9), it compiles fine.
</p>
<p>
So, in other words, the problem <em>can</em> be solved. But I really wonder about the requirement that the user has to have a latex installation with a very recent enumitem. Can this be really required? Or would we be allowed to ship enumitem.sty with Sage?
</p>
TicketSimonKingWed, 28 Aug 2013 10:44:29 GMTattachment set
https://trac.sagemath.org/ticket/9107
https://trac.sagemath.org/ticket/9107
<ul>
<li><strong>attachment</strong>
set to <em>categories.pdf</em>
</li>
</ul>
<p>
Output of pdflatex after doing setlistdept(10) in categories.tex
</p>
TicketSimonKingWed, 28 Aug 2013 10:45:27 GMT
https://trac.sagemath.org/ticket/9107#comment:62
https://trac.sagemath.org/ticket/9107#comment:62
<p>
Well, it does compile, but it does not work. Look at the ugly output in <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/9107/categories.pdf" title="Attachment 'categories.pdf' in Ticket #9107">categories.pdf</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/9107/categories.pdf" title="Download"></a>.
</p>
TicketnthieryWed, 28 Aug 2013 12:54:14 GMT
https://trac.sagemath.org/ticket/9107#comment:63
https://trac.sagemath.org/ticket/9107#comment:63
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:61" title="Comment 61">SimonKing</a>:
</p>
<blockquote class="citation">
<p>
OK, after getting a more recent version of the enumitem package, I first get a "too deeply nested" error on <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/9107/categories.tex" title="Attachment 'categories.tex' in Ticket #9107">categories.tex</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/9107/categories.tex" title="Download"></a>. However, after doing
</p>
<pre class="wiki">\setlistdepth{10}
</pre><p>
(and not just depth 9), it compiles fine.
So, in other words, the problem <em>can</em> be solved.
</p>
</blockquote>
<p>
What? Really? I thought I had tried that. Ah, I see, the level that
you have to put seems to actually have nothing to do with the actual
depth of your itemize. Now I can compile the full categories
documentation, but that requires <code>\setlistdepth{275</code>}!!! There
must be something wrong in the depth-counting logic of enumitem ...
</p>
<blockquote class="citation">
<p>
But I really wonder about the requirement that the user has to have
a latex installation with a very recent enumitem. Can this be really
required? Or would we be allowed to ship enumitem.sty with Sage?
</p>
</blockquote>
<p>
I would vote for shipping enumitem.sty if that's easy. <a class="missing wiki">Jeroen/Volker/?</a>..., can we just throw it in
<code>/opt/sage-dev/local/share/texmf/tex/generic</code> ?
</p>
<p>
Cheers,
</p>
<blockquote>
<p>
Nicolas
</p>
</blockquote>
TicketnthieryWed, 28 Aug 2013 12:59:17 GMT
https://trac.sagemath.org/ticket/9107#comment:64
https://trac.sagemath.org/ticket/9107#comment:64
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:62" title="Comment 62">SimonKing</a>:
</p>
<blockquote class="citation">
<p>
Well, it does compile, but it does not work. Look at the ugly output in <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/9107/categories.pdf" title="Attachment 'categories.pdf' in Ticket #9107">categories.pdf</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/9107/categories.pdf" title="Download"></a>.
</p>
</blockquote>
<p>
Nothing to worry about: this filed was obtained by stripping lots of stuff from an actual tex file; I am not surprised it does not look good. On the other hand, I had a look at the full categories.pdf produced by sphinx, and it looked reasonable.
</p>
TicketSimonKingWed, 28 Aug 2013 13:06:04 GMT
https://trac.sagemath.org/ticket/9107#comment:65
https://trac.sagemath.org/ticket/9107#comment:65
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:63" title="Comment 63">nthiery</a>:
</p>
<blockquote class="citation">
<p>
Now I can compile the full categories
documentation, but that requires <code>\setlistdepth{275</code>}!!! There
must be something wrong in the depth-counting logic of enumitem ...
</p>
</blockquote>
<p>
Ouch. So, if it really turns out that the depth-counting is broken (did you check that the nesting of lists in the created tex file are not broken?), then we should perhaps consider to search for an alternative solution.
</p>
<p>
For example, is it really needed to use nesting in the resulting tex file? Or could one create a nice layout without nesting? If I understand correctly, <em>we</em> (i.e., Sage) are creating the tex file. Hence, we can control what happens.
</p>
<blockquote class="citation">
<p>
I would vote for shipping enumitem.sty if that's easy. <a class="missing wiki">Jeroen/Volker/?</a>..., can we just throw it in
<code>/opt/sage-dev/local/share/texmf/tex/generic</code> ?
</p>
</blockquote>
<p>
I have already asked on <a class="ext-link" href="https://groups.google.com/forum/#!topic/sage-devel/8Q-I0e2OESE"><span class="icon"></span>sage-devel</a>...
</p>
TicketnthieryThu, 29 Aug 2013 16:14:35 GMT
https://trac.sagemath.org/ticket/9107#comment:66
https://trac.sagemath.org/ticket/9107#comment:66
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:65" title="Comment 65">SimonKing</a>:
</p>
<blockquote class="citation">
<p>
I have already asked on <a class="ext-link" href="https://groups.google.com/forum/#!topic/sage-devel/8Q-I0e2OESE"><span class="icon"></span>sage-devel</a>...
</p>
</blockquote>
<p>
Thanks for the pointer. I answered there.
</p>
Ticketvbraun_spamThu, 30 Jan 2014 21:20:52 GMTmilestone changed
https://trac.sagemath.org/ticket/9107#comment:67
https://trac.sagemath.org/ticket/9107#comment:67
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.1</em> to <em>sage-6.2</em>
</li>
</ul>
Ticketvbraun_spamTue, 06 May 2014 15:20:58 GMTmilestone changed
https://trac.sagemath.org/ticket/9107#comment:68
https://trac.sagemath.org/ticket/9107#comment:68
<ul>
<li><strong>milestone</strong>
changed from <em>sage-6.2</em> to <em>sage-6.3</em>
</li>
</ul>
TicketvbraunThu, 12 Jun 2014 14:01:04 GMT
https://trac.sagemath.org/ticket/9107#comment:69
https://trac.sagemath.org/ticket/9107#comment:69
<p>
Just require enumitems, geez... Afair we already require a number of packages that are not part of a "small"/"medium" TeXLive install. One more doesn't make a difference.
</p>
TicketnthieryThu, 12 Jun 2014 14:54:14 GMTbranch set
https://trac.sagemath.org/ticket/9107#comment:70
https://trac.sagemath.org/ticket/9107#comment:70
<ul>
<li><strong>branch</strong>
set to <em>u/nthiery/nested_class_name_mangling_can_be_wrong_in_case_of_double_nesting</em>
</li>
</ul>
TicketnthieryThu, 12 Jun 2014 14:55:47 GMTbranch deleted
https://trac.sagemath.org/ticket/9107#comment:71
https://trac.sagemath.org/ticket/9107#comment:71
<ul>
<li><strong>branch</strong>
<em>u/nthiery/nested_class_name_mangling_can_be_wrong_in_case_of_double_nesting</em> deleted
</li>
</ul>
<p>
Yeah, you are right, let's make it simple. I for example had to install a bunch of language packages (russian, ...) to get the pdf doc to install a couple days ago.
</p>
<p>
First attempt pushed. Compiling the doc and running the tests now.
</p>
<p>
Cheers,
</p>
<blockquote>
<p>
Nicolas
</p>
</blockquote>
TicketSimonKingThu, 12 Jun 2014 15:54:38 GMT
https://trac.sagemath.org/ticket/9107#comment:72
https://trac.sagemath.org/ticket/9107#comment:72
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:69" title="Comment 69">vbraun</a>:
</p>
<blockquote class="citation">
<p>
Just require enumitems, geez...
</p>
</blockquote>
<p>
What exactly do you mean? Would it be sufficient to let Sage insert <code>usepackage{enumitem}</code> (I have not heard about the plural, <code>enumitems</code>), or will we also need to change the latex code emitted for nested classes? And how?
</p>
TicketnthieryThu, 12 Jun 2014 21:50:49 GMT
https://trac.sagemath.org/ticket/9107#comment:73
https://trac.sagemath.org/ticket/9107#comment:73
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:72" title="Comment 72">SimonKing</a>:
</p>
<blockquote class="citation">
<p>
What exactly do you mean? Would it be sufficient to let Sage insert <code>usepackage{enumitem}</code>
</p>
</blockquote>
<p>
That's my understanding and what I did in my latest commit. Plus raising the depth limit to a stupidly high value.
</p>
<p>
There seems to still be some compilation issue, but I guess they are just due to more stuff getting compiled, hence catching glitches that had gone unnoticed so far. I'll check this out tomorrow.
</p>
<p>
Cheers,
</p>
<blockquote>
<p>
Nicolas
</p>
</blockquote>
TicketnthieryFri, 13 Jun 2014 09:18:06 GMTbranch set
https://trac.sagemath.org/ticket/9107#comment:74
https://trac.sagemath.org/ticket/9107#comment:74
<ul>
<li><strong>branch</strong>
set to <em>u/nthiery/nested_class_name_mangling_can_be_wrong_in_case_of_double_nesting</em>
</li>
</ul>
TicketnthieryFri, 13 Jun 2014 09:24:44 GMTcommit set
https://trac.sagemath.org/ticket/9107#comment:75
https://trac.sagemath.org/ticket/9107#comment:75
<ul>
<li><strong>commit</strong>
set to <em>891c3fad654e89e6b96bcf8f79114f631c8b7bba</em>
</li>
</ul>
<p>
Gosh, it turned out that using <code>\setlistdepth{275}</code> was not sufficient
anymore: I had to use <code>\setlistdepth{2000}</code>! This meant the problem
would just keep going to be worst and worst with time.
</p>
<p>
So I investigated a further and got lucky this time: if we replace
list by trivlist in the customized Verbatim defined by <code>sphinx.sty</code>,
then our documenation compiles smoothly, without even using enumitem.
</p>
<p>
I proposed this fix upstream:
</p>
<p>
<a class="ext-link" href="https://bitbucket.org/birkenfeld/sphinx/issue/777/latex-output-too-deeply-nested"><span class="icon"></span>https://bitbucket.org/birkenfeld/sphinx/issue/777/latex-output-too-deeply-nested</a>
</p>
<p>
For the time being, I tweaked our conf.py to redefine and fix sphinx's
Verbatim.
</p>
<p>
Ok, now there just remains to check that all tests pass, and this will
be a needs review.
</p>
<p>
Cheers,
</p>
<blockquote>
<p>
Nicolas
</p>
</blockquote>
<hr />
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=727bd6a3ce1c577295a5fd421c257ae89618e989"><span class="icon"></span>727bd6a</a></td><td><code>#9107: Enable nesting of a nested class into a nested class</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=213e3b1a612b7e34933432fdd01d0d3f61fe7016"><span class="icon"></span>213e3b1</a></td><td><code>#9107: Fix one cross reference in the documentation of a functorial construction</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=66b7e72505a6683f246535083f071a3963b11104"><span class="icon"></span>66b7e72</a></td><td><code>#9107: fix a docstring (missing example and raw)</code>
</td></tr><tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=891c3fad654e89e6b96bcf8f79114f631c8b7bba"><span class="icon"></span>891c3fa</a></td><td><code>#9107: monkey patch a fix for deeply nested pdflatex compilation error until it's merged upstream (Sphinx #777)</code>
</td></tr></table>
TickettscrimFri, 13 Jun 2014 16:52:40 GMT
https://trac.sagemath.org/ticket/9107#comment:76
https://trac.sagemath.org/ticket/9107#comment:76
<p>
Is there a reason why you don't patch the sphinx spkg directly?
</p>
TicketnthieryFri, 13 Jun 2014 19:35:15 GMT
https://trac.sagemath.org/ticket/9107#comment:77
https://trac.sagemath.org/ticket/9107#comment:77
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:76" title="Comment 76">tscrim</a>:
</p>
<blockquote class="citation">
<p>
Is there a reason why you don't patch the sphinx spkg directly?
</p>
</blockquote>
<p>
Lazyness mostly. If someone whats to create a patch, adapt the spkg, ... please go ahead!
</p>
TicketgitFri, 13 Jun 2014 19:43:01 GMTcommit changed
https://trac.sagemath.org/ticket/9107#comment:78
https://trac.sagemath.org/ticket/9107#comment:78
<ul>
<li><strong>commit</strong>
changed from <em>891c3fad654e89e6b96bcf8f79114f631c8b7bba</em> to <em>ed2c7047aab14dce0abbf22eb531fa0667179982</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=ed2c7047aab14dce0abbf22eb531fa0667179982"><span class="icon"></span>ed2c704</a></td><td><code>#9107: updated doctests now that the name of deeply nested classes is finaly correct</code>
</td></tr></table>
TicketnthieryFri, 13 Jun 2014 19:44:51 GMTstatus changed
https://trac.sagemath.org/ticket/9107#comment:79
https://trac.sagemath.org/ticket/9107#comment:79
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
Ok, there were a couple doctest failures, all to be expected since nested classes now have a correct name. Fixed now. So that's a needs review!
</p>
TickettscrimFri, 13 Jun 2014 21:05:26 GMTcommit, branch changed
https://trac.sagemath.org/ticket/9107#comment:80
https://trac.sagemath.org/ticket/9107#comment:80
<ul>
<li><strong>commit</strong>
changed from <em>ed2c7047aab14dce0abbf22eb531fa0667179982</em> to <em>d6b432b24b3f1fbfc5298fe096a13e095dda8b1f</em>
</li>
<li><strong>branch</strong>
changed from <em>u/nthiery/nested_class_name_mangling_can_be_wrong_in_case_of_double_nesting</em> to <em>public/nested_class-9107</em>
</li>
</ul>
<p>
Here's a version with a patched version of the sphinx spkg. Although I think your pull request is based on v1.2 (but it still applied (for me) to our current v1.1). Could someone check to make sure I created the patch correctly (and tell me what I should do instead if it isn't right).
</p>
<hr />
<p>
New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=d6b432b24b3f1fbfc5298fe096a13e095dda8b1f"><span class="icon"></span>d6b432b</a></td><td><code>Moved hack conf.py to proper patch.</code>
</td></tr></table>
TicketgitMon, 16 Jun 2014 19:57:32 GMTcommit changed
https://trac.sagemath.org/ticket/9107#comment:81
https://trac.sagemath.org/ticket/9107#comment:81
<ul>
<li><strong>commit</strong>
changed from <em>d6b432b24b3f1fbfc5298fe096a13e095dda8b1f</em> to <em>8b14e051c933f2ec2ae9891efbf329e7f0f2cba4</em>
</li>
</ul>
<p>
Branch pushed to git repo; I updated commit sha1. New commits:
</p>
<table class="wiki">
<tr><td><a class="ext-link" href="http://git.sagemath.org/sage.git/commit/?id=8b14e051c933f2ec2ae9891efbf329e7f0f2cba4"><span class="icon"></span>8b14e05</a></td><td><code>#9107: improved description of Sphinx's patch nested.patch</code>
</td></tr></table>
TicketnthieryMon, 16 Jun 2014 20:03:36 GMT
https://trac.sagemath.org/ticket/9107#comment:82
https://trac.sagemath.org/ticket/9107#comment:82
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:80" title="Comment 80">tscrim</a>:
</p>
<blockquote class="citation">
<p>
Here's a version with a patched version of the sphinx spkg.
</p>
</blockquote>
<p>
Ah, that's nice: modifying standard spkgs is much simpler now that we have a single repository. Thanks!
</p>
<blockquote class="citation">
<p>
Although I think your pull request is based on v1.2 (but it still applied (for me) to our current v1.1). Could someone check to make sure I created the patch correctly (and tell me what I should do instead if it isn't right).
</p>
</blockquote>
<p>
It seems to apply as it's supposed to (modulo trivial line offset).
</p>
<p>
I have made some minor improvement to the patch description.
</p>
<p>
I am a bit nervous about the removal of the former change log in SPKG.txt. But if someone can confirm that this is the right thing to do, that's ok for me.
</p>
<p>
Other than this, this sounds good to go!
</p>
<p>
Thanks again,
</p>
<blockquote>
<p>
Nicolas
</p>
</blockquote>
TicketvbraunMon, 16 Jun 2014 21:02:55 GMT
https://trac.sagemath.org/ticket/9107#comment:83
https://trac.sagemath.org/ticket/9107#comment:83
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9107#comment:82" title="Comment 82">nthiery</a>:
</p>
<blockquote class="citation">
<p>
I am a bit nervous about the removal of the former change log in SPKG.txt. But if someone can confirm that this is the right thing to do, that's ok for me.
</p>
</blockquote>
<p>
Do it! ;-)
</p>
TickettscrimTue, 17 Jun 2014 02:03:46 GMTstatus, reviewer, author changed
https://trac.sagemath.org/ticket/9107#comment:84
https://trac.sagemath.org/ticket/9107#comment:84
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
<li><strong>reviewer</strong>
changed from <em>Volker Braun, Florent Hivert</em> to <em>Volker Braun, Florent Hivert, Travis Scrimshaw</em>
</li>
<li><strong>author</strong>
changed from <em>Simon King</em> to <em>Simon King, Nicolas M. Thiéry</em>
</li>
</ul>
<p>
Then away we go.
</p>
TicketncohenWed, 18 Jun 2014 12:39:16 GMT
https://trac.sagemath.org/ticket/9107#comment:85
https://trac.sagemath.org/ticket/9107#comment:85
<p>
Thanks for fixing this !!!
</p>
TicketvbraunWed, 18 Jun 2014 14:11:28 GMTstatus, branch changed; resolution set
https://trac.sagemath.org/ticket/9107#comment:86
https://trac.sagemath.org/ticket/9107#comment:86
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
<li><strong>branch</strong>
changed from <em>public/nested_class-9107</em> to <em>8b14e051c933f2ec2ae9891efbf329e7f0f2cba4</em>
</li>
</ul>
TicketchapotonSun, 06 Sep 2015 17:10:16 GMTdescription changed; commit deleted
https://trac.sagemath.org/ticket/9107#comment:87
https://trac.sagemath.org/ticket/9107#comment:87
<ul>
<li><strong>commit</strong>
<em>8b14e051c933f2ec2ae9891efbf329e7f0f2cba4</em> deleted
</li>
<li><strong>description</strong>
modified (<a href="/ticket/9107?action=diff&version=87">diff</a>)
</li>
</ul>
Ticket