Re: [sage-combinat-devel] unable to install (fixed)
Hi Travis! On Mon, Oct 15, 2012 at 02:37:10PM -0700, Travis Scrimshaw wrote: Nicolas, a quick question, I'm going to create a new ticket for partition_options-ts.patch, should I have #5439 list that as a dependency or just make a reference to it? Just make a list of the related patches in the description of #5439. By the way, you may want to dub this ticket a task rather than a defect. Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Fast check for updates?
Is there a way to (easily) check whether there are updates on the mercurial server without popping all patches, reapplying, and rebuilding? With the amount of cython in the queue, it's taking quite a while for sage to rebuild itself after each check. I just want to check that there are no changes, then commit (or update if there are changes)! In fact, if possible, this should probably be the default behaviour for 'sage --combinat update'. Best, -tom -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/-k92mDC7g-AJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Fast check for updates?
On Tue, Oct 16, 2012 at 01:31:11AM -0700, tom d wrote: Is there a way to (easily) check whether there are updates on the mercurial server without popping all patches, reapplying, and rebuilding? With the amount of cython in the queue, it's taking quite a while for sage to rebuild itself after each check. I just want to check that there are no changes, then commit (or update if there are changes)! In fact, if possible, this should probably be the default behaviour for 'sage --combinat update'. cd sage/devel/sage-combinat/.ht/patches hg incoming I agree that this would be a nice and easy to implement feature of the sage-combinat script. Volunteers? Cheers, Nicolas PS: It could even be fancy and only pop off those patches that have been modified (but that's tricky, because we need to check the series as well). -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Fast check for updates?
I could certainly look into writing the modification - I've written a shell script or ten in my day. How much different is the process for patching up the combinat script as opposed to the main sage sources? Cheers, -tom On Tuesday, October 16, 2012 11:50:10 AM UTC+3, Nicolas M. Thiery wrote: On Tue, Oct 16, 2012 at 01:31:11AM -0700, tom d wrote: Is there a way to (easily) check whether there are updates on the mercurial server without popping all patches, reapplying, and rebuilding?� With the amount of cython in the queue, it's taking quite a while for sage to rebuild itself after each check.� I just want to check that there are no changes, then commit (or update if there are changes)!� In fact, if possible, this should probably be the default behaviour for 'sage --combinat update'. cd sage/devel/sage-combinat/.ht/patches hg incoming I agree that this would be a nice and easy to implement feature of the sage-combinat script. Volunteers? Cheers, Nicolas PS: It could even be fancy and only pop off those patches that have been modified (but that's tricky, because we need to check the series as well). -- Nicolas M. Thi�ry Isil nth...@users.sf.net javascript: http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/CMv6ZW4jS5YJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-combinat-devel] Fast check for updates?
Hi Tom, On Tue, Oct 16, 2012 at 06:02:41AM -0700, tom d wrote: I could certainly look into writing the modification - I've written a shell script or ten in my day. Thanks! Even better: it's a Python script. How much different is the process for patching up the combinat script as opposed to the main sage sources? No real difference, except that it's in the hg repository sage/local/bin rather than sage/devel/sage-combinat/. It's in fact easier as there are basically no risk to get conflicts with other work in progress. One just needs to mention on the ticket on which repo the patch is to be applied. Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-devel] Policy on spkgs updates
Is it always encouraged to upgrade spkgs to more current stable upstream version? Right now scipy is at 0.9, applied with patches to fix a bug that is now corrected in version 0.11 (normally, I have not tested yet). The patch does not seem to work under Mac OS X 10.8, so I was wondering if instead of fixing the patch I should really upgrade the spkg to the later version for everyone. Paul -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] Policy on spkgs updates
On 16/10/2012, at 7:17 PM, Paul-Olivier Dehaye paul-olivier.deh...@math.uzh.ch wrote: Is it always encouraged to upgrade spkgs to more current stable upstream version? Right now scipy is at 0.9, applied with patches to fix a bug that is now corrected in version 0.11 (normally, I have not tested yet). The patch does not seem to work under Mac OS X 10.8, so I was wondering if instead of fixing the patch I should really upgrade the spkg to the later version for everyone. Paul You mean like in #13541? -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] Re: Removing pickles from the pickle jar?
Here is my vote: You may add stuff to the pickle jar. But please do not remove stuff from the pickle jar. +1 -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] Re: Removing pickles from the pickle jar?
Hi Simon, If I understand correctly, we are talking here about modifying in the sense of removing stuff. IMHO, it would be totally against the purpose of the pickle jar, if we would encourage (or just explain how) to remove stuff from the pickle jar. If the pickle jar doc tests break then I think it is *not* the pickle jar that needs to be updated. Instead, it is the unpickling methods that need to be fixed. Actually, I think that you and I are talking about two different things: I am happy to maintain the pickle_jar whenever possible in the way the sage community wishes but I would really like this to be documented properly by the people who how know how it is supposed to work. I removed these files from the pickle jar not because I wantonly wanted to destroy pickles but because I thought that this was the correct way to fix the problem - it does, after all, fix the doc tests. If this procedure was properly documented in the development guide, for example then we would not be having this conversation. Having said that I am happy to maintain old pickles, if it's possible, I should add that with my limited knowledge of pickles it does seem to me when a class is refactored (as here) then it will not always be possible to unpickle the old pickle because the new and old data structures may not be compatible. Perhaps I am being naive, however, as I am yet to figure out how register_unpickle_override works. Cheers, Andrew -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] Policy on spkgs updates
On 2012-10-16 08:17, Paul-Olivier Dehaye wrote: Is it always encouraged to upgrade spkgs to more current stable upstream version? No. I'd say it's neither encouraged nor discouraged. Usually patching a package is easier than updating to the latest upstream version. Sometimes upstream upgrades break stuff. But if it's easy to upgrade, then sure, why not do it? -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] setup.py
Hi! Having to manually update the packages list in the setup.py file whenever one adds a new directory to the sage sources is a pain, and a constant source of conflicts between patches. Shall we instead build this list automatically, either at compile time or at sage's startup? Would this by any chance be taken care of by the upcoming change to setuptools #13190? Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] Re: Removing pickles from the pickle jar?
On Tuesday, October 16, 2012 8:47:03 AM UTC+2, Andrew Mathas wrote: Hi Simon, If I understand correctly, we are talking here about modifying in the sense of removing stuff. IMHO, it would be totally against the purpose of the pickle jar, if we would encourage (or just explain how) to remove stuff from the pickle jar. If the pickle jar doc tests break then I think it is *not* the pickle jar that needs to be updated. Instead, it is the unpickling methods that need to be fixed. Actually, I think that you and I are talking about two different things: I am happy to maintain the pickle_jar whenever possible in the way the sage community wishes but I would really like this to be documented properly by the people who how know how it is supposed to work. I think the doc here explicitly says that the default pickle jar should be updated from time to time: http://www.sagemath.org/doc/reference/sage/structure/sage_object.html#sage.structure.sage_object.picklejar I also agree it may not be a sensible choice to remove old pickles (the point is to be sure they can still be loaded! so removing them to pass doctests is a bad fix in my opinion), nor to keep the ones from sage 0.4 whose class got deprecated in sage 1.1. I removed these files from the pickle jar not because I wantonly wanted to destroy pickles but because I thought that this was the correct way to fix the problem - it does, after all, fix the doc tests. If this procedure was properly documented in the development guide, for example then we would not be having this conversation. Having said that I am happy to maintain old pickles, if it's possible, I should add that with my limited knowledge of pickles it does seem to me when a class is refactored (as here) then it will not always be possible to unpickle the old pickle because the new and old data structures may not be compatible. Perhaps I am being naive, however, as I am yet to figure out how register_unpickle_override works. Cheers, Andrew -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] Re: Removing pickles from the pickle jar?
I also agree it may not be a sensible choice to remove old pickles (the point is to be sure they can still be loaded! so removing them to pass doctests is a bad fix in my opinion), nor to keep the ones from sage 0.4 whose class got deprecated in sage 1.1. Just for the record the pickles removed were for classes being deprecated. A. -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] setup.py
No, 13190 would not solve the problem, and it would be very difficult to have the entire list generated automatically, since setting up the appropriate flags, source files, etc would be very difficult, if not impossible to automate. 13031 would do a lot to help the situation -- the point of the ticket is to use Cython's built in logic to deal with dependency checking and generation of c files (which is finally robust enough to handle the complexity of sage). Since the patch almost rewrites module_list.py, it probably needs rebasing again (I haven't rebased since 5.4.beta1). On Tue, Oct 16, 2012 at 12:40 AM, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote: Hi! Having to manually update the packages list in the setup.py file whenever one adds a new directory to the sage sources is a pain, and a constant source of conflicts between patches. Shall we instead build this list automatically, either at compile time or at sage's startup? Would this by any chance be taken care of by the upcoming change to setuptools #13190? Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. -- Andrew -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] setup.py
Hi Andrew! On Tue, Oct 16, 2012 at 12:59:05AM -0700, R. Andrew Ohana wrote: No, 13190 would not solve the problem, and it would be very difficult to have the entire list generated automatically, since setting up the appropriate flags, source files, etc would be very difficult, if not impossible to automate. Thanks for your answer! You are speaking about module_list.py, right? That certainly sounds non trivial! I was just thinking of the ``packages`` list in ``setup.py``. It seems to be in one-to-one correspondence with the subdirectories in devel/sage/sage. I actually just ran a diff between what I get with ``ls **/__init__.py``, and I get just three differences. One because ``graph_decompositions`` is listed twice in ``setup.py`` (an accident), and the others because ``sage/libs/polybori/`` and ``sage/libs/gmp/` dont have a __init__.py file (those would be easy to add). So? Nicolas PS: Of course, autogenerating (part of) module_list would be nice as well :-) -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] Re: Removing pickles from the pickle jar?
On Tue, Oct 16, 2012 at 12:22:25AM -0600, David Roe wrote: Here is my vote: You may add stuff to the pickle jar. But please do not remove stuff from the pickle jar. +1 My point of view: - The pickle jar is here to test that Sage supports loading back old pickles for backward compatibility. - The general rule is that Sage should strive for backward compatibility. - There can however be a few circumstances where keeping backward compatibility is far more work than it's worth for the community. In such cases, it can be decided by consensus (e.g. through a vote) to break it. - As a special case, the general rule is to not remove stuff from the pickle jar, except on special circumstances where it's not worth the trouble (we have already done that on some rare occasions). - For the case at hand, I am fine breaking backward compatibility for the reasons I mentioned on the ticket. Note that updating a pickle in the pickle jar is not much better than removing a pickle; in both case we don't test any more backward compatibility for an old pickle. For doing this cleanly, we should have versioned pickles, as proposed on: http://trac.sagemath.org/sage_trac/ticket/10768 By the way, this ticket goes in the same general direction of having a single mercurial/git repository for all of Sage. Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] Policy on spkgs updates
Yes, like #13541 On Tuesday, October 16, 2012 8:19:11 AM UTC+2, yomcat wrote: On 16/10/2012, at 7:17 PM, Paul-Olivier Dehaye paul-oliv...@math.uzh.chjavascript: wrote: Is it always encouraged to upgrade spkgs to more current stable upstream version? Right now scipy is at 0.9, applied with patches to fix a bug that is now corrected in version 0.11 (normally, I have not tested yet). The patch does not seem to work under Mac OS X 10.8, so I was wondering if instead of fixing the patch I should really upgrade the spkg to the later version for everyone. Paul You mean like in #13541? -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] Re: Policy on spkgs updates
Given the choice between update (drop a patch that is fixed upstream) and fork (maintain a separate patch), I think we should always opt for the former. Otherwise we'll just get bogged down in an ever-increasing maintenance headache. Don't reinvent the wheel. So I'd say we should always upgrade to new upstream stable releases. Sometimes that uncovers bugs, which we then can report upstream. On Tuesday, October 16, 2012 7:17:55 AM UTC+1, Paul-Olivier Dehaye wrote: Is it always encouraged to upgrade spkgs to more current stable upstream version? -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] Re: Removing pickles from the pickle jar?
I'm confused here, the workflow should be deprecate - wait one year - remove deprecated functionality. But you are saying you want to remove the pickles at the beginning of the deprecation period? That sounds wrong. On Tuesday, October 16, 2012 8:58:06 AM UTC+1, Andrew Mathas wrote: I also agree it may not be a sensible choice to remove old pickles (the point is to be sure they can still be loaded! so removing them to pass doctests is a bad fix in my opinion), nor to keep the ones from sage 0.4 whose class got deprecated in sage 1.1. Just for the record the pickles removed were for classes being deprecated. A. -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] Re: Policy on spkgs updates
Le 16/10/2012 12:43, Volker Braun a écrit : Given the choice between update (drop a patch that is fixed upstream) and fork (maintain a separate patch), I think we should always opt for the former. Otherwise we'll just get bogged down in an ever-increasing maintenance headache. Don't reinvent the wheel. So I'd say we should always upgrade to new upstream stable releases. Sometimes that uncovers bugs, which we then can report upstream. It depends. For example, in debian stable, the adjective refers to the fact that the bugs are stable, precisely because things aren't updated to latest upstreams. The downside is that it is always using several years old software, even when it gets out! And that makes sense... On the other end, when you're looking for say an elliptic curve algorithm or trying to make some things explicit in some very specialized domain, then you are generally interested in the latest and greatest. Isn't sage geared toward research-level mathematics anymore? Snark on #sagemath -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] Troubles build doc - Sphinx AttributeError: Reporter instance has no attribute 'locator'
Hi, I have troubles building the documentation. Can any one help me? Following are some usefull information and the error notification. $ sage -v Sage Version 5.4.rc1, Release Date: 2012-10-05 $ sage -branch main $ sage -docbuild reference html sphinx-build -b html -d /home/raniere/opt/sage/devel/sage/doc/output/doctrees/en/reference /home/raniere/opt/sage/devel/sage/doc/en/reference /home/raniere/opt/sage/devel/sage/doc/output/html/en/reference Running Sphinx v1.1.2 loading pickled environment... not yet created loading intersphinx inventory from /home/raniere/opt/sage/devel/sage/doc/common/python.inv... building [html]: targets for 1064 source files that are out of date updating environment: 1064 added, 0 changed, 0 removed reading sources... [ 0%] coercion Exception occurred: File /home/raniere/opt/sage/local/lib/python2.7/site-packages/Sphinx-1.1.2-py2.7.egg/sphinx/util/nodes.py, line 183, in set_role_source_info inliner.reporter.locator(lineno) AttributeError: Reporter instance has no attribute 'locator' The full traceback has been saved in /tmp/sphinx-err-M2ppWT.log, if you want to report the issue to the developers. Please also report this if it was a user error, so that a better error message can be provided next time. Either send bugs to the mailing list at http://groups.google.com/group/sphinx-dev/, or report them in the tracker at http://bitbucket.org/birkenfeld/sphinx/issues/. Thanks! Build finished. The built documents can be found in /home/raniere/opt/sage/devel/sage/doc/output/html/en/reference ---/tmp/sphinx-err-M2ppWT.log--- # Sphinx version: 1.1.2 # Python version: 2.7.3 # Docutils version: 0.9.1 release # Jinja2 version: 2.6 Traceback (most recent call last): File /home/raniere/opt/sage/local/lib/python2.7/site-packages/Sphinx-1.1.2-py2.7.egg/sphinx/cmdline.py, line 189, in main app.build(force_all, filenames) File /home/raniere/opt/sage/local/lib/python2.7/site-packages/Sphinx-1.1.2-py2.7.egg/sphinx/application.py, line 204, in build self.builder.build_update() File /home/raniere/opt/sage/local/lib/python2.7/site-packages/Sphinx-1.1.2-py2.7.egg/sphinx/builders/__init__.py, line 196, in build_update 'out of date' % len(to_build)) File /home/raniere/opt/sage/local/lib/python2.7/site-packages/Sphinx-1.1.2-py2.7.egg/sphinx/builders/__init__.py, line 216, in build purple, length): File /home/raniere/opt/sage/local/lib/python2.7/site-packages/Sphinx-1.1.2-py2.7.egg/sphinx/builders/__init__.py, line 120, in status_iterator for item in iterable: File /home/raniere/opt/sage/local/lib/python2.7/site-packages/Sphinx-1.1.2-py2.7.egg/sphinx/environment.py, line 616, in update_generator self.read_doc(docname, app=app) File /home/raniere/opt/sage/local/lib/python2.7/site-packages/Sphinx-1.1.2-py2.7.egg/sphinx/environment.py, line 764, in read_doc pub.publish() File /home/raniere/.local/lib/python2.7/site-packages/docutils-0.9.1-py2.7.egg/docutils/core.py, line 221, in publish self.settings) File /home/raniere/.local/lib/python2.7/site-packages/docutils-0.9.1-py2.7.egg/docutils/readers/__init__.py, line 69, in read self.parse() File /home/raniere/.local/lib/python2.7/site-packages/docutils-0.9.1-py2.7.egg/docutils/readers/__init__.py, line 75, in parse self.parser.parse(self.input, document) File /home/raniere/.local/lib/python2.7/site-packages/docutils-0.9.1-py2.7.egg/docutils/parsers/rst/__init__.py, line 162, in parse self.statemachine.run(inputlines, document, inliner=self.inliner) File /home/raniere/.local/lib/python2.7/site-packages/docutils-0.9.1-py2.7.egg/docutils/parsers/rst/states.py, line 174, in run input_source=document['source']) File /home/raniere/.local/lib/python2.7/site-packages/docutils-0.9.1-py2.7.egg/docutils/statemachine.py, line 239, in run context, state, transitions) File /home/raniere/.local/lib/python2.7/site-packages/docutils-0.9.1-py2.7.egg/docutils/statemachine.py, line 460, in check_line return method(match, context, next_state) File /home/raniere/.local/lib/python2.7/site-packages/docutils-0.9.1-py2.7.egg/docutils/parsers/rst/states.py, line 2706, in underline self.section(title, source, style, lineno - 1, messages) File /home/raniere/.local/lib/python2.7/site-packages/docutils-0.9.1-py2.7.egg/docutils/parsers/rst/states.py, line 331, in section self.new_subsection(title, lineno, messages) File /home/raniere/.local/lib/python2.7/site-packages/docutils-0.9.1-py2.7.egg/docutils/parsers/rst/states.py, line 399, in new_subsection node=section_node, match_titles=True) File /home/raniere/.local/lib/python2.7/site-packages/docutils-0.9.1-py2.7.egg/docutils/parsers/rst/states.py, line 286, in nested_parse node=node, match_titles=match_titles) File /home/raniere/.local/lib/python2.7/site-packages/docutils-0.9.1-py2.7.egg/docutils/parsers/rst/states.py, line 199, in run results = StateMachineWS.run(self, input_lines, input_offset) File
Re: [sage-devel] setup.py
On Tue, Oct 16, 2012 at 12:59 AM, R. Andrew Ohana andrew.oh...@gmail.com wrote: No, 13190 would not solve the problem, and it would be very difficult to have the entire list generated automatically, since setting up the appropriate flags, source files, etc would be very difficult, if not impossible to automate. 13031 would do a lot to help the situation -- the point of the ticket is to use Cython's built in logic to deal with dependency checking and generation of c files (which is finally robust enough to handle the complexity of sage). Since the patch almost rewrites module_list.py, it probably needs rebasing again (I haven't rebased since 5.4.beta1). This would also allow us to specify library dependencies, etc. in the source files themselves (and track then transitively), so module_list could be almost entirely generated. First we just need to get something in and then we can work on automating setup.py piecemeal. I'll rebase it if anyone is willing to review it. As for packages, I see no reason to not auto-generate it. (Perhaps we could have an excludes parameter if need be.) On Tue, Oct 16, 2012 at 12:40 AM, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote: Hi! Having to manually update the packages list in the setup.py file whenever one adds a new directory to the sage sources is a pain, and a constant source of conflicts between patches. Shall we instead build this list automatically, either at compile time or at sage's startup? Would this by any chance be taken care of by the upcoming change to setuptools #13190? Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. -- Andrew -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
Re: [sage-devel] setup.py
As for packages, I see no reason to not auto-generate it. (Perhaps we could have an excludes parameter if need be.) +1 -- You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
[sage-devel] Re: Troubles build doc - Sphinx AttributeError: Reporter instance has no attribute 'locator'
I used the changes describes in https://bitbucket.org/birkenfeld/sphinx/changeset/bab0b83c9e02 and solve the problem. On Tue, Oct 16, 2012 at 11:13 AM, Raniere Gaia Silva r.gaia...@gmail.com wrote: Hi, I have troubles building the documentation. Can any one help me? Following are some usefull information and the error notification. $ sage -v Sage Version 5.4.rc1, Release Date: 2012-10-05 $ sage -branch main $ sage -docbuild reference html sphinx-build -b html -d /home/raniere/opt/sage/devel/sage/doc/output/doctrees/en/reference /home/raniere/opt/sage/devel/sage/doc/en/reference /home/raniere/opt/sage/devel/sage/doc/output/html/en/reference Running Sphinx v1.1.2 loading pickled environment... not yet created loading intersphinx inventory from /home/raniere/opt/sage/devel/sage/doc/common/python.inv... building [html]: targets for 1064 source files that are out of date updating environment: 1064 added, 0 changed, 0 removed reading sources... [ 0%] coercion Exception occurred: File /home/raniere/opt/sage/local/lib/python2.7/site-packages/Sphinx-1.1.2-py2.7.egg/sphinx/util/nodes.py, line 183, in set_role_source_info inliner.reporter.locator(lineno) AttributeError: Reporter instance has no attribute 'locator' The full traceback has been saved in /tmp/sphinx-err-M2ppWT.log, if you want to report the issue to the developers. Please also report this if it was a user error, so that a better error message can be provided next time. Either send bugs to the mailing list at http://groups.google.com/group/sphinx-dev/, or report them in the tracker at http://bitbucket.org/birkenfeld/sphinx/issues/. Thanks! Build finished. The built documents can be found in /home/raniere/opt/sage/devel/sage/doc/output/html/en/reference ---/tmp/sphinx-err-M2ppWT.log--- # Sphinx version: 1.1.2 # Python version: 2.7.3 # Docutils version: 0.9.1 release # Jinja2 version: 2.6 Traceback (most recent call last): File /home/raniere/opt/sage/local/lib/python2.7/site-packages/Sphinx-1.1.2-py2.7.egg/sphinx/cmdline.py, line 189, in main app.build(force_all, filenames) File /home/raniere/opt/sage/local/lib/python2.7/site-packages/Sphinx-1.1.2-py2.7.egg/sphinx/application.py, line 204, in build self.builder.build_update() File /home/raniere/opt/sage/local/lib/python2.7/site-packages/Sphinx-1.1.2-py2.7.egg/sphinx/builders/__init__.py, line 196, in build_update 'out of date' % len(to_build)) File /home/raniere/opt/sage/local/lib/python2.7/site-packages/Sphinx-1.1.2-py2.7.egg/sphinx/builders/__init__.py, line 216, in build purple, length): File /home/raniere/opt/sage/local/lib/python2.7/site-packages/Sphinx-1.1.2-py2.7.egg/sphinx/builders/__init__.py, line 120, in status_iterator for item in iterable: File /home/raniere/opt/sage/local/lib/python2.7/site-packages/Sphinx-1.1.2-py2.7.egg/sphinx/environment.py, line 616, in update_generator self.read_doc(docname, app=app) File /home/raniere/opt/sage/local/lib/python2.7/site-packages/Sphinx-1.1.2-py2.7.egg/sphinx/environment.py, line 764, in read_doc pub.publish() File /home/raniere/.local/lib/python2.7/site-packages/docutils-0.9.1-py2.7.egg/docutils/core.py, line 221, in publish self.settings) File /home/raniere/.local/lib/python2.7/site-packages/docutils-0.9.1-py2.7.egg/docutils/readers/__init__.py, line 69, in read self.parse() File /home/raniere/.local/lib/python2.7/site-packages/docutils-0.9.1-py2.7.egg/docutils/readers/__init__.py, line 75, in parse self.parser.parse(self.input, document) File /home/raniere/.local/lib/python2.7/site-packages/docutils-0.9.1-py2.7.egg/docutils/parsers/rst/__init__.py, line 162, in parse self.statemachine.run(inputlines, document, inliner=self.inliner) File /home/raniere/.local/lib/python2.7/site-packages/docutils-0.9.1-py2.7.egg/docutils/parsers/rst/states.py, line 174, in run input_source=document['source']) File /home/raniere/.local/lib/python2.7/site-packages/docutils-0.9.1-py2.7.egg/docutils/statemachine.py, line 239, in run context, state, transitions) File /home/raniere/.local/lib/python2.7/site-packages/docutils-0.9.1-py2.7.egg/docutils/statemachine.py, line 460, in check_line return method(match, context, next_state) File /home/raniere/.local/lib/python2.7/site-packages/docutils-0.9.1-py2.7.egg/docutils/parsers/rst/states.py, line 2706, in underline self.section(title, source, style, lineno - 1, messages) File /home/raniere/.local/lib/python2.7/site-packages/docutils-0.9.1-py2.7.egg/docutils/parsers/rst/states.py, line 331, in section self.new_subsection(title, lineno, messages) File /home/raniere/.local/lib/python2.7/site-packages/docutils-0.9.1-py2.7.egg/docutils/parsers/rst/states.py, line 399, in new_subsection node=section_node, match_titles=True) File
[sage-devel] Re: Removing pickles from the pickle jar?
On Tuesday, 16 October 2012 22:00:13 UTC+11, Volker Braun wrote:
I'm confused here, the workflow should be deprecate - wait one year -
remove deprecated functionality. But you are saying you want to remove the
pickles at the beginning of the deprecation period? That sounds wrong.
Hi Volker,
I agree that this wrong, however, I also think that it is unavoidable in
some cases. I would be very happy to be corrected on this.
I have just uploaded a new patch *
trac_9265--tableaux_categories_pickles-am.patch*http://trac.sagemath.org/sage_trac/attachment/ticket/9265/trac_9265--tableaux_categories_pickles-am.patchto
trac which adds a bunch of unpickle overrides to fix all but four of the
unpickling errors (see the ticket). The ones that remain are all due, I
think, to not being able to unpickle the class *Tableau_class* which is
being deprecated by this patch.
I have tried to fix the unpickling of Tableau_class using
register_unpickle_override('sage.combinat.tableau', 'Tableau_class',
Tableau)
but this does not work. My guess is that it is not possible to unpickle the
deprecated *Tableau_class* objects using the new *Tableau* class objects
because the underlying classes are too different.
If some one can see how to do this please let me know.
Andrew
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To post to this group, send email to sage-devel@googlegroups.com.
To unsubscribe from this group, send email to
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
