[sage-combinat-devel] problem in words
Hi there, I was using lrcalc, and noticed that supplying the weight keyword does not work, not even the doctest: (this is on sage 4.8) lrcalc.lrskew([3,2,1], [2], weight=[3,1]) gives 1 not in alphabet. I found that the problem is that the row_word of a skew tableau expects its entries to be from ZZ, while lrcalc uses int's. If this is not known, how should it be fixed? Should we convert the entries of the tableau returned by lrcalc to ZZ's or only when computing the row_word? Martin -- 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] problem in words
Hi Martin, hi Vincent, On Thu, Mar 15, 2012 at 08:43:47AM +0100, Martin Rubey wrote: I was using lrcalc, and noticed that supplying the weight keyword does not work, not even the doctest: (this is on sage 4.8) lrcalc.lrskew([3,2,1], [2], weight=[3,1]) gives 1 not in alphabet. I found that the problem is that the row_word of a skew tableau expects its entries to be from ZZ, while lrcalc uses int's. If this is not known, how should it be fixed? Should we convert the entries of the tableau returned by lrcalc to ZZ's or only when computing the row_word? For the record, this only appears when alphabet-vd.patch is applied. Without it, the doctest pass (4.8, 5.0): sage: import sage.libs.lrcalc.lrcalc sage: sage.libs.lrcalc.lrcalc.lrskew([3,2,1], [2], weight=[3,1]) [[[None, None, 1], [1, 1], [2]]] That being said, internally, this tableau indeed contains ints: sage: t = sage.libs.lrcalc.lrcalc.lrskew([3,2,1], [2], weight=[3,1])[0] sage: type(t[2][0]) type 'int' Whereas the same tableau build from the command line would be filled with Integers:: sage: t2 = SkewTableau([[None, None, 1], [1, 1], [2]]) sage: type(t2[2][0]) type 'sage.rings.integer.Integer' Well, at least, those two tableaux are equal: sage: t == t2 True I let the tableau fans decide whether we want to enforce that all entries of a (skew) tableau are Integers, and if yes to write a patch on lrcalc to convert the ints to Integers. We could throw this in the ticket #12284 which will make lrcalc a standard Sage package. 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.
Re: [sage-combinat-devel] problem in words
On Thu, Mar 15, 2012 at 09:27:00AM +0100, Martin Rubey wrote: Yet another thing: sage: lrskew([1,1],[2])[0].pp() . . 1 So, possibly lrskew should check that mu is contained in lambda? I guess the result above indeed has no specific meaning, but you might want to double check with Anders, just in case. Otherwise, you are welcome to add in the documentation that inner should be contained in outer. And to add an assertion check such as: assert len(inner) = len(outer) and inner[i]=outer[i] for i in range(len(inner)), inner should be contained in outer 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.
Re: [sage-combinat-devel] problem in words
Dear Anders, I was using lrcalc from within sage and noticed the following: sage: lrskew([1,1],[2])[0].pp() . . 1 that is, lrskew returns a tableau of shape [1,1]/[2] :-) Should lrcalc check that mu is contained in lambda, or sage, or neither? Many thanks, Martin -- 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] bug? in Partitions
On Tue, Mar 13, 2012 at 05:52:03PM +0100, Florent Hivert wrote: So if we suggest that the sum could be negative then we should also take care of having other negative argument. I would put it more mildly: if we accept negative sums, then the user might expect that other arguments like min_part would accept negative values. However the underlying algorithmic strongly relies on all parts to be non negative. That being said, if there is a good use case where it is much more practical to accept negative sums, and if it can be implemented consistently for Partitions, Compositions, and other IntegerVectors with just a few lines of code, then I guess I would be fine with it, as long as this is documented as such: For the user's convenience, Partitions(-4) is accepted and returns the empty set:: sage: Partitions(-4).list() [] sage: TestSuite(Partitions(-4)).run() 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.
Re: [sage-combinat-devel] problem in words
Hi Martin, hi Nicolas,
2012/3/15, Nicolas M. Thiery nicolas.thi...@u-psud.fr:
Hi Martin, hi Vincent,
On Thu, Mar 15, 2012 at 08:43:47AM +0100, Martin Rubey wrote:
I was using lrcalc, and noticed that supplying the weight keyword does
not work, not even the doctest: (this is on sage 4.8)
lrcalc.lrskew([3,2,1], [2], weight=[3,1])
gives 1 not in alphabet.
I found that the problem is that the row_word of a skew tableau expects
its entries to be from ZZ, while lrcalc uses int's.
If this is not known, how should it be fixed? Should we convert the
entries of the tableau returned by lrcalc to ZZ's or only when computing
the row_word?
For the record, this only appears when alphabet-vd.patch is
applied. Without it, the doctest pass (4.8, 5.0):
Sorry for this. The reason is:
{{{
sage: 1 in IntegerRange(5)
True
sage: int(1) in IntegerRange(5)
False
}}}
and that alphabet-vd.patch now makes IntegerRange a default for
alphabet over integer. I don't know what to do...
Cheers,
Vincent
--
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] problem in words
Hi Vincent,
On 3/15/12 7:30 AM, Vincent Delecroix wrote:
Hi Martin, hi Nicolas,
2012/3/15, Nicolas M. Thiery nicolas.thi...@u-psud.fr:
Hi Martin, hi Vincent,
On Thu, Mar 15, 2012 at 08:43:47AM +0100, Martin Rubey wrote:
I was using lrcalc, and noticed that supplying the weight keyword does
not work, not even the doctest: (this is on sage 4.8)
lrcalc.lrskew([3,2,1], [2], weight=[3,1])
gives 1 not in alphabet.
I found that the problem is that the row_word of a skew tableau expects
its entries to be from ZZ, while lrcalc uses int's.
If this is not known, how should it be fixed? Should we convert the
entries of the tableau returned by lrcalc to ZZ's or only when computing
the row_word?
For the record, this only appears when alphabet-vd.patch is
applied. Without it, the doctest pass (4.8, 5.0):
Sorry for this. The reason is:
{{{
sage: 1 in IntegerRange(5)
True
sage: int(1) in IntegerRange(5)
False
}}}
and that alphabet-vd.patch now makes IntegerRange a default for
alphabet over integer. I don't know what to do...
As Nicolas wrote, one could in principle enforce the skew tableaux produced by
lrcalc
to use Integers. This could be put in #12284. If containment checking of the
skew partitions
also should be done, this could also go into that patch.
Best,
Anne
--
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] doctest failures in categories/coxeter_groups.py
Arrgh, I had my google account settings wrong and several of my email posts went to the bit bucket before I noticed. I have been encountering doctest errors involving the availability of chevie: /coxeter_group.py, line 256, in CoxeterGroup assert is_chevie_available() What is the workaround? The error log follows (snipped after the assertion error). (Note that _test_enumerated_set_iter_cardinality() also fails.) --Mark sage -t devel/sage-combinat/sage/categories/coxeter_groups.py ** File /home/msshimo/sage-5.0.beta7/devel/sage-combinat/sage/categories/ coxeter_groups.py, line 74: sage: W = CoxeterGroups().example(); TestSuite(W).run(verbose = True) Expected: running ._test_an_element() . . . pass running ._test_associativity() . . . pass running ._test_category() . . . pass running ._test_elements() . . . Running the test suite of self.an_element() running ._test_category() . . . pass running ._test_eq() . . . pass running ._test_not_implemented_methods() . . . pass running ._test_pickling() . . . pass pass running ._test_elements_eq() . . . pass running ._test_enumerated_set_contains() . . . pass running ._test_enumerated_set_iter_cardinality() . . . pass running ._test_enumerated_set_iter_list() . . . pass running ._test_eq() . . . pass running ._test_has_descent() . . . pass running ._test_inverse() . . . pass running ._test_not_implemented_methods() . . . pass running ._test_one() . . . pass running ._test_pickling() . . . pass running ._test_prod() . . . pass running ._test_reduced_word() . . . pass running ._test_simple_projections() . . . pass running ._test_some_elements() . . . pass Got: running ._test_an_element() . . . pass running ._test_associativity() . . . pass running ._test_category() . . . pass running ._test_elements() . . . Running the test suite of self.an_element() running ._test_category() . . . pass running ._test_eq() . . . pass running ._test_not_implemented_methods() . . . pass running ._test_pickling() . . . pass pass running ._test_elements_eq() . . . pass running ._test_enumerated_set_contains() . . . pass running ._test_enumerated_set_iter_cardinality() . . . fail Traceback (most recent call last): File /home/msshimo/sage-5.0.beta7/local/lib/python/site- packages/sage/misc/sage_unittest.py, line 279, in run test_method(tester = tester) File /home/msshimo/sage-5.0.beta7/local/lib/python/site- packages/sage/categories/finite_enumerated_sets.py, line 426, in _test_enumerated_set_iter_cardinality tester.assert_(type(card) is Integer) File /home/msshimo/sage-5.0.beta7/local/lib/python2.7/unittest/ case.py, line 420, in assertTrue raise self.failureException(msg) AssertionError: False is not true running ._test_enumerated_set_iter_list() . . . pass running ._test_eq() . . . pass running ._test_has_descent() . . . pass running ._test_inverse() . . . pass running ._test_len() . . . pass running ._test_not_implemented_methods() . . . pass running ._test_one() . . . pass running ._test_pickling() . . . pass running ._test_prod() . . . pass running ._test_reduced_word() . . . pass running ._test_simple_projections() . . . pass running ._test_some_elements() . . . pass The following tests failed: _test_enumerated_set_iter_cardinality ** File /home/msshimo/sage-5.0.beta7/devel/sage-combinat/sage/categories/ coxeter_groups.py, line 612: sage: W = CoxeterGroup(['A',2],index_set=[1,2]) Exception raised: Traceback (most recent call last): File /home/msshimo/sage-5.0.beta7/local/bin/ncadoctest.py, line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File /home/msshimo/sage-5.0.beta7/local/bin/sagedoctest.py, line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File /home/msshimo/sage-5.0.beta7/local/bin/ncadoctest.py, line 1172, in run_one_example compileflags, 1) in test.globs File doctest __main__.example_16[2], line 1, in module W = CoxeterGroup(['A',Integer(2)],index_set=[Integer(1),Integer(2)])###line 612: sage: W = CoxeterGroup(['A',2],index_set=[1,2]) File /home/msshimo/sage-5.0.beta7/local/lib/python/site- packages/sage/combinat/root_system/coxeter_group.py, line 256, in CoxeterGroup assert is_chevie_available() AssertionError -- 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
Re: [sage-combinat-devel] doctest failures in categories/coxeter_groups.py
Cristian and Nicolas, I already installed the J-M distro of gap3 and it works from the command line, but how do I tell sage of its existence? I see that the ticket has a line sage -i gap3-jm2.spkg based on an older version. --Mark I have just updated the GAP3 interface ticket description on http://trac.sagemath.org/sage_trac/ticket/8380 to describe how to install GAP3 (including a link to the spkg based on Jean-Michel's distribution). Please check! On Thu, Mar 15, 2012 at 06:59:03PM +0100, Christian Stump wrote: You should then be set to play with CoxeterGroups in Sage. Please be aware that I am constantly (sometimes more sometimes less) working on the implementation, so it is not yet completely stable and things might change. Please send feedback when you encounter bugs or missing features (of course, there is a lot missing still!). By the way: for Mark's current purpose, it might be sufficient to tag the GAP3 dependent tests with # optional. 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. -- 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] doctest failures in categories/coxeter_groups.py
Never mind, I had named the shellscript gap instead of gap3. --Mark Can you reconfirm that you can run gap3 from the command line within the Sage folder. I wouldn't know anything else necessary, do you Nicolas? Next, what happens if you run gap3.console() from within Sage? -- 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. -- 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] doctest failures in categories/coxeter_groups.py
Hi! Actually, I think the easiest to install gap3 for Sage is using sage -f http://sage.math.washington.edu/home/nthiery/gap3-jm2.spkg Best, Anne On 3/15/12 10:59 AM, Christian Stump wrote: Dear Marc, /coxeter_group.py, line 256, in CoxeterGroup assert is_chevie_available() To use the coxeter groups implementation, you must have gap3 installed (i.e., typing gap3 in the command line starts gap3), and the chevie package available (i.e., typing RequirePackage(chevie) within gap3 should work). The easiest to obtain that is to download Jean Michel's version of gap3 with chevie preinstalled, which you can download at http://www.math.jussieu.fr/~jmichel/gap3/gap3-jm4.tar.gz (Thanks to Jean for providing it!). From http://www.math.jussieu.fr/~jmichel/gap3/: The installation instructions are as follows: unpack somewhere the file, it will make a gap3-jm4 directory. Then, in gap3-jm4/bin edit gap.sh (on Linux or Mac-OSX) or gap.bat or gap.cmd (on dos/windows) so that the variable GAP_DIR refers to the right directory and GAP_PRG to the right executable, and put gap.sh (renamed gap3) or gap.bat someplace on your path. You should then be set to play with CoxeterGroups in Sage. Please be aware that I am constantly (sometimes more sometimes less) working on the implementation, so it is not yet completely stable and things might change. Please send feedback when you encounter bugs or missing features (of course, there is a lot missing still!). Let me know if you don't get gap3 running, or if you have other issues! Christian -- 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] Re: Adding GCC and MPC as standard packages
Hi Leif, hi all, On 15 Mrz., 04:13, leif not.rea...@online.de wrote: So what we currently need is CLooG-PPL 0.15.11, and a suitable version of PPL. (I'm not 100% sure that PPL 0.11.2, the version currently shipped with Sage, works, but /I think/(tm) it will...) I installed * a modified PPL 0.11.2 spkg, that also installs a C interface, * a CLooG-PPL 0.15.11 spkg * a modified gcc 4.6.3 spkg, that builds gcc with graphite. TODO: Attempt to build graphite only if CLooG-PPL is present. I defined CFLAGS=-O3 -march=native -floop-interchange -floop-strip-mine -floop- block -fno-strict-aliasing export CFLAGS CXXFLAGS=-O3 -march=native -floop-interchange -floop-strip-mine - floop-block -fno-strict-aliasing export CXXFLAGS And then I rebuilt all of Sage (not only sage -ba, I rebuilt all spkgs). I did not run the test suite yet, but the compilation in this high optimization went smoothly on my openSuse laptop, and Sage starts. I am looking forward to the total time required for running sage - testall compared with and without optimization! Cheers, Simon -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Building a deb for sage on Debian/Ubuntu
Hi Dan On 15 March 2012 02:05, Dan Drake dr...@kaist.edu wrote: sudo apt-add-repository ppa:aims/sagemath sudo apt-get update sudo apt-get install sagemath-upstream-binary I tried this in a 11.10 virtual machine, and it created the user's .sage directory as owned by root -- with 700 permissions, so when I try to start Sage, it fails because it can't read that directory. In another virtual machine, I got something similar, where the matplotlib directory was owned by root. This may be related to having used Sage previously on those machines, but in any case we shouldn't create root-owned things in the user's directory! Thanks, I will look into it. Are the steps to reproduce 1) install new OS, 2) install Sage from PPA, 3) run sage as user? I had previous .sage directories and the 64bit install on precise did not cause this problem. I now moved my .sage out the way and ran sage, and .sage was not created with root permissions. I then removed my .sage, aptitude reinstall sagemath-upstream-binary, ran sage, but am not able to reproduce this problem. I can't really think how the deb could cause this, but will try reproduce on a fresh OS install in a VM in a week or two. An update on the previous dpkg version problem. I have dropped lucid support on that PPA, as it is the only Ubuntu version requiring an older dpkg, and that older dpkg does not support xz compression. The difference between xz compression and gz compression is roughly 80M for the deb alone. dpkg 1.15.6 started supporting this. I did however add 32bit and changed to supporting natty, oneiric, and precise. The 32bit is really compiled for i686 (not i386 as expected by debhelper) so I had to disable stripping the binary, so the 32bit deb package is 70M larger than the 64bit deb package. The latter is around 370M. The unpacked space usage is 1.6G. Anyway, the from-upstream-binary (that is the compiled binaries for Ubuntu 10.04.3 from sagemath.org) was just a hack to get something out quickly, I would like to move efforts on to a from-source PPA soon. I will however fix bugs as I can. The PPA has reached its 2G space limit on launchpad. I asked for more space on 6th March: https://answers.launchpad.net/launchpad/+question/189847 The project is pretty much standing still until that space problem is sorted out. Regards, Jan -- .~. /V\ Jan Groenewald /( )\www.aims.ac.za ^^-^^ -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Adding GCC and MPC as standard packages
On 15 Mrz., 07:12, Simon King simon.k...@uni-jena.de wrote: I installed * a modified PPL 0.11.2 spkg, that also installs a C interface, * a CLooG-PPL 0.15.11 spkg * a modified gcc 4.6.3 spkg, that builds gcc with graphite. And I forgot: I also upgraded the optional GMP spkg (GMP is required by CLooG). Our old spkg was broken and needed massive patches. I made an spkg based on unpatched GMP 5.0.4 upstream sources. I have no idea what would happen on other platforms, but it worked on openSuse. Cheers, Simon -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Basing new development versions of Sage on the previous development version
Georg S. Weber georgswe...@googlemail.com writes: On 14 Mrz., 20:43, Jeroen Demeyer jdeme...@cage.ugent.be wrote: On 2012-03-14 19:20, Keshav Kini wrote: If we switch to git, as I understand we eventually will, patches (commits) made from an older dev release will be considered to not apply (not be mergeable) a lot more often than merely the cases when other people have meanwhile touched the same files - in fact, *always* - unless we make development releases based on their predecessors. If this is true, then I don't want to switch to git. (... scatches his head ...) If this was true, how could Torvalds and coworkers possibly use git as a (distributed!) version control system tool for developing the Linux kernel? ... what? I made a very specific statement about Sage development. Kernel development has nothing to do with it. In particular, I *guarantee* you that the kernel devs do not rewrite published history in their public tree, while we do so left and right, even when it's not even necessary (i.e. when no patches even need to be backed out)! In fact, here's `a quote`_ from the Linux kernel developer's guide: if you rewrite history which other developers have pulled into their repositories, you will make life much more difficult for those developers. So a simple rule of thumb applies here: history which has been exported to others should generally be seen as immutable thereafter. And we not only mutate history that has been exported to others, but history that has been published as an official beta version of Sage!! .. _a quote: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/development-process/7.AdvancedTopics;h=26dc3fa196e46fc9a1f8ef9f03e303c409e5b8b2;hb=HEAD#l80 To explain what I meant in more technical detail: If we switch to git, commits made on an older dev release will not be mergeable into the new dev release unless the new dev release is based on (i.e. consists of a superset of the commits present in) the old dev release. (In the below, single lines indicate history private to a single developer, and double lines indicate history published in our official repository.) How it would work if new dev releases were based on old dev releases 1) A dev release is made, incorporating commits A and B. o == A == B ^ 1 2) A developer commits some changes on top of the release. o == A == B -- X ^ 1 3) Another release is made, incorporating commit C. X / o == A == B == C ^^ 12 4) The developer updates his changes with what has changed in the new release. He then makes some fixes to make his code compatible with the new release. X -- M -- Y // o == A == B == C ^^ 12 5) Another release is made, incorporating the developer's changes (X, M, and Y), but first backing out the changes made in A, with commit D. This release now incorporates X, M, Y, D, and E, on top of what was in the previous release. X == M === Y // // \\ o == A == B == C == D == E ^^ ^ 12 3 How it would work given current practices - 1) A release is made, incorporating commits A and B. o == A == B ^ 1 2) A developer commits some changes on top of the release. o == A == B -- X ^ 1 3) Another release is made, incorporating commit C but also duplicating commits A and B. Notice that previously public, global commits have now become private, local commits (the duplicated A and B). A -- B -- X / o == A == B == C ^^ 12 4) The developer updates his changes with what has changed in the new release. He makes some fixes to make his code compatible with the new release. A -- B -- X -- M -- Y / / o == A == B == C ^^ 12 5) Another release is made, incorporating the developer's changes (X, M, and Y), but first backing out the changes made in A, with commit D. Pulling in the developer's changes also pulls in the two old copies of A and B and one copy of C from the previous two dev releases. This release now incorporates X, M, Y, D, E, old A, old B, old C, older A, and older B on top of what was in the previous release. A == B == X == M == Y // // \\ /=== A == B == C\\ //\\ o == A == B == C == D = E ^^^ 123 What is wrong with this picture: * A and B now in the history in triplicate, and C in duplicate. This is confusing and a waste
[sage-devel] Re: Adding GCC and MPC as standard packages
On Mar 15, 7:15 am, Simon King simon.k...@uni-jena.de wrote: On 15 Mrz., 07:12, Simon King simon.k...@uni-jena.de wrote: I installed * a modified PPL 0.11.2 spkg, that also installs a C interface, * a CLooG-PPL 0.15.11 spkg * a modified gcc 4.6.3 spkg, that builds gcc with graphite. And I forgot: I also upgraded the optional GMP spkg (GMP is required by CLooG). Our old spkg was broken and needed massive patches. I made an spkg based on unpatched GMP 5.0.4 upstream sources. I have no idea what would happen on other platforms, but it worked on openSuse. I'm almost sure CLooG works with MPIR (2.x, with '--enable-gmpcompat', which we pass) as well. -leif -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] [SOLVED] Re: Sage 4.8 build failed: Error: Failed to build Maxima as an ECL library.
Wasn't a compiler problem. I built gcc 4.6.3 at my home directory and rebuilt sage. The problem persisted. The problem is very similar to what Dmitrii described here: https://groups.google.com/forum/?fromgroups#!msg/sage-devel/Gj3cbdcPqKo/ROV39CTFbI4J The problem is that my home directory is: /files3/home/sahosse/ but I only have execution permission to the directory home: [sahosse@msx0 ~]$ ls -ld /files3/home drwx--x--x 192 root msstaff 4096 Feb 15 13:23 /files3/home [sahosse@msx0 ~]$ ls -l /files3/home ls: /files3/home: Permission denied Off course I have access to my home directory but (directory) function of ecl always return NIL as long as home appears in the path of the requested directory, which means it fails on my entire home directory: [sahosse@msx0 ~]$ ~/sage/local/bin/ecl ECL (Embeddable Common-Lisp) 11.1.1 (git:UNKNOWN) Copyright (C) 1984 Taiichi Yuasa and Masami Hagiya Copyright (C) 1993 Giuseppe Attardi Copyright (C) 2000 Juan J. Garcia-Ripoll ECL is free software, and you are welcome to redistribute it under certain conditions; see file 'Copyright' for details. Type :h for Help. Top level. (directory /*) (#P/.autorelabel #P/.autofsck #P/.rnd) (directory /files3/*) NIL (directory /files3/home/sahosse/*) NIL (directory /tmp/maxima-5.23.2.p3/*) (#P/tmp/maxima-5.23.2.p3/spkg-install~ #P/tmp/maxima-5.23.2.p3/spkg-install #P/tmp/maxima-5.23.2.p3/.hgtags #P/tmp/maxima-5.23.2.p3/.hgignore #P/tmp/maxima-5.23.2.p3/spkg-dist) So, for the ecl step of maxima to be successful, I copied the maxima package directory to /tmp , run the rest of the script there, then commented Maxima out from the install script in spkg: Build finished. The built documents can be found in /files3/home/sahosse/sage/devel/sage/doc/output/html/ru/tutorial [sahosse@msx0 sage]$ sage -- | Sage Version 4.8, Release Date: 2012-01-20 | | Type notebook() for the GUI, and license() for information.| -- sage: maxima(1+1) 2 This is a bug of ecl and they need to fix it. It seems to me a poor implementation of directory function that can not handle such a common permission situation. I do not know how to report bug to ecl, but if sb knows please do. It is easily reproducible and I checked and it persists in the latest stable (12.2.1). בתאריך יום שני, 5 במרס 2012 20:31:20 UTC-7, מאת Dima Pasechnik: Well, I don't see what goes wrong there (except that the compiler you use is so outdated that surely Sage is not tested with it --- version alone does not say this, as the same version on MacOSX is a different beast). You mention people talking about this error on Lion. Any links to any posts/forums on this? I guess it is an ECL bug (or feature :)). I'll cc'in this to the ECL list, just in case they are aware of these issues. On Mar 5, 1:26 pm, syd.lavas...@gmail.com syd.lavas...@gmail.com wrote: Hello Dmitrii, Thank you very much for looking to my case. I have uploaded it here, good luck with this 90Mb file: http://payamban.com/install.log Moreover, maybe this information is also useful: ~/sage $ cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.8 (Tikanga) ~/sage $ gcc --version gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-52) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Thank you very much. Cheers, Syd בתאריך יום שישי, 2 במרס 2012 19:43:14 UTC-7, מאת Dima Pasechnik: Please make sure to follow this part of the instruction: and including the relevant part of the log file /files3/home/sahosse/sage/spkg/logs/maxima-5.23.2.p3.log Describe your computer, operating system, etc. All one can see from your report so far that your Linux kernel is kind of old. We do not see at all what e.g. your compiler is, or what flavour of Linux you're running. Could you perhaps upload the complete install.log somewhere and post a link to it here? Thanks, Dmitrii On Mar 2, 5:03 pm, syd.lavas...@gmail.com syd.lavas...@gmail.com wrote: Hi there, I saw people talking about this error on Lion. But this machine is linux, so it might be a new error. uname - a Linux msx0 2.6.18-274.12.1.el5 #1 SMP Tue Nov 8 21:37:35 EST 2011 x86_64 x86_64 x86_64 GNU/Linux Error Log: ;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=0 ;;; ;;; End of Pass 1. ;;; Note: ;;; Invoking external command: ;;; gcc -I. -I/files3/home/sahosse/sage/local/include/ -I/files3/ home/sahosse/sage/local/include -I/files3/home/sahosse/sage/local/ include
[sage-devel] Re: Adding GCC and MPC as standard packages
Hi Leif, On 15 Mrz., 08:17, leif not.rea...@online.de wrote: And I forgot: I also upgraded the optional GMP spkg (GMP is required by CLooG). Our old spkg was broken and needed massive patches. I made an spkg based on unpatched GMP 5.0.4 upstream sources. I have no idea what would happen on other platforms, but it worked on openSuse. I'm almost sure CLooG works with MPIR (2.x, with '--enable-gmpcompat', which we pass) as well. How? I mean, what options does one need to pass when one wants to build CLooG-PPL with MPIR? It does not pick it up automatically - when I first tried to build CLooG (not CLooG-PPL) then it failed because it missed GMP. Cheers, Simon -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Adding GCC and MPC as standard packages
On Thursday, 15 March 2012 16:15:09 UTC+8, Simon King wrote: Hi Leif, On 15 Mrz., 08:17, leif not.rea...@online.de wrote: And I forgot: I also upgraded the optional GMP spkg (GMP is required by CLooG). Our old spkg was broken and needed massive patches. I made an spkg based on unpatched GMP 5.0.4 upstream sources. I have no idea what would happen on other platforms, but it worked on openSuse. I'm almost sure CLooG works with MPIR (2.x, with '--enable-gmpcompat', which we pass) as well. IMHO at least MPIR 1.* does not implement all the GMP functionality, i.e. it is not really a drop-in replacement. E.g. GAP 4.5 does not work with MPIR, even though it does work with GMP 5.0.4. Does MPIR 2.* really implement more GMP calls than MPIR 1.* ? How? I mean, what options does one need to pass when one wants to build CLooG-PPL with MPIR? It does not pick it up automatically - when I first tried to build CLooG (not CLooG-PPL) then it failed because it missed GMP. Cheers, Simon -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Basing new development versions of Sage on the previous development version
Okay, I'll think about your suggestion and changing the merger procedure. But I'll be honest that this is not too high on my list of priorities. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Basing new development versions of Sage on the previous development version
On Thursday, 15 March 2012 17:55:31 UTC+8, Jeroen Demeyer wrote: Okay, I'll think about your suggestion and changing the merger procedure. But I'll be honest that this is not too high on my list of priorities. well, I think that Keshav's approach is very important if we want to decrease the huge rate of bitrot we have now with patches that did not make it into a release quickly. As the current scheme of things destroys the history of development, it gets hard to recreate the state of source when the now bit-rotten patch has been working. By the way, is http://hg.sagemath.org/ now officially dead? It didn't change a bit since January or so... Dima -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Basing new development versions of Sage on the previous development version
On Mar 15, 6:34 am, Dima Pasechnik dimp...@gmail.com wrote: On Thursday, 15 March 2012 17:55:31 UTC+8, Jeroen Demeyer wrote: Okay, I'll think about your suggestion and changing the merger procedure. But I'll be honest that this is not too high on my list of priorities. well, I think that Keshav's approach is very important if we want to decrease the huge rate of bitrot we have now with patches that did not make it into a release quickly. As the current scheme of things destroys the history of development, it gets hard to recreate the state of source when the now bit-rotten patch has been working. By the way, ishttp://hg.sagemath.org/now officially dead? It didn't change a bit since January or so... ?? This is only the official release repository, as far as I can tell - and 4.8 was the last official release. I use it a lot because it's faster than pulling up the file on my own computer :) -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Basing new development versions of Sage on the previous development version
On 3/15/12 1:53 AM, Keshav Kini wrote: Please tell me if anything else about what I said, in my previous post(s) or this one, is insufficiently clear - I hope the diagrams are of some help! And of course I welcome comments about the other points I have made as well. 1. First of all, it seemed that maybe the confusion stemmed from maybe not seeing the critical point of your paragraph, which was the *unless* part (emphasized below): - If we switch to git, as I understand we eventually will, patches (commits) made from an older dev release will be considered to not apply (not be mergeable) a lot more often than merely the cases when other people have meanwhile touched the same files - in fact, *always* - **unless** we make development releases based on their predecessors. - Thanks for this email that you sent too. I was writing an email that was about 1/10 as long and about that clear and comprehensive explaining what you explained above. You did a much better job. 2. A big +1 to the process changes you describe, and a big +1 to the long and very comprehensive (and I thought very clear) explanations you are providing. And especially a big +1 to giving us specific technical items to change. Disclaimer: I too have not done a Sage release... 3. Of course, along with everyone else, a very big +1 to Jereon and all the work he has done to streamline the process and encode the release manager logic into great scripts. Thanks, Jason -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Basing new development versions of Sage on the previous development version
On Thursday, 15 March 2012 20:37:36 UTC+8, kcrisman wrote: On Mar 15, 6:34 am, Dima Pasechnik dimp...@gmail.com wrote: On Thursday, 15 March 2012 17:55:31 UTC+8, Jeroen Demeyer wrote: Okay, I'll think about your suggestion and changing the merger procedure. But I'll be honest that this is not too high on my list of priorities. well, I think that Keshav's approach is very important if we want to decrease the huge rate of bitrot we have now with patches that did not make it into a release quickly. As the current scheme of things destroys the history of development, it gets hard to recreate the state of source when the now bit-rotten patch has been working. By the way, ishttp://hg.sagemath.org/now officially dead? It didn't change a bit since January or so... ?? This is only the official release repository, as far as I can tell - and 4.8 was the last official release. I use it a lot because it's faster than pulling up the file on my own computer :) it was just down - probably still the aftermath of that power failure they had... -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Adding GCC and MPC as standard packages
Hi All! On 13 Mrz., 10:00, Jeroen Demeyer jdeme...@cage.ugent.be wrote: Try CFLAGS=-O3 -march=native CXXFLAGS=-O3 -march=native and see if that works. Meanwhile I managed to build the (slightly modified) gcc with graphite, based on * an extension of the standard ppl spkg (build the ppl C interface, #12672, needs review) * an upgrade of the optional gmp spkg (the current version is broken for me, but 5.0.4 works out of the box. See #12661, needs review. * a cloog-ppl spkg (note that cloog itself won't suffice). See #12666, needs review. Then, building all of Sage (all spkgs) with CFLAGS=-O3 -march=native -floop-interchange -floop-strip-mine - floop-block -fno-strict-aliasing CXXFLAGS=-O3 -march=native -floop-interchange -floop-strip-mine - floop-block -fno-strict-aliasing went smoothly (of course, some packages override the flags). And it even seems that the doc tests pass. And now the bad news: Using the above compiler flags, Sage became MASSIVELY slower, by factors of 2 or 3. That's why I interrupted sage - testall after about 54% (there was no error up to that point). Do you have any insight why optimization has such a big negative impact? Even though the optimization thingy seems to be a failure, I still think that we should upgrade the optional gmp spkg (it is broken, at least on my machine), and we should have an optional CLooG-PPL package (which would then require to make our standard PPL spkg build the C interface, rather than just the C++ interface). Cheers, Simon -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] sage.media.wav
Hi, There is a module included in sage called sage.media.wav. It's really bad. I want to remove it despite our deprecation policy, since it is bad. http://trac.sagemath.org/sage_trac/ticket/12673 The history of this ticket is that it was code that Bobby Moretti and Josh Kantor (two UW students) whipped it out in a few hours to help in teaching a class about Fourier transform to high school students, which I added into Sage. This was in maybe 2007 when random things just got added to Sage with no doctests. I doubt anybody is depending on this code, since it seems to barely work. Neither Bobby or Josh are involved in Sage anymore. -- William -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Adding patches to PARI (#12638) needs review
Two patches need to be added to the PARI sources: 1. GCC 4.6.3 miscompiles src/language/init.c on OS X 10.4 PPC (32-bit), because of a problem with pointer arithmetic in stack_base() called in pari_init_functions(). There is an easy work-around by reordering some code in the PARI sources. Related to #12369. 2. PARI's ispower() function gives wrong results when applied to negative numbers. Related to #12116. Please review the PARI spkg at: http://trac.sagemath.org/sage_trac/ticket/12638 Thanks, Jeroen. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Basing new development versions of Sage on the previous development version
Jeroen Demeyer jdeme...@cage.ugent.be writes: Okay, I'll think about your suggestion and changing the merger procedure. But I'll be honest that this is not too high on my list of priorities. Thanks! Again, I would be more than willing to try to make the changes myself, or at least some of them, if I can. Can you confirm that the latest version of your merger script (i.e. the one I should play with) is in /home/jdemeyer/merger12618/ on boxen? Do you have your merger script under any kind of revision control? -Keshav Join us in #sagemath on irc.freenode.net ! -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Basing new development versions of Sage on the previous development version
Dima Pasechnik dimp...@gmail.com writes: well, I think that Keshav's approach is very important if we want to decrease the huge rate of bitrot we have now with patches that did not make it into a release quickly. As the current scheme of things destroys the history of development, it gets hard to recreate the state of source when the now bit-rotten patch has been working. This is really a problem with the fact that we use patch files at all (instead of pushing and pulling), not really related to what I am complaining about in this thread. Don't worry, changing that is on my radar too :) In fact, the ability of `hg qimport` to do fuzzy patching is actually *masking* the problems with the current approach, not exemplifying them. By the way, is http://hg.sagemath.org/ now officially dead? It didn't change a bit since January or so... hg.sagemath.org is only updated when we have an official release. The last official release was 4.8, which was in January :) By the way, this means that we are actually not rewriting public history if by public history one means history on hg.sagemath.org. However, when we are told to base our patches on the development releases, I think it's no longer realistic to say that the commits seen in development releases are not public - and that is where the history rewriting is happening. -Keshav Join us in #sagemath on irc.freenode.net ! -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Basing new development versions of Sage on the previous development version
On 2012-03-15 16:01, Keshav Kini wrote: Thanks! Again, I would be more than willing to try to make the changes myself, or at least some of them, if I can. Can you confirm that the latest version of your merger script (i.e. the one I should play with) is in /home/jdemeyer/merger12618/ on boxen? Yes (in case you're wondering: the 12618 refers to a ticket that this script depends on). I guess you should be looking mostly at merge.sh and notes.sh Do you have your merger script under any kind of revision control? No. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Basing new development versions of Sage on the previous development version
On 3/15/12 10:10 AM, Jeroen Demeyer wrote: Do you have your merger script under any kind of revision control? No. It might make sense to include these scripts with Sage, managed under the sage root repository, for example, or in sage/local/bin. Thanks, Jason -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Basing new development versions of Sage on the previous development version
Jason Grout jason-s...@creativetrax.com writes: On 3/15/12 1:53 AM, Keshav Kini wrote: Please tell me if anything else about what I said, in my previous post(s) or this one, is insufficiently clear - I hope the diagrams are of some help! And of course I welcome comments about the other points I have made as well. 1. First of all, it seemed that maybe the confusion stemmed from maybe not seeing the critical point of your paragraph, which was the *unless* part (emphasized below): - If we switch to git, as I understand we eventually will, patches (commits) made from an older dev release will be considered to not apply (not be mergeable) a lot more often than merely the cases when other people have meanwhile touched the same files - in fact, *always* - **unless** we make development releases based on their predecessors. - Hmm, that would at least explain Georg's analogy to the linux kernel, indeed... On the other hand maybe Georg interpreted based on the previous release to mean something other than what I meant, viz.: If A is a dev release and B is another dev release, when I say that B should be based on A, I mean that the commits in A should be a subset of the commits in B. Maybe Georg thought I meant that the commits in B must all be descendants of the HEAD commit(s) in A (this is not what I mean!). Thanks for this email that you sent too. I was writing an email that was about 1/10 as long and about that clear and comprehensive explaining what you explained above. You did a much better job. 2. A big +1 to the process changes you describe, and a big +1 to the long and very comprehensive (and I thought very clear) explanations you are providing. And especially a big +1 to giving us specific technical items to change. Disclaimer: I too have not done a Sage release... Thanks! Positive feedback is always nice too :) -Keshav Join us in #sagemath on irc.freenode.net ! -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Basing new development versions of Sage on the previous development version
Jason Grout jason-s...@creativetrax.com writes: On 3/15/12 10:10 AM, Jeroen Demeyer wrote: Do you have your merger script under any kind of revision control? No. It might make sense to include these scripts with Sage, managed under the sage root repository, for example, or in sage/local/bin. Is the merger script realistically part of Sage? Only one person actually runs it. (On the other hand we also ship MoinMoin for some reason, even though only one person runs that, too.) And with the current state of our repositories, putting it under revision control in one of them might hurt more than it helps... -Keshav Join us in #sagemath on irc.freenode.net ! -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Sage 4.8 build failed: Error: Failed to build Maxima as an ECL library.
On Mar 15, 12:21 am, syd.lavas...@gmail.com syd.lavas...@gmail.com wrote: The problem is that my home directory is: /files3/home/sahosse/ but I only have execution permission to the directory home: I confirm: $ mkdir /tmp/test $ chmod a-r /tmp/test $ mkdir /tmp/test/a $ touch /tmp/test/a/b $ ls /tmp/test/a/* /tmp/test/a/b $ ecl ECL (Embeddable Common-Lisp) 11.1.1 [...] (directory /tmp/test/a/*) NIL (quit) $ chmod u+r /tmp/test $ ecl ECL (Embeddable Common-Lisp) 11.1.1 [...] (directory /tmp/test/a/*) (#P/tmp/test/a/b) so, changing read permissions on a directory higher up in the tree makes everything below not reachable for directory. The same problem arises for multi-level wildcards in the shell, i.e., ls /tmp/test/*/ * can't find /tmp/test/a/b either if test is not readable. I guess ECL uses the same code for wildcards as it uses for specified path components. I have checked the CLHS and no mention is made of how permissions should be handled by lisp. I guess that is implementation-dependent. From that perspective, ECL could just define that read permission is required on all components of a path in order for it to be reachable, but since that is so incompatible with UNIX, I think they will consider this a bug as well. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Basing new development versions of Sage on the previous development version
On Thu, Mar 15, 2012 at 9:22 AM, Keshav Kini keshav.k...@gmail.com wrote: Jason Grout jason-s...@creativetrax.com writes: On 3/15/12 10:10 AM, Jeroen Demeyer wrote: Do you have your merger script under any kind of revision control? No. It might make sense to include these scripts with Sage, managed under the sage root repository, for example, or in sage/local/bin. Is the merger script realistically part of Sage? Only one person actually runs it. (On the other hand we also ship MoinMoin for some reason, even though only one person runs that, too.) I thought MoinMoin will soon be removed from Sage. And with the current state of our repositories, putting it under revision control in one of them might hurt more than it helps... I definitely think the release management scripts should be shipped with Sage. Your argument against it is: (1) Only one person runs them, which is silly, since this conversation started because more than one person wants to run them, and (2) Our repository sucks, so why bother, which is just counterproductive. -- William -Keshav Join us in #sagemath on irc.freenode.net ! -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Basing new development versions of Sage on the previous development version
On 2012-03-15 17:28, William Stein wrote: I definitely think the release management scripts should be shipped with Sage. I wouldn't mind. I don't feel like this doing this now, though. The current sage-5.0 release is already complicated enough. Maybe something for sage-5.0.1 or sage-5.1. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Basing new development versions of Sage on the previous development version
William Stein wst...@gmail.com writes: On Thu, Mar 15, 2012 at 9:22 AM, Keshav Kini keshav.k...@gmail.com wrote: Jason Grout jason-s...@creativetrax.com writes: On 3/15/12 10:10 AM, Jeroen Demeyer wrote: Do you have your merger script under any kind of revision control? No. It might make sense to include these scripts with Sage, managed under the sage root repository, for example, or in sage/local/bin. Is the merger script realistically part of Sage? Only one person actually runs it. (On the other hand we also ship MoinMoin for some reason, even though only one person runs that, too.) I thought MoinMoin will soon be removed from Sage. There was some discussion about it but I don't think anyone opened a ticket. And with the current state of our repositories, putting it under revision control in one of them might hurt more than it helps... I definitely think the release management scripts should be shipped with Sage. Your argument against it is: (1) Only one person runs them, which is silly, since this conversation started because more than one person wants to run them, and (2) Our repository sucks, so why bother, which is just counterproductive. I'm not arguing against shipping it with Sage. I just brought up some possible reasons why one might not want to do so. The reason I asked whether it was in some repo was that if so, I should be committing to that repo if I change anything. Anyway, you're right that complaining that our repository sucks so why bother is counterproductive. Sorry. The alternative is of course to make our repository suck less, which I will continue to push for... -Keshav Join us in #sagemath on irc.freenode.net -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Basing new development versions of Sage on the previous development version
On Thu, Mar 15, 2012 at 3:34 AM, Dima Pasechnik dimp...@gmail.com wrote: On Thursday, 15 March 2012 17:55:31 UTC+8, Jeroen Demeyer wrote: Okay, I'll think about your suggestion and changing the merger procedure. But I'll be honest that this is not too high on my list of priorities. well, I think that Keshav's approach is very important if we want to decrease the huge rate of bitrot we have now with patches that did not make it into a release quickly. As the current scheme of things destroys the history of development, it gets hard to recreate the state of source when the now bit-rotten patch has been working. +1. Note that this is rather orthogonal from the git vs. hg discussion, right now we're using hg as a glorified diff and patch (and periodically-constructed changelog). By the way, is http://hg.sagemath.org/ now officially dead? It didn't change a bit since January or so... In the current release model, there's no history to push to the the central repository until a final release is cut, as it keeps getting re-written and tossed. Part of this proposal would be that hg.sagemath.org (or its equivalent) would be the actual current development head(s). - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Sage 4.8 build failed: Error: Failed to build Maxima as an ECL library.
In gmane.comp.mathematics.sage.devel, you wrote: On Mar 15, 12:21 am, syd.lavas...@gmail.com syd.lavas...@gmail.com wrote: The problem is that my home directory is: /files3/home/sahosse/ but I only have execution permission to the directory home: I confirm: $ mkdir /tmp/test $ chmod a-r /tmp/test $ mkdir /tmp/test/a $ touch /tmp/test/a/b $ ls /tmp/test/a/* /tmp/test/a/b $ ecl ECL (Embeddable Common-Lisp) 11.1.1 [...] (directory /tmp/test/a/*) NIL (quit) $ chmod u+r /tmp/test $ ecl ECL (Embeddable Common-Lisp) 11.1.1 [...] (directory /tmp/test/a/*) (#P/tmp/test/a/b) so, changing read permissions on a directory higher up in the tree makes everything below not reachable for directory. The same problem arises for multi-level wildcards in the shell, i.e., ls /tmp/test/*/ * can't find /tmp/test/a/b either if test is not readable. I guess ECL uses the same code for wildcards as it uses for specified path components. I have checked the CLHS and no mention is made of how permissions should be handled by lisp. I guess that is implementation-dependent. From that perspective, ECL could just define that read permission is required on all components of a path in order for it to be reachable, but since that is so incompatible with UNIX, I think they will consider this a bug as well. I've sent this to ecls-l...@lists.sourceforge.net as a bug report. Dima -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Wolfram on Reddit
You know, Wolfram has an enormous ego. He thinks he revolutionized science. He thinks he invented computer algebra systems. He thinks he has designed the world's best programming language. 3 strikes. If you want to look for a simple language, you could look at ones aimed at simple people (children). Logo for example. Or you could look at ones with a simple description (Scheme comes to mind). Or even Turing machines or Markov rewriting systems. Or simple to understand (perhaps Scheme again?) Of course some people might think Mathematica is simple. By the same kind of reasoning, solving world hunger is simple: Grow enough food for everyone and give it out. Playing a violin is simple: use one hand to hold down the strings and the other to run the bow back and forth. That is, if you think it is simple, it is because you don't understand it. Now about that natural language stuff. People have proposed to do this for 50 years or so, on and off. That is, use natural language for programming. COBOL (1961). Lots of other ideas, too. Warren Teitelman's thesis work on DWIM. Linguistics specialists with any number of ideas that didn't pan out. I have tried Wolfram's Alpha a number of times, and its natural language understanding seems to be quite deficient, and occasionally laughable. Compound that with the fallibility of humans to be able to express algorithms unambiguously in natural language anyway, and one might reasonably doubt the claims that a front end to Mathematica would make it simple. I just scanned the current wikipedia page on natural language programming. It appears to be a marketing blurb. too bad, wiki pedestrians. RJF On Sunday, March 11, 2012 3:44:22 AM UTC-7, Harald Schilly wrote: On Saturday, March 10, 2012 2:53:25 PM UTC+1, rjf wrote: It is not a simple language. I'm sure you all know more about this than me. Is there a common way to measure this? What I'm thinking about are those grammar dependency trees. From my personal experience and looking at those graphs: narrow trees with not too many nodes are easier to understand, whereas broader trees with more nodes are harder. Here are some examples, e.g. Python is easy, as is JavaScript. Harder is Perl and Ruby; I also found one for Java and C. Might be interesting to create one for MMAs grammar! Python: http://www.flickr.com/photos/nicksieger/281055485/ Ruby, Java, JavaScript: http://antigreen.org/vadim/ProgLanguageComparison/grammar-vizualization/visualization-of-rubys-grammar.html Ansi C: http://c2.com/cgi/wiki?BnfToDot H -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Basing new development versions of Sage on the previous development version
Robert Bradshaw rober...@math.washington.edu writes: On Thu, Mar 15, 2012 at 3:34 AM, Dima Pasechnik dimp...@gmail.com wrote: On Thursday, 15 March 2012 17:55:31 UTC+8, Jeroen Demeyer wrote: Okay, I'll think about your suggestion and changing the merger procedure. But I'll be honest that this is not too high on my list of priorities. well, I think that Keshav's approach is very important if we want to decrease the huge rate of bitrot we have now with patches that did not make it into a release quickly. As the current scheme of things destroys the history of development, it gets hard to recreate the state of source when the now bit-rotten patch has been working. +1. Note that this is rather orthogonal from the git vs. hg discussion, right now we're using hg as a glorified diff and patch (and periodically-constructed changelog). Just to be clear: the git vs. hg discussion, the destroying history of dev releases discussion, and the patches vs. push/pull discussion are all orthogonal to each other, though push/pull exposes the problems with destroying history more clearly than the patches workflow does (as I said in my reply to Dima). Of these three things, IMO the most important is patches vs. push/pull . I really just made this thread in the hopes of getting the destroying history problem out of the way so that it won't stand as a barrier to switching to push/pull (though it is bad in its own right anyway, even when using patches). -Keshav Join us in #sagemath on irc.freenode.net ! -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Wolfram on Reddit
On Sunday, March 11, 2012 3:44:22 AM UTC-7, Harald Schilly wrote: On Saturday, March 10, 2012 2:53:25 PM UTC+1, rjf wrote: It is not a simple language. I'm sure you all know more about this than me. Is there a common way to measure this? What I'm thinking about are those grammar dependency trees. To address this issue more specifically, the complexity of a grammar does not reflect the entire complexity of a language. Scheme is more complicated than its utterly simple grammar would indicate. Mathematica is far more complicated than its utterly complicated (not even written down!) grammar would indicate. The fact that one can teach the IMPLEMENTATION of scheme down to assembly language in a chapter or two of a textbook (Norvig's AI programming book) suggests there is a simplicity to it. RJF -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Wolfram on Reddit
rjf fate...@gmail.com writes: Now about that natural language stuff. People have proposed to do this for 50 years or so, on and off. That is, use natural language for programming. COBOL (1961). Lots of other ideas, too. Warren Teitelman's thesis work on DWIM. Linguistics specialists with any number of ideas that didn't pan out. There is an EWD on just this topic: http://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667.html -Keshav Join us in #sagemath on irc.freenode.net ! -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Docbuild options for sage -docbuild and make doc
Dear Sage doc compilation fans, Currently, make doc calls sage -docbuild with the option --no-pdf-links. I don't have an opinion about this specific option, but a very anoying consequence is that if you do a make and later a sage -docbuild, then all the doc is recompiled (GASP!). And reciprocally. Is there a very good reason to use different options for make doc and sage -docbuild? Otherwise, I vote for having make doc just call sage -docbuild. And I let the expert decide whether they want to throw --no-pdf-links in those default options or not. I volunteer for opening a ticket and implementing it: this will very soon save me time! Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [mpir-devel] Fwd: [sage-devel] Re: Upgrading the optional GMP spkg
We currently test against mpfr-3.0.1.tar.bz2 mpfi-1.5.tar.bz2 mpc-0.9.tar.gz ecm-6.3.tar.gz flint-2.1.tgz pari-2.3.5.tar.gz on all the usual test machines. I can easily add gap and any other smallish packages(sage itself is too big) and/or versions. Jason --- Probably GAP uses some of the GMP internals. As far as I know, we don't test MPIR against GAP. It sounds like we should. Bill. On 14 March 2012 02:55, William Stein wst...@gmail.com wrote: Hi MPIR devs Do any of you know what Dima is alluding to below? -- Forwarded message -- From: Dima Pasechnik dimp...@gmail.com Date: Tue, Mar 13, 2012 at 11:18 AM Subject: [sage-devel] Re: Upgrading the optional GMP spkg To: sage-devel@googlegroups.com On Tuesday, 13 March 2012 21:30:07 UTC+8, Simon King wrote: Hi! I had problems with the optional gmp-4.2.1 spkg. After some half- succeeding attempts to fix it, I tried to upgrade the spkg to the latest upstream code: It works like a charm (i.e., builds and passes self-tests)! If someone is interested: #12661 provides a new gmp-5.0.4.spkg (intended to be optional, of course) and needs review. that's the version of GMP used by GAP 4.5 (they are moving towards using an external longnums package), and I know they recently were working quite a bit with GMP people to get in the right patches. I wish GAP worked with MPIR, but the latter does not provide all the GMP calls used by GAP. It would be good if these were added... Dima The old spkg had a lot of patches. So far, the new applies none of them - on openSuse, the unpatched code passes tests. However, I'd be glad if the patch authors could check whether the fixes (some of them addressing platform specific issues) all made it upstream. According to the old spkg's SPKG.txt, it is needed to upgrade the optional polymake spkg if gmp is upgraded. I haven't tried it. Best regards, Simon -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- William Stein Professor of Mathematics University of Washington http://wstein.org -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-de...@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-de...@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Wolfram on Reddit
On Thursday, March 15, 2012 7:00:10 PM UTC+1, rjf wrote: To address this issue more specifically, the complexity of a grammar does not reflect the entire complexity of a language. yes, i wasn't implying that this is the solve measurement, but i think it is part of it. mathematica's grammar might be real fun! Norvig because you mention him, he is teaching design of computer programs at this udacity online university. http://www.udacity.com/overview/Course/cs212 i'll try to follow it, he is certainly a good guy to deliver some key insights into this whole babylonian tower of programming languages. h -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: sage.media.wav
On Thursday, March 15, 2012 3:55:34 PM UTC+1, William wrote: sage.media.wav ah, i wasn't even aware of that. good idea to remove it if it is just dead code. i actually reply because i was thinking about some more general audio processing capabilities of sage. e.g. loading soundfiles, generating sounds out of formulas, in various ways, exporting them, and even doing manipulations like adding files together or more advanced things like changing the speed - with and without chainging the pitch. also some visualizations. and on top of it all: using html5's audio capabilites to play it in the notebook :-) h -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: sage.media.wav
On Mar 15, 3:42 pm, Harald Schilly harald.schi...@gmail.com wrote: On Thursday, March 15, 2012 3:55:34 PM UTC+1, William wrote: sage.media.wav ah, i wasn't even aware of that. good idea to remove it if it is just dead code. i actually reply because i was thinking about some more general audio processing capabilities of sage. e.g. loading soundfiles, generating sounds out of formulas, in various ways, exporting them, and even doing manipulations like adding files together or more advanced things like changing the speed - with and without chainging the pitch. also some visualizations. and on top of it all: using html5's audio capabilites to play it in the notebook :-) I have tried that a bit while tinkering on an outreach lecture on tunings. I used the audioop standard module for basic plumbing and a pipe to sox to play the sounds (so, not using html5's sound capability, but once you have an audiofile that would be trivial) real- time. To actually produce the waveforms, I ended up writing some cython to produce the right bytestrings (really wordstrings of course). For advertising reasons it might be interesting to have a special sage- module for this stuff, but for actual functionality I think you can cobble together something from standard python components quite easily. Anything that really touches the data will have to be in cython, though, because at, say, 48KHz sampling rate, the data gets bulky quite quickly. What I was really looking for is software that can play, say, a MIDI file in various tunings. There is http://www.huygens-fokker.org/scala/ but I haven't been able to get that to produce sound yet. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Basing new development versions of Sage on the previous development version
Hi Keshav, that's the diagram I have the most stomachache with: (snip) How it would work given current practices - (snip) 5) Another release is made, incorporating the developer's changes (X, M, and Y), but first backing out the changes made in A, with commit D. Pulling in the developer's changes also pulls in the two old copies of A and B and one copy of C from the previous two dev releases. This release now incorporates X, M, Y, D, E, old A, old B, old C, older A, and older B on top of what was in the previous release. A == B == X == M == Y // // \\ /=== A == B == C\\ //\\ o == A == B == C == D = E ^^^ 123 (snip) Please tell me if anything else about what I said, in my previous post(s) or this one, is insufficiently clear - I hope the diagrams are of some help! And of course I welcome comments about the other points I have made as well. -Keshav Well, I'm not perfect, and I know it, and so I appreciate your patience with me, trying make your point(s) clear. Alas, I still have my problems, and I hope to be able on my side to explain those to you. So let's define our entities. There are (a finite set of) releases (say rel0, rel1, relA, ...) for each of which there is a (regression) testsuite (which has to be passed OK as a basic assumption throughout). There are (a finite set of) developer changes (patch sets from trac tickets), called A, B, X, and so on. For the latter, there are the notions of (doc)test, depends on and history. Let's dwell on the depends on notion a bit further, giving a formal definition. 0.) Each developer change A depends on some release, say e.g. relA, and A possibly depends on some other developer changes with respect to (w.r.t) relA. Those other developer changes must depend on the same release relA, and we make it an axiom that every dependency graph (consisting of such an A, relA, and the set of developer changes that A depends on w.r.t relA, and so on, i.e. the closure of those that these depend on w.r.t relA) is a tree, i.e. contains no circular dependencies. A developer change A may depend on several releases rel0, rel1, ... and if this is the case, we may have different respective sets of those developer changes, that A depends on w.r.t. these releases relA, relB, ... We assume throughout that any developer change both can be applied to a release it depends on and is only applied to such a release, if all of the other developer changes it depends on w.r.t. that release, had been applied previously (our axiom makes this feasible/ reasonable). 1.) A developer change B does depend not only on some release rel0, but also depends on developer changes A', A'', A''', ... (possibly only one A) w.r.t. rel0, if B's patch does apply (no merge conflict, or at most a trivial merge conflict, i.e. only trivial fuzziness like shifted line numbers, or whitespace changes) to rel0==A'==A''==A'''==... (rel0 and all those developer changes applied), *but* shows a non-trivial merge conflict when one tries to apply it directly to rel0, i.e. without having these other developer changes applied first. 2.) Some B also depends on some A w.r.t. some release rel0 (even if 1.) is not the case), if any doctest of B is OK in the presence of A (both applied to rel0), but is NOK in the absence of A (B applied to rel0, but not A). 3.) Some B also depends on some A w.r.t some release rel0 (even if 1.) or 2.) or both are not the case), if the testsuite of rel0 is NOK in the presence of B and when A is not present, but the testsuite passes when both A and B are applied (all w.r.t a certain release rel0). (In other words: without A applied first to rel0, B would introduce a regression in the testsuite of rel0.) 4.) Some B does *not* depend on some A w.r.t. a fixed release rel0, if none of the above conditions 1.), 2.), 3.) holds. A developer change has one or more (doc)tests if it's a bugfix, or feature enhancement (possibly no doctest if it's only a spelling correction in a comment ...). If we apply a series of developer changes A, B, C, ... to some release rel0, and after that the testsuite of rel0 still passes OK, as well as all of the new (doc)tests from A, B, C, ... then the result may become a new release rel1, the testsuite of which is the union of the old testsuite and those (doc)tests. Now take up the given example, and say developer Linus has released some (official) release rel0, and later some (development) release rel1 which is just rel0==A==B, i.e. rel0 applied two developer change sets A and B to rel0, none of which depends on the other. (To say it explicitly: A does not depend on B, and B does not depend on A, but both depend on rel0, in the sense defined above. The testsuite of rel1 is the union of the testuite of rel0 and the doctests of A and the doctests of B, passing OK.)
[sage-devel] Re: Docbuild options for sage -docbuild and make doc
On Thursday, March 15, 2012 2:28:02 PM UTC-7, Nicolas M. Thiéry wrote: Dear Sage doc compilation fans, Currently, make doc calls sage -docbuild with the option --no-pdf-links. I don't have an opinion about this specific option, but a very anoying consequence is that if you do a make and later a sage -docbuild, then all the doc is recompiled (GASP!). And reciprocally. Is there a very good reason to use different options for make doc and sage -docbuild? Otherwise, I vote for having make doc just call sage -docbuild. And I let the expert decide whether they want to throw --no-pdf-links in those default options or not. I volunteer for opening a ticket and implementing it: this will very soon save me time! Sounds good to me. I can't figure out when it was introduced, so i don't know why it was introduced, either. Anyone else know? -- John -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Sage 4.8 build failed: Error: Failed to build Maxima as an ECL library.
On Mar 15, 6:44 pm, Dima Pasechnik dimp...@gmail.com wrote: In gmane.comp.mathematics.sage.devel, you wrote: On Mar 15, 12:21 am, syd.lavas...@gmail.com syd.lavas...@gmail.com wrote: The problem is that my home directory is: /files3/home/sahosse/ but I only have execution permission to the directory home: I confirm: $ mkdir /tmp/test $ chmod a-r /tmp/test $ mkdir /tmp/test/a $ touch /tmp/test/a/b $ ls /tmp/test/a/* /tmp/test/a/b $ ecl ECL (Embeddable Common-Lisp) 11.1.1 [...] (directory /tmp/test/a/*) NIL (quit) $ chmod u+r /tmp/test $ ecl ECL (Embeddable Common-Lisp) 11.1.1 [...] (directory /tmp/test/a/*) (#P/tmp/test/a/b) so, changing read permissions on a directory higher up in the tree makes everything below not reachable for directory. The same problem arises for multi-level wildcards in the shell, i.e., ls /tmp/test/*/ * can't find /tmp/test/a/b either if test is not readable. I guess ECL uses the same code for wildcards as it uses for specified path components. I have checked the CLHS and no mention is made of how permissions should be handled by lisp. I guess that is implementation-dependent. From that perspective, ECL could just define that read permission is required on all components of a path in order for it to be reachable, but since that is so incompatible with UNIX, I think they will consider this a bug as well. I've sent this to ecls-l...@lists.sourceforge.net as a bug report. Btw, you run into similar problems if you happen to have HOME set but the directory doesn't exist (e.g. because /home isn't mounted); ECL insists on being at least able to *read* your home directory. -leif -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Docbuild options for sage -docbuild and make doc
On Mar 16, 1:00 am, John H Palmieri jhpalmier...@gmail.com wrote: On Thursday, March 15, 2012 2:28:02 PM UTC-7, Nicolas M. Thiéry wrote: Dear Sage doc compilation fans, Currently, make doc calls sage -docbuild with the option --no-pdf-links. I don't have an opinion about this specific option, but a very anoying consequence is that if you do a make and later a sage -docbuild, then all the doc is recompiled (GASP!). And reciprocally. Is there a very good reason to use different options for make doc and sage -docbuild? Otherwise, I vote for having make doc just call sage -docbuild. And I let the expert decide whether they want to throw --no-pdf-links in those default options or not. I volunteer for opening a ticket and implementing it: this will very soon save me time! Sounds good to me. I can't figure out when it was introduced, so i don't know why it was introduced, either. Anyone else know? A quick search on sage-release reveals #10811: by default build HTML doc without PDF links [1] IIRC there's repeatedly been discussion about this (on sage-release); the ticket only refers to the following short sage-devel thread: http://groups.google.com/group/sage-devel/browse_thread/thread/04c3d373d5451a96 (So there's a reason we do use '--no-pdf-links'... ;-) ) -leif [1] http://trac.sagemath.org/sage_trac/ticket/10811 -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: [mpir-devel] Fwd: Re: Upgrading the optional GMP spkg
In gmane.comp.mathematics.sage.devel, you wrote: We currently test against mpfr-3.0.1.tar.bz2 mpfi-1.5.tar.bz2 mpc-0.9.tar.gz ecm-6.3.tar.gz flint-2.1.tgz pari-2.3.5.tar.gz on all the usual test machines. I can easily add gap and any other smallish packages(sage itself is too big) and/or versions. GAP 4.5 is still unreleased, although coming close to being released; I can get you a snapshot. Send me an email then (I can't put an URL in the open here). Dima Jason --- Probably GAP uses some of the GMP internals. As far as I know, we don't test MPIR against GAP. It sounds like we should. Bill. On 14 March 2012 02:55, William Stein wst...@gmail.com wrote: Hi MPIR devs Do any of you know what Dima is alluding to below? -- Forwarded message -- From: Dima Pasechnik dimp...@gmail.com Date: Tue, Mar 13, 2012 at 11:18 AM Subject: [sage-devel] Re: Upgrading the optional GMP spkg To: sage-devel@googlegroups.com On Tuesday, 13 March 2012 21:30:07 UTC+8, Simon King wrote: Hi! I had problems with the optional gmp-4.2.1 spkg. After some half- succeeding attempts to fix it, I tried to upgrade the spkg to the latest upstream code: It works like a charm (i.e., builds and passes self-tests)! If someone is interested: #12661 provides a new gmp-5.0.4.spkg (intended to be optional, of course) and needs review. that's the version of GMP used by GAP 4.5 (they are moving towards using an external longnums package), and I know they recently were working quite a bit with GMP people to get in the right patches. I wish GAP worked with MPIR, but the latter does not provide all the GMP calls used by GAP. It would be good if these were added... Dima The old spkg had a lot of patches. So far, the new applies none of them - on openSuse, the unpatched code passes tests. However, I'd be glad if the patch authors could check whether the fixes (some of them addressing platform specific issues) all made it upstream. According to the old spkg's SPKG.txt, it is needed to upgrade the optional polymake spkg if gmp is upgraded. I haven't tried it. Best regards, Simon -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- William Stein Professor of Mathematics University of Washington http://wstein.org -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-de...@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-de...@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Basing new development versions of Sage on the previous development version
Should we invite Linus to do a demo release for us (unless Jeroen objects)? /me *hides* -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Docbuild options for sage -docbuild and make doc
On Mar 16, 1:32 am, leif not.rea...@online.de wrote: On Mar 16, 1:00 am, John H Palmieri jhpalmier...@gmail.com wrote: On Thursday, March 15, 2012 2:28:02 PM UTC-7, Nicolas M. Thiéry wrote: Dear Sage doc compilation fans, Currently, make doc calls sage -docbuild with the option --no-pdf-links. I don't have an opinion about this specific option, but a very anoying consequence is that if you do a make and later a sage -docbuild, then all the doc is recompiled (GASP!). And reciprocally. Is there a very good reason to use different options for make doc and sage -docbuild? Otherwise, I vote for having make doc just call sage -docbuild. And I let the expert decide whether they want to throw --no-pdf-links in those default options or not. I volunteer for opening a ticket and implementing it: this will very soon save me time! Sounds good to me. I can't figure out when it was introduced, so i don't know why it was introduced, either. Anyone else know? A quick search on sage-release reveals #10811: by default build HTML doc without PDF links [1] IIRC there's repeatedly been discussion about this (on sage-release); the ticket only refers to the following short sage-devel thread: http://groups.google.com/group/sage-devel/browse_thread/thread/04c3d3... (So there's a reason we do use '--no-pdf-links'... ;-) ) -leif [1]http://trac.sagemath.org/sage_trac/ticket/10811 P.S.: Perhaps the opportunity to introduce yet another Sage environment variable; to be set in ~/.sagerc of course! -leif -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: sage.media.wav
See also http://trac.sagemath.org/sage_trac/ticket/7668 for a related ticket. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Building a deb for sage on Debian/Ubuntu
On Thu, 15 Mar 2012 at 07:13AM +0100, Jan Groenewald wrote: Thanks, I will look into it. Are the steps to reproduce 1) install new OS, 2) install Sage from PPA, 3) run sage as user? What I have done is (this happens every time): 1. Remove $HOME/.sage 2. Reinstall Sage from PPA 3. New $HOME/.sage is root-owned. If I have an existing $HOME/.sage owned by the user, I get a root-owned file when reinstalling the PPA package: the lazy_import_cache.pickle file. An update on the previous dpkg version problem. I have dropped lucid support on that PPA, as it is the only Ubuntu version requiring an older dpkg, and that older dpkg does not support xz compression. The difference between xz compression and gz compression is roughly 80M for the deb alone. dpkg 1.15.6 started supporting this. Dropping Lucid is a good idea. Focus on getting this to work on Precise, and then see if we can do a source PPA. Dan -- --- Dan Drake - http://mathsci.kaist.ac.kr/~drake --- signature.asc Description: Digital signature
[sage-devel] moving sage.misc.fpickle to another python module
Currently the installation of Sage python module (setup.py), built when sage-***.spkg is installed, is using twisted.persisted.styles to allow class instances to be pickled. Basically, a duplicate (slightly more efficient, as it is Cython) of this functionality is also in sage.misc.fpickle But (IMHO, I am not a huge expert on this) the latter cannot be used during the installation, some kind of chicken vs. egg problem. Thus, as we want twisted to be removed from Sage (#11874) we need the functionality of sage.misc.fpickle to be available during the installation of sage-***.spkg. One way to achieve it is to put it somewhere else, in a Python module built and installed before Sage Python module. Another way is to include a Python module with this functionality inside sage-***.spkg, to be used for installation only. Any idea as to how is the best to proceed? Dima -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
