[sage-combinat-devel] sage-combinat queue
Hi! The queue currently does not seem to apply to sage-4.8: ... applying trac_8-finite_enumset_list_cache-fh.patch skipping trac_10998_prerebase-cs.patch - guarded by ['+4_7_2'] skipping trac_10998-categories-posets-nt.patch - guarded by '-5_0' applying trac_10998-categories-posets-review-fh.patch patching file sage/combinat/posets/posets.py Hunk #1 FAILED at 233 1 out of 1 hunks FAILED -- saving rejects to file sage/combinat/posets/posets.py.rej patching file sage/misc/sageinspect.py Hunk #1 FAILED at 949 1 out of 1 hunks FAILED -- saving rejects to file sage/misc/sageinspect.py.rej patch failed, unable to continue (try -v) patch failed, rejects left in working dir errors during apply, please fix and refresh trac_10998-categories-posets-review-fh.patch Abort 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-devel] Dealing with different signs in doctest output?
What is the correct way to fix the following doctest failure? Here, G is the result of a gram_schmidt() computation, hence the sign shouldn't matter mathematically. sage -t -force_lib devel/sage/sage/matrix/matrix2.pyx ** File /Users/jdemeyer/sage-5.0.beta1-gcc/devel/sage-main/sage/matrix/matrix2.pyx, line 7983: sage: G.round(6) Expected: [-0.422243 - 0.490087*I 0.566698 - 0.097416*I -0.500882 + 0.002251*I] [-0.057002 - 0.495035*I -0.35059 - 0.625323*I 0.255514 - 0.415284*I] [ 0.394105 - 0.421778*I -0.392266 - 0.039345*I -0.352905 + 0.62195*I] Got: [ 0.422243 + 0.490087*I -0.566698 + 0.097416*I 0.500882 - 0.002251*I] [ 0.057002 + 0.495035*I 0.35059 + 0.625323*I -0.255514 + 0.415284*I] [-0.394105 + 0.421778*I 0.392266 + 0.039345*I 0.352905 - 0.62195*I] ** (this happens on OS X 10.7 systems, at least with a custom GCC, see #12456) -- 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: Dealing with different signs in doctest output?
On Tuesday, February 7, 2012 2:49:36 AM UTC-8, Jeroen Demeyer wrote: What is the correct way to fix the following doctest failure? Here, G is the result of a gram_schmidt() computation, hence the sign shouldn't matter mathematically. sage -t -force_lib devel/sage/sage/matrix/matrix2.pyx ** File /Users/jdemeyer/sage-5.0.beta1-gcc/devel/sage-main/sage/matrix/matrix2.pyx, line 7983: sage: G.round(6) Expected: [-0.422243 - 0.490087*I 0.566698 - 0.097416*I -0.500882 + 0.002251*I] [-0.057002 - 0.495035*I -0.35059 - 0.625323*I 0.255514 - 0.415284*I] [ 0.394105 - 0.421778*I -0.392266 - 0.039345*I -0.352905 + 0.62195*I] Got: [ 0.422243 + 0.490087*I -0.566698 + 0.097416*I 0.500882 - 0.002251*I] [ 0.057002 + 0.495035*I 0.35059 + 0.625323*I -0.255514 + 0.415284*I] [-0.394105 + 0.421778*I 0.392266 + 0.039345*I 0.352905 - 0.62195*I] ** (this happens on OS X 10.7 systems, at least with a custom GCC, see #12456) I suppose we could have a list of acceptable matrices, and then the test could be sage: G.round(6) in LIST Or as part of the doctest normalize G.round(6): multiply by -1 if the real part of the (0,0) entry is positive. If it gets too complicated, maybe it should be moved to a TESTS block instead of an EXAMPLES block. I wonder what part of the algorithm leads to a difference choice of sign on this one platform. -- 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: Dealing with different signs in doctest output?
On 2/7/12 9:34 AM, John H Palmieri wrote: Or as part of the doctest normalize G.round(6): multiply by -1 if the real part of the (0,0) entry is positive. If it gets too complicated, maybe it should be moved to a TESTS block instead of an EXAMPLES block. I wonder what part of the algorithm leads to a difference choice of sign on this one platform. so something like: sage: G.round(6)*sgn(G[0,0].real()) 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
Re: [sage-devel] Re: Dealing with different signs in doctest output?
On 07/02/2012 15:43, Jason Grout wrote: On 2/7/12 9:34 AM, John H Palmieri wrote: Or as part of the doctest normalize G.round(6): multiply by -1 if the real part of the (0,0) entry is positive. If it gets too complicated, maybe it should be moved to a TESTS block instead of an EXAMPLES block. I wonder what part of the algorithm leads to a difference choice of sign on this one platform. so something like: sage: G.round(6)*sgn(G[0,0].real()) Thanks, Jason These are quite ugly solutions. How do people feel about having a solution analogous to #10952? http://trac.sagemath.org/sage_trac/ticket/10952 For example, let # sign variation ignore every +, -, and space in the output string. Marco -- 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: Dealing with different signs in doctest output?
On 2/7/12 9:55 AM, Marco Streng wrote: On 07/02/2012 15:43, Jason Grout wrote: On 2/7/12 9:34 AM, John H Palmieri wrote: Or as part of the doctest normalize G.round(6): multiply by -1 if the real part of the (0,0) entry is positive. If it gets too complicated, maybe it should be moved to a TESTS block instead of an EXAMPLES block. I wonder what part of the algorithm leads to a difference choice of sign on this one platform. so something like: sage: G.round(6)*sgn(G[0,0].real()) Thanks, Jason These are quite ugly solutions. How do people feel about having a solution analogous to #10952? http://trac.sagemath.org/sage_trac/ticket/10952 For example, let # sign variation ignore every +, -, and space in the output string. But then it would consider the two vectors (-1,2) and (-1,-2) to be the same, which is not what we want. 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: Dealing with different signs in doctest output?
How about testig for the desired mathematical properties? If this is a Gram-Schmidt test, the resulting matrix M should be orthogonal, so we can test for M*M.transpose() being the identity matrix (up to numerical accuracy). Of course, this type of indirect test should belong to the test section, not to the examples section. Cheers, Javier -- 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: Saving GAP objects across sessions
Hi Dima, I didn't know about CodePcgs, thanks for bringing it up! This workaround has the disadvantage that one must re-generate the groups each time, which is an annoyance I can live with for now I guess. Is there any advantage in saving the CodePcgs rather than the Small Group Library ID? In your example, why would one want to save the tuple (5790338948, 24) rather than (24, 12)? Cheers, Javier On 7 feb, 01:53, Dima Pasechnik dimp...@gmail.com wrote: A workaround is to use GAP facilities to encode a pc group using a pair of integers. Cutting from the GAP manual on CodePcgs gap G := SmallGroup( 24, 12 );; gap p := Pcgs( G );; gap code := CodePcgs( p ); 5790338948 gap H := PcGroupCode( code, 24 ); pc group of size 24 with 4 generators gap map := GroupHomomorphismByImages( G, H, p, FamilyPcgs(H) ); Pcgs([ f1, f2, f3, f4 ]) - Pcgs([ f1, f2, f3, f4 ]) gap IsBijective(map); true That is, in Sage you'd do sage: G = gap.SmallGroup( 24, 12 ) sage: code=gap.CodePcgs(gap.Pcgs( G )) sage: code 5790338948 (and you can easily store 24 and 5790338948), and then recover them: sage: gap.PcGroupCode(code,24) Group( [ f1, f2, f3, f4 ] ) HTH, 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
Re: [sage-devel] use ./configure; make for Sage?
On Mon, Feb 6, 2012 at 3:42 PM, Dr. David Kirkby david.kir...@onetel.net wrote: On 02/ 6/12 09:09 AM, Jeroen Demeyer wrote: On 2012-02-06 09:33, Dr. David Kirkby wrote: I think trying to replicate autotools would be just silly. That's what PARI tried and they are probably the spkg with the *most* patches to the configuration system. More fool them. I am not suggesting *replicating* autotools. I'm suggesting that we should clearly identify exactly what this ./configure is supposed to accomplish before deciding on what tool to use to implement it. Autconf may or may not be the right choice. -- William -- 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: Saving GAP objects across sessions
On Wednesday, February 8, 2012 12:18:17 AM UTC+8, javier wrote: Hi Dima, I didn't know about CodePcgs, thanks for bringing it up! This workaround has the disadvantage that one must re-generate the groups each time, which is an annoyance I can live with for now I guess. Is there any advantage in saving the CodePcgs rather than the Small Group Library ID? In your example, why would one want to save the tuple (5790338948, 24) rather than (24, 12)? well, not every pc group lives in Small Group Library. :-) Surely, if all your groups are there, the ID will do... 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
Re: [sage-devel] Re: Dealing with different signs in doctest output?
On 07/02/2012 16:06, Jason Grout wrote: On 2/7/12 9:55 AM, Marco Streng wrote: On 07/02/2012 15:43, Jason Grout wrote: On 2/7/12 9:34 AM, John H Palmieri wrote: Or as part of the doctest normalize G.round(6): multiply by -1 if the real part of the (0,0) entry is positive. If it gets too complicated, maybe it should be moved to a TESTS block instead of an EXAMPLES block. I wonder what part of the algorithm leads to a difference choice of sign on this one platform. so something like: sage: G.round(6)*sgn(G[0,0].real()) Thanks, Jason These are quite ugly solutions. How do people feel about having a solution analogous to #10952? http://trac.sagemath.org/sage_trac/ticket/10952 For example, let # sign variation ignore every +, -, and space in the output string. But then it would consider the two vectors (-1,2) and (-1,-2) to be the same, which is not what we want. Jason True, that is the biggest downside of this solution. But examples should be illustrative. It would be a shame to have a documentation of a function without any printed examples of the output of the function. Users may want to see what the output is supposed to look like, as a way of understanding what a function does. We can always add another test like M*M.transpose() below it if we really are afraid of getting (-1,-2) instead of (-1, 2). -- 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: Dealing with different signs in doctest output?
On Tue, Feb 7, 2012 at 8:11 AM, javier vengor...@gmail.com wrote: How about testig for the desired mathematical properties? If this is a Gram-Schmidt test, the resulting matrix M should be orthogonal, so we can test for M*M.transpose() being the identity matrix (up to numerical accuracy). Of course, this type of indirect test should belong to the test section, not to the examples section. +1, this is the best way to test it. However, this kind of of indirect test is exactly the thing that *should* go in the examples section (whether or not it's needed for testing), as it is a good illustration of what the expected mathematical properties are. (In fact I consider tests like this to be much better than here's the answer tests; one could take the Gram-Schmidt of a random 100x100 matrix and verify it's nearly orthogonal rather than print out the meaningless coefficients themselves.) - 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
Re: [sage-devel] Re: Are the Sage binaries for OS X are crap?
Hi, I just got yet another (almost daily now) bug report about our OS X binaries being complete crap. This time from a Fields Medalist! So why don't we deal with this? The traceback he sent me is exactly the same as the one that started this thread.This is really stupid. -- William On Sun, Feb 5, 2012 at 9:07 AM, Ivan Andrus darthand...@gmail.com wrote: FWIW you should be able to work around the problem by opening Terminal.app before starting sage. At least if it's the manifestation of the problem that I think it is. -Ivan On Feb 4, 2012, at 7:52 PM, Mike OS wrote: Just corroborating. I encountered the same problem this week installing sage for the first time on a laptop running 10.6.8. I had no problem installing on a imac running 10.6.8 that already had an older copy of sage. -- 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 -- 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] log messages
Hi, I just did hg log and I'm concerned with the way ticket numbers appear in log messages. Here's the top few in sage-5.0.beta2: summary: Trac #12396: #12396: these whitespace changes are needed for the new doctest framework summary: Trac #12390: trac 12390 -- the documentation for number_of_partitions mentions a summary: Trac #10333: #10333: Optional interface to Anders Buch's LR calculator summary: Trac #12094: Bump Maxima to 5.24.0. summary: Trac #10959: Trac 10959: add_edge automatically adds newly created vertex to some partition summary: Trac #6804: Trac #6804: change '=' to '=' in the docstring for Permutation.weak_excedences() summary: Trac #12068: Reviewer patch fixing trivial formatting issue summary: Trac #12068: #12068: Numerator for symbolic expression should'nt us Basically, all but one of them is redundant, in many different ways. Even if the person making the patch puts -- what appears I guess -- to be the canonical format, they still get another copy of that prepended (Trac #6804: Trac #6804:).This has been the case for almost every commit message for well over a year. What's going on here? It's important (in fact, critical) that the trac ticket number is clearly available in the commit message. But having it twice in two different ways in almost every message seems a little bit sloppy to me. The first Trac #num message is probably being added by some script that Jereon wrote... maybe that script needs to be a little more sophisticated? - 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] Re: log messages
Hi William, On 7 Feb., 20:47, William Stein wst...@gmail.com wrote: It's important (in fact, critical) that the trac ticket number is clearly available in the commit message. But having it twice in two different ways in almost every message seems a little bit sloppy to me. We were told, by different release managers, that the commit message has to identify the ticket number. Patches not following the rule were rejected. If that rule has changed in the meantime, the new rule (Do not mention the ticket number in your commit message!) should be enforced in the same way as the old rule was enforced. 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] use ./configure; make for Sage?
Le Tue, 7 Feb 2012 08:38:16 -0800, William Stein wst...@gmail.com a écrit : On Mon, Feb 6, 2012 at 3:42 PM, Dr. David Kirkby david.kir...@onetel.net wrote: On 02/ 6/12 09:09 AM, Jeroen Demeyer wrote: On 2012-02-06 09:33, Dr. David Kirkby wrote: I think trying to replicate autotools would be just silly. That's what PARI tried and they are probably the spkg with the *most* patches to the configuration system. More fool them. I am not suggesting *replicating* autotools. I'm suggesting that we should clearly identify exactly what this ./configure is supposed to accomplish before deciding on what tool to use to implement it. Autconf may or may not be the right choice. Let me first start by saying that I disagree with calling pari developpers fools! A configure script is there to make the sources ready for compilation. Once you have configured the sources, they are supposed to just build. So it's the place where you detect what kind of hardware you're targetting (endianness, size and number of registers, availability of floating-point or vector units, etc), what kind of software you have available for the build (compilers, libraries, presence and version), what kind of software you have available for the runtime (which may not be the same). An autotools based build system has nice properties when done right : - the autotools need not be installed on a system to be used, ie: the sage developpers will need them to generate the configure script, but they are not needed to run the configure script ; - they handle out-of-tree builds nicely ; those can be used to build a same source code with different options (including the next point) ; - they make it easier to cross-build for another architecture ; - the different distributions' maintainers have it easy to package your software ; - they help with portability, as they handle a huge amount of different things. Snark on #sagemath -- 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: log messages
On Tue, Feb 7, 2012 at 12:00 PM, Simon King simon.k...@uni-jena.de wrote: Hi William, On 7 Feb., 20:47, William Stein wst...@gmail.com wrote: It's important (in fact, critical) that the trac ticket number is clearly available in the commit message. But having it twice in two different ways in almost every message seems a little bit sloppy to me. We were told, by different release managers, that the commit message has to identify the ticket number. Patches not following the rule were rejected. If that rule has changed in the meantime, the new rule (Do not mention the ticket number in your commit message!) should be enforced in the same way as the old rule was enforced. I think the commit message should mention the ticket number. This makes it much easier to keep track of stuff, even before the release manager puts the code in Sage. E.g., I have a big patch queue of my own code, and I find the ticket numbers in commit messages useful. What I'm suggesting is that the script that auto-adds ticket numbers should strip the user-added ticket number first, to avoid extensive duplication. 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 -- 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: log messages
On Tue, Feb 7, 2012 at 12:08 PM, William Stein wst...@gmail.com wrote: On Tue, Feb 7, 2012 at 12:00 PM, Simon King simon.k...@uni-jena.de wrote: Hi William, On 7 Feb., 20:47, William Stein wst...@gmail.com wrote: It's important (in fact, critical) that the trac ticket number is clearly available in the commit message. But having it twice in two different ways in almost every message seems a little bit sloppy to me. We were told, by different release managers, that the commit message has to identify the ticket number. Patches not following the rule were rejected. If that rule has changed in the meantime, the new rule (Do not mention the ticket number in your commit message!) should be enforced in the same way as the old rule was enforced. I think the commit message should mention the ticket number. This makes it much easier to keep track of stuff, even before the release manager puts the code in Sage. E.g., I have a big patch queue of my own code, and I find the ticket numbers in commit messages useful. What I'm suggesting is that the script that auto-adds ticket numbers should strip the user-added ticket number first, to avoid extensive duplication. Or at the very least not add it if it's not already there. (Stripping it in all its variants might be hard.) - 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: log messages
On 2/7/12 2:16 PM, Robert Bradshaw wrote: On Tue, Feb 7, 2012 at 12:08 PM, William Steinwst...@gmail.com wrote: On Tue, Feb 7, 2012 at 12:00 PM, Simon Kingsimon.k...@uni-jena.de wrote: Hi William, On 7 Feb., 20:47, William Steinwst...@gmail.com wrote: It's important (in fact, critical) that the trac ticket number is clearly available in the commit message. But having it twice in two different ways in almost every message seems a little bit sloppy to me. We were told, by different release managers, that the commit message has to identify the ticket number. Patches not following the rule were rejected. If that rule has changed in the meantime, the new rule (Do not mention the ticket number in your commit message!) should be enforced in the same way as the old rule was enforced. I think the commit message should mention the ticket number. This makes it much easier to keep track of stuff, even before the release manager puts the code in Sage. E.g., I have a big patch queue of my own code, and I find the ticket numbers in commit messages useful. What I'm suggesting is that the script that auto-adds ticket numbers should strip the user-added ticket number first, to avoid extensive duplication. Or at the very least not add it if it's not already there. (Stripping it in all its variants might be hard.) On the other hand, I think the canonical number should be the automatically prepended number, and that the prepended number should *always* be added: 1. Its format is consistent, so we can write scripts and things that take advantage of that consistency 2. It's guaranteed to be correct, i.e., to reflect what ticket the patch was actually pulled from (in case patches move from ticket to ticket or the user makes a mistake). When I do hg log with my patches, I get output like this: changeset: 16483:722b00d2890c tag: trac-12229-manifest.patch user:Jason Grout jason.gr...@drake.edu date:Mon Jan 16 15:13:16 2012 -0600 summary: Patch MANIFEST.in to copy the .inc and .png sagenb doc files Notice that the tag field gives the filename. That's a great place to put the ticket number (in the filename). You then see the ticket number when you do hg queues commands, you see it in hg log, you see it in the patches directory, you see it on trac and when uploading, etc. The summary does not contain the ticket number---that is added when the ticket is merged. 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
Re: [sage-devel] Re: log messages
On Tue, Feb 7, 2012 at 12:28 PM, Jason Grout jason-s...@creativetrax.com wrote: On 2/7/12 2:16 PM, Robert Bradshaw wrote: On Tue, Feb 7, 2012 at 12:08 PM, William Steinwst...@gmail.com wrote: On Tue, Feb 7, 2012 at 12:00 PM, Simon Kingsimon.k...@uni-jena.de wrote: Hi William, On 7 Feb., 20:47, William Steinwst...@gmail.com wrote: It's important (in fact, critical) that the trac ticket number is clearly available in the commit message. But having it twice in two different ways in almost every message seems a little bit sloppy to me. We were told, by different release managers, that the commit message has to identify the ticket number. Patches not following the rule were rejected. If that rule has changed in the meantime, the new rule (Do not mention the ticket number in your commit message!) should be enforced in the same way as the old rule was enforced. I think the commit message should mention the ticket number. This makes it much easier to keep track of stuff, even before the release manager puts the code in Sage. E.g., I have a big patch queue of my own code, and I find the ticket numbers in commit messages useful. What I'm suggesting is that the script that auto-adds ticket numbers should strip the user-added ticket number first, to avoid extensive duplication. Or at the very least not add it if it's not already there. (Stripping it in all its variants might be hard.) On the other hand, I think the canonical number should be the automatically prepended number, and that the prepended number should *always* be added: Are you arguing that this from hg log is a good commit message? summary: Trac #6804: Trac #6804: change '=' to '=' in the docstring for Permutation.weak_excedences() 1. Its format is consistent, so we can write scripts and things that take advantage of that consistency 2. It's guaranteed to be correct, i.e., to reflect what ticket the patch was actually pulled from (in case patches move from ticket to ticket or the user makes a mistake). When I do hg log with my patches, I get output like this: changeset: 16483:722b00d2890c tag: trac-12229-manifest.patch user: Jason Grout jason.gr...@drake.edu date: Mon Jan 16 15:13:16 2012 -0600 summary: Patch MANIFEST.in to copy the .inc and .png sagenb doc files Notice that the tag field gives the filename. That's a great place to put the ticket number (in the filename). You then see the ticket number when you do hg queues commands, you see it in hg log, you see it in the patches directory, you see it on trac and when uploading, etc. The summary does not contain the ticket number---that is added when the ticket is merged. If I then qfinish the patch, that tag vanishes, right? At least if I simply import the patch then it vanishes. -- William 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 -- 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] Re: log messages
On 2/7/12 2:46 PM, William Stein wrote: On Tue, Feb 7, 2012 at 12:28 PM, Jason Grout jason-s...@creativetrax.com wrote: On 2/7/12 2:16 PM, Robert Bradshaw wrote: On Tue, Feb 7, 2012 at 12:08 PM, William Steinwst...@gmail.comwrote: On Tue, Feb 7, 2012 at 12:00 PM, Simon Kingsimon.k...@uni-jena.de wrote: Hi William, On 7 Feb., 20:47, William Steinwst...@gmail.comwrote: It's important (in fact, critical) that the trac ticket number is clearly available in the commit message. But having it twice in two different ways in almost every message seems a little bit sloppy to me. We were told, by different release managers, that the commit message has to identify the ticket number. Patches not following the rule were rejected. If that rule has changed in the meantime, the new rule (Do not mention the ticket number in your commit message!) should be enforced in the same way as the old rule was enforced. I think the commit message should mention the ticket number. This makes it much easier to keep track of stuff, even before the release manager puts the code in Sage. E.g., I have a big patch queue of my own code, and I find the ticket numbers in commit messages useful. What I'm suggesting is that the script that auto-adds ticket numbers should strip the user-added ticket number first, to avoid extensive duplication. Or at the very least not add it if it's not already there. (Stripping it in all its variants might be hard.) On the other hand, I think the canonical number should be the automatically prepended number, and that the prepended number should *always* be added: Are you arguing that this from hg log is a good commit message? summary: Trac #6804: Trac #6804: change '=' to '=' in the docstring for Permutation.weak_excedences() Given the choice between unreliable and inconsistently formatted ticket numbers that require manual maintenance, compared to automatic, correct, and consistent numbers, I'd choose the latter, even if it meant that sometimes the number is duplicated. I would rather the script try to strip out the ticket number if it already exists, replacing it with a properly formatted automatically generated ticket number, rather than trying to decide whether to prepend the ticket number. In other words, I think the final commit message should contain an automatically-generated, consistently formatted ticket number. My post was more about advocating the opposite of Robert's suggestion (i.e., I think we should always prepend, and decide whether you should strip out the existing number), than arguing against making the script smarter. 1. Its format is consistent, so we can write scripts and things that take advantage of that consistency 2. It's guaranteed to be correct, i.e., to reflect what ticket the patch was actually pulled from (in case patches move from ticket to ticket or the user makes a mistake). When I do hg log with my patches, I get output like this: changeset: 16483:722b00d2890c tag: trac-12229-manifest.patch user:Jason Groutjason.gr...@drake.edu date:Mon Jan 16 15:13:16 2012 -0600 summary: Patch MANIFEST.in to copy the .inc and .png sagenb doc files Notice that the tag field gives the filename. That's a great place to put the ticket number (in the filename). You then see the ticket number when you do hg queues commands, you see it in hg log, you see it in the patches directory, you see it on trac and when uploading, etc. The summary does not contain the ticket number---that is added when the ticket is merged. If I then qfinish the patch, that tag vanishes, right? At least if I simply import the patch then it vanishes. Good question. I operate under the assumption that a developer never qfinishes a patch; it's the release manager's job to commit the patch. I don't know what happens when you qfinish the patch. Obviously the release manager script isn't run in that case. 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
Re: [sage-devel] Re: log messages
On Tue, Feb 7, 2012 at 12:59 PM, Jason Grout jason-s...@creativetrax.com wrote: On 2/7/12 2:46 PM, William Stein wrote: On Tue, Feb 7, 2012 at 12:28 PM, Jason Grout jason-s...@creativetrax.com wrote: On 2/7/12 2:16 PM, Robert Bradshaw wrote: On Tue, Feb 7, 2012 at 12:08 PM, William Steinwst...@gmail.com wrote: On Tue, Feb 7, 2012 at 12:00 PM, Simon Kingsimon.k...@uni-jena.de wrote: Hi William, On 7 Feb., 20:47, William Steinwst...@gmail.com wrote: It's important (in fact, critical) that the trac ticket number is clearly available in the commit message. But having it twice in two different ways in almost every message seems a little bit sloppy to me. We were told, by different release managers, that the commit message has to identify the ticket number. Patches not following the rule were rejected. If that rule has changed in the meantime, the new rule (Do not mention the ticket number in your commit message!) should be enforced in the same way as the old rule was enforced. I think the commit message should mention the ticket number. This makes it much easier to keep track of stuff, even before the release manager puts the code in Sage. E.g., I have a big patch queue of my own code, and I find the ticket numbers in commit messages useful. What I'm suggesting is that the script that auto-adds ticket numbers should strip the user-added ticket number first, to avoid extensive duplication. Or at the very least not add it if it's not already there. (Stripping it in all its variants might be hard.) On the other hand, I think the canonical number should be the automatically prepended number, and that the prepended number should *always* be added: Are you arguing that this from hg log is a good commit message? summary: Trac #6804: Trac #6804: change '=' to '=' in the docstring for Permutation.weak_excedences() Given the choice between unreliable and inconsistently formatted ticket numbers that require manual maintenance, compared to automatic, correct, and consistent numbers, I'd choose the latter, even if it meant that sometimes the number is duplicated. I would rather the script try to strip out the ticket number if it already exists, replacing it with a properly formatted automatically generated ticket number, rather than trying to decide whether to prepend the ticket number. In other words, I think the final commit message should contain an automatically-generated, consistently formatted ticket number. +1 -- that's exactly what I want. My post was more about advocating the opposite of Robert's suggestion (i.e., I think we should always prepend, and decide whether you should strip out the existing number), than arguing against making the script smarter. Cool. If I then qfinish the patch, that tag vanishes, right? At least if I simply import the patch then it vanishes. Good question. I operate under the assumption that a developer never qfinishes a patch; it's the release manager's job to commit the patch. I don't know what happens when you qfinish the patch. Obviously the release manager script isn't run in that case. OK, I'm beginning to be convinced Mercurial is kind of lacking (compared to git) if the only way for 99% of us to use it is to only use queues. -- 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
Re: [sage-devel] Re: log messages
On Tue, Feb 7, 2012 at 12:59 PM, Jason Grout jason-s...@creativetrax.com wrote: On 2/7/12 2:46 PM, William Stein wrote: On Tue, Feb 7, 2012 at 12:28 PM, Jason Grout jason-s...@creativetrax.com wrote: On 2/7/12 2:16 PM, Robert Bradshaw wrote: On Tue, Feb 7, 2012 at 12:08 PM, William Steinwst...@gmail.com wrote: On Tue, Feb 7, 2012 at 12:00 PM, Simon Kingsimon.k...@uni-jena.de wrote: Hi William, On 7 Feb., 20:47, William Steinwst...@gmail.com wrote: It's important (in fact, critical) that the trac ticket number is clearly available in the commit message. But having it twice in two different ways in almost every message seems a little bit sloppy to me. We were told, by different release managers, that the commit message has to identify the ticket number. Patches not following the rule were rejected. If that rule has changed in the meantime, the new rule (Do not mention the ticket number in your commit message!) should be enforced in the same way as the old rule was enforced. I think the commit message should mention the ticket number. This makes it much easier to keep track of stuff, even before the release manager puts the code in Sage. E.g., I have a big patch queue of my own code, and I find the ticket numbers in commit messages useful. What I'm suggesting is that the script that auto-adds ticket numbers should strip the user-added ticket number first, to avoid extensive duplication. Or at the very least not add it if it's not already there. (Stripping it in all its variants might be hard.) On the other hand, I think the canonical number should be the automatically prepended number, and that the prepended number should *always* be added: Are you arguing that this from hg log is a good commit message? summary: Trac #6804: Trac #6804: change '=' to '=' in the docstring for Permutation.weak_excedences() Given the choice between unreliable and inconsistently formatted ticket numbers that require manual maintenance, compared to automatic, correct, and consistent numbers, I'd choose the latter, even if it meant that sometimes the number is duplicated. I would rather the script try to strip out the ticket number if it already exists, replacing it with a properly formatted automatically generated ticket number, rather than trying to decide whether to prepend the ticket number. In other words, I think the final commit message should contain an automatically-generated, consistently formatted ticket number. My post was more about advocating the opposite of Robert's suggestion (i.e., I think we should always prepend, and decide whether you should strip out the existing number), than arguing against making the script smarter. I think stripping out something like (([Tt]rac:?)? *(--)?#?TICKET_NUMBER? would be more error prone, but you make a good point about consistency in the final commit message. 1. Its format is consistent, so we can write scripts and things that take advantage of that consistency 2. It's guaranteed to be correct, i.e., to reflect what ticket the patch was actually pulled from (in case patches move from ticket to ticket or the user makes a mistake). When I do hg log with my patches, I get output like this: changeset: 16483:722b00d2890c tag: trac-12229-manifest.patch user: Jason Groutjason.gr...@drake.edu date: Mon Jan 16 15:13:16 2012 -0600 summary: Patch MANIFEST.in to copy the .inc and .png sagenb doc files Notice that the tag field gives the filename. That's a great place to put the ticket number (in the filename). You then see the ticket number when you do hg queues commands, you see it in hg log, you see it in the patches directory, you see it on trac and when uploading, etc. The summary does not contain the ticket number---that is added when the ticket is merged. If I then qfinish the patch, that tag vanishes, right? At least if I simply import the patch then it vanishes. Good question. I operate under the assumption that a developer never qfinishes a patch; it's the release manager's job to commit the patch. I don't know what happens when you qfinish the patch. Obviously the release manager script isn't run in that case. 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 -- 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: log messages
On 2/7/12 3:17 PM, William Stein wrote: OK, I'm beginning to be convinced Mercurial is kind of lacking (compared to git) if the only way for 99% of us to use it is to only use queues. To be fair, it's more our workflow than mercurial itself. You have pull requests and things like that with Mercurial (ala bitbucket). Phases, in Mercurial 2.1, look pretty neat as well. The main things I miss in hg are: 1. a staging area 2. proper topic branch support for multiple heads. It's there with bookmarks, but it doesn't seem very well supported to have multiple heads, remote tracking branches, etc. Those are the main reasons why I use git for anything I can. Well, that and the fact that most of the scientific python community seems to be using git... 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
Re: [sage-devel] Re: log messages
On 2012-02-07 21:08, William Stein wrote: What I'm suggesting is that the script that auto-adds ticket numbers should strip the user-added ticket number first, to avoid extensive duplication. If you send me the magic sed/awk/perl/python/whatever script to do this, I'll happily use it :-) -- 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: Are the Sage binaries for OS X are crap?
I'm fairly certain #11881 (which still needs review) will solve the problem. At least the most common problem. Has anyone tried the work around I mentioned below? -Ivan On Feb 7, 2012, at 8:34 PM, William Stein wrote: Hi, I just got yet another (almost daily now) bug report about our OS X binaries being complete crap. This time from a Fields Medalist! So why don't we deal with this? The traceback he sent me is exactly the same as the one that started this thread.This is really stupid. -- William On Sun, Feb 5, 2012 at 9:07 AM, Ivan Andrus darthand...@gmail.com wrote: FWIW you should be able to work around the problem by opening Terminal.app before starting sage. At least if it's the manifestation of the problem that I think it is. -Ivan On Feb 4, 2012, at 7:52 PM, Mike OS wrote: Just corroborating. I encountered the same problem this week installing sage for the first time on a laptop running 10.6.8. I had no problem installing on a imac running 10.6.8 that already had an older copy of sage. -- 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 -- 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 -- 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] Removing Debian scripts (#12470) needs review
Something I did on a long boring train ride: remove some of the Debian cruft left in the scripts. Please review #12470: http://trac.sagemath.org/sage_trac/ticket/12470 -- 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] spkg dependency checking
I came across the following in the Sage Developer guide: - If your package depends on another package, say boehmgc, then you should check that this other package has been installed. Your ``spkg-install`` script should check that it exists, with code like the following: :: BOEHM_GC=`cd $SAGE_ROOT/spkg/standard/; ./newest_version boehm_gc` if [ $? -ne 0 ]; then echo Failed to find boehm_gc. Please install the boehm_gc spkg exit 1 fi Only *one* package does this, namely PPL. Since I think this is neither needed not used, I propose to remove this. I would also like to get rid of the newest_version script (#10492). -- 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: spkg dependency checking
As the PPL packager I'm fine with this ;-) -- 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] use ./configure; make for Sage?
On 7 February 2012 16:38, William Stein wst...@gmail.com wrote: On Mon, Feb 6, 2012 at 3:42 PM, Dr. David Kirkby david.kir...@onetel.net wrote: On 02/ 6/12 09:09 AM, Jeroen Demeyer wrote: On 2012-02-06 09:33, Dr. David Kirkby wrote: I think trying to replicate autotools would be just silly. That's what PARI tried and they are probably the spkg with the *most* patches to the configuration system. More fool them. I am not suggesting *replicating* autotools. I'm suggesting that we should clearly identify exactly what this ./configure is supposed to accomplish before deciding on what tool to use to implement it. Autconf may or may not be the right choice. -- William I think from a user's perspective, if he/she sees a configure script, they are likely to assume it behaves the same way as 95+% of other configure scripts. They probably will not know or care how it was created, but they will probably appreciate if it works like most others. I maintain a chess program http://chessdb.sourceforge.net/ originally written by someone else. That has a configure script that is NOT generated by autoconf. I think that was a bad decision by the original author, as the script behaves differently to most others. Using it is less intuitive than one generated by autoconf. I know there are other packages which have non-autoconf configure scripts (I think Perl is one such program), but generally it's a lot easier for a user if the script behaves like he/she has seen so many times in the past, and is familiar with. I've used autoconf on a finite difference program I wrote for modelling transmission lines. http://atlc.sourceforge.net/ That worked very well, and allowed the code to be very portable - it has been built on a Cray supercomputer as well as a Sony Playstation, and pretty much any Unix or Unix-like system. Unfortunately, from a developers point of view, it is not the easiest language to learn, and my experience of many Sage developers would suggest they will not be over keen on studying the details of .autoconf I can't exactly blame them either. -- 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: Are the Sage binaries for OS X are crap?
On Wednesday, February 8, 2012 3:34:38 AM UTC+8, William wrote: Hi, I just got yet another (almost daily now) bug report about our OS X binaries being complete crap. This time from a Fields Medalist! So why don't we deal with this? The traceback he sent me is exactly the same as the one that started this thread.This is really stupid. as a courtesy to the new users, one at least should put a big warning on the download page of this buggy download (*mirrorsname*/sage/osx/intel/index.html) And tell them to use the Terminal (i.e. non '-app' file) version for the time being. Otherwise it indeed alienates a lot of people :-( Dima -- William On Sun, Feb 5, 2012 at 9:07 AM, Ivan Andrus wrote: FWIW you should be able to work around the problem by opening Terminal.app before starting sage. At least if it's the manifestation of the problem that I think it is. -Ivan On Feb 4, 2012, at 7:52 PM, Mike OS wrote: Just corroborating. I encountered the same problem this week installing sage for the first time on a laptop running 10.6.8. I had no problem installing on a imac running 10.6.8 that already had an older copy of sage. -- 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] [ARM] The failed numerical tests only show the tests are bad!
See http://trac.sagemath.org/sage_trac/ticket/12449 I made a patch to change the way that sage evaluates symbolic functions for basic python types, and at the same time changed RDF to just use math.gamma() instead of gsl's gamma function. (Note: math.gamma() should be available in sage-5.0 (python 2.7.2), but I don't think it is in 4.8.) -- 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: spkg dependency checking
On Wednesday, February 8, 2012 7:06:14 AM UTC+8, Jeroen Demeyer wrote: I came across the following in the Sage Developer guide: - If your package depends on another package, say boehmgc, then you should check that this other package has been installed. Your ``spkg-install`` script should check that it exists, with code like the following: :: BOEHM_GC=`cd $SAGE_ROOT/spkg/standard/; ./newest_version boehm_gc` if [ $? -ne 0 ]; then echo Failed to find boehm_gc. Please install the boehm_gc spkg exit 1 fi Only *one* package does this, namely PPL. Since I think this is neither needed not used, I propose to remove this. I would also like to get rid of the newest_version script (#10492). well, I'd rather popularize this! E.g. GAP and GAP-related packages use some home-made stuff for a similar task, at least I recall something like this done in Simon's cohomology package. 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: Are the Sage binaries for OS X are crap?
On 2/7/12 4:28 PM, Ivan Andrus wrote: I'm fairly certain #11881 (which still needs review) will solve the problem. At least the most common problem. Do you, by chance, mean http://trac.sagemath.org/sage_trac/ticket/12161 #11881 is a huge ticket with lots of patches. Thanks, Jason Has anyone tried the work around I mentioned below? -Ivan On Feb 7, 2012, at 8:34 PM, William Stein wrote: Hi, I just got yet another (almost daily now) bug report about our OS X binaries being complete crap. This time from a Fields Medalist! So why don't we deal with this? The traceback he sent me is exactly the same as the one that started this thread.This is really stupid. -- William On Sun, Feb 5, 2012 at 9:07 AM, Ivan Andrusdarthand...@gmail.com wrote: FWIW you should be able to work around the problem by opening Terminal.app before starting sage. At least if it's the manifestation of the problem that I think it is. -Ivan On Feb 4, 2012, at 7:52 PM, Mike OS wrote: Just corroborating. I encountered the same problem this week installing sage for the first time on a laptop running 10.6.8. I had no problem installing on a imac running 10.6.8 that already had an older copy of sage. -- 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 -- 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 -- 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: spkg dependency checking
On Tuesday, February 7, 2012 3:06:14 PM UTC-8, Jeroen Demeyer wrote: I came across the following in the Sage Developer guide: - If your package depends on another package, say boehmgc, then you should check that this other package has been installed. Your ``spkg-install`` script should check that it exists, with code like the following: This is relevant for optional packages, so maybe it should say: If your package depends on an optional package, say ..., then you should As Dima points out, Simon King's group cohomology package does something like this. Is the 'deps' file discussed in the Developer's Guide? -- 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: Are the Sage binaries for OS X are crap?
On Feb 7, 2:34 pm, William Stein wst...@gmail.com wrote: Hi, I just got yet another (almost daily now) bug report about our OS X binaries being complete crap. This time from a Fields Medalist! So why don't we deal with this? William, on a related note, have all the people who used your 4.8.alpha3 or whatever custom binary successfully people who would now have a .sage directory (after having unsuccessfully used the regular binary)? And I assume this is using the app bundle that caused the problem, correct? If there is something wrong with the buildbot one, we could just create a custom one (I wouldn't, because I don't have libtiff or something so those files in plot/plot3d/base.pyx fail tests) on a machine we know does work. Georg makes it sound like one could test #12161 as being the problem by removing/renaming the .sage directory and then starting up the app bundle and seeing if this fixes the problem. Am I reading this right? If I find a little time I may yet try this tonight, since ... The traceback he sent me is exactly the same as the one that started this thread. This is really stupid. ... you are right about that. Maybe Harald could remove/hide the app bundles for the time being, though that's a drastic move. I wonder if one of our Python updates (certainly not the 2.7 one, of course) was to blame... -- 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] GSOC 2012
Hi, Does anybody want to help put together a GSoC application for Sage for 2012? http://code.google.com/soc/ The application deadline is March 9. So far, I think we've applied 5 times to have Sage as a mentoring organizing, and been denied every time. I think there is no feedback about why we are denied (maybe they think we already have too much NSF funding?). Also, other similar projects such as R, Sympy, PlanetMath, etc., have often been accepted as mentoring organizations.However, I don't think being denied every year is a reason to stop trying, because (1) our project is better than many of the projects Google chooses (they are just making a mistake by not choosing us), and (2) even if they don't choose us, we can propose our project ideas to other mentoring organizations. Regarding (2) though, it can be frustrating -- e.g., I felt we had an excellent proposal for a mentoring organization one of the years Sage was denied, and the organization decided against funding it because the developers didn't know us personally; their no was not based on weaknesses of the project itself, which I found frustrating. So it's best if we are a mentoring organization. -- 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] Re: GSOC 2012
On 2/7/12 9:48 PM, William Stein wrote: Hi, Does anybody want to help put together a GSoC application for Sage for 2012? http://code.google.com/soc/ The application deadline is March 9. So far, I think we've applied 5 times to have Sage as a mentoring organizing, and been denied every time. I think there is no feedback about why we are denied (maybe they think we already have too much NSF funding?). Also, other similar projects such as R, Sympy, PlanetMath, etc., have often been accepted as mentoring organizations.However, I don't think being denied every year is a reason to stop trying, because (1) our project is better than many of the projects Google chooses (they are just making a mistake by not choosing us), and (2) even if they don't choose us, we can propose our project ideas to other mentoring organizations. Regarding (2) though, it can be frustrating -- e.g., I felt we had an excellent proposal for a mentoring organization one of the years Sage was denied, and the organization decided against funding it because the developers didn't know us personally; their no was not based on weaknesses of the project itself, which I found frustrating. So it's best if we are a mentoring organization. So are you saying we shouldn't, for example, submit under the Python Software Foundation umbrella? I'd be willing to mentor, for example, a notebook project, since that's what I'll be working on most of the summer. I'll already have several students hopefully working with me on the notebook, or graphics (webgl, here we come :), etc. 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
Re: [sage-devel] Re: GSOC 2012
On Tue, Feb 7, 2012 at 7:55 PM, Jason Grout jason-s...@creativetrax.com wrote: On 2/7/12 9:48 PM, William Stein wrote: Hi, Does anybody want to help put together a GSoC application for Sage for 2012? http://code.google.com/soc/ The application deadline is March 9. So far, I think we've applied 5 times to have Sage as a mentoring organizing, and been denied every time. I think there is no feedback about why we are denied (maybe they think we already have too much NSF funding?). Also, other similar projects such as R, Sympy, PlanetMath, etc., have often been accepted as mentoring organizations. However, I don't think being denied every year is a reason to stop trying, because (1) our project is better than many of the projects Google chooses (they are just making a mistake by not choosing us), and (2) even if they don't choose us, we can propose our project ideas to other mentoring organizations. Regarding (2) though, it can be frustrating -- e.g., I felt we had an excellent proposal for a mentoring organization one of the years Sage was denied, and the organization decided against funding it because the developers didn't know us personally; their no was not based on weaknesses of the project itself, which I found frustrating. So it's best if we are a mentoring organization. So are you saying we shouldn't, for example, submit under the Python Software Foundation umbrella? If we come up with good projects that would make sense for PSF *and* are denied as a mentoring organization, then we should summit there. In my remark above, the mentoring org was not PSF. I'd be willing to mentor, for example, a notebook project, since that's what I'll be working on most of the summer. I'll already have several students hopefully working with me on the notebook, or graphics (webgl, here we come :), etc. Excellent. I am also willing to mentor a project on the notebook. Or something on implementing mathematical algorithms. 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 -- 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] Re: GSOC 2012
I'd be willing to mentor, for example, a notebook project, since that's what I'll be working on most of the summer. I'll already have several students hopefully working with me on the notebook, or graphics (webgl, here we come :), etc. Excellent. I am also willing to mentor a project on the notebook. Or something on implementing mathematical algorithms. Looking at Sympy's GSOC 2011 stuff, there is a lot of nontrivial math in it - so perhaps GSOC is getting more interested in funding more mathematical stuff (which was bandied about as a possible reason for previous denials). In fact, Sympy is looking like it's getting pretty impressive. I hesitate to say I would be a good mentor, but there are a lot of things in symbolics and graphics that would be appropriate for this that I'd like to try with some of my students. Especially piecewise functions and such. Continuing nontrivial Geogebra integration could be another very appropriate one. - kcrisman -- 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: Are the Sage binaries for OS X are crap?
If I find a little time I may yet try this tonight, since ... I can't reproduce this even if I do mv .sage/ .oldsage with the sketchy binary in question. It must be highly dependent on a lot of stuff :( sorry. -- 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: GSOC 2012
On Tue, Feb 7, 2012 at 8:11 PM, Volker Braun vbraun.n...@gmail.com wrote: Maybe we can tie the Android app into the notebook work? I could help mentor a student working on Android stuff, maybe that would help our GSOC application. That's an *extremely* good idea! Maybe we should have The Sage Notebook as the mentoring organization instead of Sage, given that every project idea so far has involved it? William -- 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: Are the Sage binaries for OS X are crap?
On Tue, Feb 7, 2012 at 8:11 PM, kcrisman kcris...@gmail.com wrote: If I find a little time I may yet try this tonight, since ... I can't reproduce this even if I do mv .sage/ .oldsage with the sketchy binary in question. It must be highly dependent on a lot of stuff :( sorry. Yes, I've never replicated this on any of my own computers either. It just happens on important people around me at the worst moment. Really annoying. -- 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
[sage-devel] Re: GSOC 2012
Maybe we can tie the Android app into the notebook work? I could help mentor a student working on Android stuff, maybe that would help our GSOC application. -- 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: GSOC 2012
On 2/7/12 10:15 PM, William Stein wrote: On Tue, Feb 7, 2012 at 8:11 PM, Volker Braunvbraun.n...@gmail.com wrote: Maybe we can tie the Android app into the notebook work? I could help mentor a student working on Android stuff, maybe that would help our GSOC application. That's an *extremely* good idea! Maybe we should have The Sage Notebook as the mentoring organization instead of Sage, given that every project idea so far has involved it? Here are some more ideas: * get interacts working in the IPython html notebook (not exactly Sage, but very closely related, and likely far more reaching than a Sage notebook project) * python-javascript translator so we can have *real* interaction (e.g., convert a symbolic expression to javascript, so the interact is totally computed in the browser, for simple interacts) * the usual: folders/tags/some method for organization, migrate to vastly different architecture for notebook (like ipython 0.12 or the sage cell architecture), webgl frontend for 3d graphics with all the trappings Sage projects: * get fast_callable into shape, including a fortran backend (I was really impressed with Oscar's demonstrations the other day). See http://trac.sagemath.org/sage_trac/ticket/5572; the sky is the limit for this as far as low-level expression optimizations too) * overhaul 2d graphics to be consistent, take advantage of matplotlib much more, etc. Introduce svg or html5 frontends for matplotlib that make interactive browser graphics easier (like interacts) * webwork/sage integration * coercion system printing framework, like David Roe has long advocated 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: GSOC 2012
* overhaul 2d graphics to be consistent, take advantage of matplotlib much more, etc. Introduce svg or html5 frontends for matplotlib that make interactive browser graphics easier (like interacts) These would be really cool. * webwork/sage integration There are real people already working on this, and WW is definitely a good partner for this - great idea. Cc:ing a few relevant people in case WW would be interested in cosponsoring that particular idea. -- 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: GSOC 2012
On Tue, Feb 7, 2012 at 11:17 PM, kcrisman kcris...@gmail.com wrote: * overhaul 2d graphics to be consistent, take advantage of matplotlib much more, etc. Introduce svg or html5 frontends for matplotlib that make interactive browser graphics easier (like interacts) These would be really cool. * webwork/sage integration There are real people already working on this, and WW is definitely a good partner for this - great idea. Cc:ing a few relevant people in case WW would be interested in cosponsoring that particular idea. Yes, we are certainly interested! I boldly assert on behalf of Mike and John ;) JasonA -- 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: GSOC 2012
+1 I had to go look up what GSOC was first ... Jt On Feb 7, 2012 11:27 PM, Jason Aubrey aubre...@gmail.com wrote: On Tue, Feb 7, 2012 at 11:17 PM, kcrisman kcris...@gmail.com wrote: * overhaul 2d graphics to be consistent, take advantage of matplotlib much more, etc. Introduce svg or html5 frontends for matplotlib that make interactive browser graphics easier (like interacts) These would be really cool. * webwork/sage integration There are real people already working on this, and WW is definitely a good partner for this - great idea. Cc:ing a few relevant people in case WW would be interested in cosponsoring that particular idea. Yes, we are certainly interested! I boldly assert on behalf of Mike and John ;) JasonA __ CONFIDENTIALITY NOTE: This communication may contain confidential information. If you are not the intended recipient or if you are not authorized to receive it, please notify and return the message to the sender. Unauthorized reviewing, forwarding, copying, distributing or using this information is strictly prohibited. -- 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: log messages
+100. -- 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: log messages
Sorry, I managed to activate some button on Google Groups accidentally and prematurely post the above message... +100. Our main problem with Mercurial is that we are not *using* it. We are just using Mercurial as a way for Jeroen to generate changelogs, and no other collaborative purpose whatsoever (despite what individual developers such as William might be doing with qfinishing patches, committing, etc. locally). We currently get zero benefit from using a distributed version control system. I completely agree with Jason's assessment of git vs. Mercurial, namely that both are serviceable, though git is more so (due to its topic branches support). But either git or a real Mercurial workflow would be vastly superior to the frankly nonsensical way we're using Mercurial right now. My $0.02. Jason: I'm sure you know this, but the record extension in mercurial allows you to do the equivalent of git commit -p, and you can of course use mq with a single patch in a patch queue as a simulation of a staging area, though this is a little painful compared to git's index. -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: log messages
+100. Our main problem with Mercurial is that we are not *using* it. We are just using Mercurial as a way for Jeroen to generate changelogs, and no other collaborative purpose whatsoever (despite what individual developers such as William might be doing with qfinishing patches, committing, etc. locally). We currently get zero benefit from using a distributed version control system. I completely agree with Jason's assessment of git vs. Mercurial, namely that both are serviceable, though git is more so (due to its topic branches support). But either git or a real Mercurial workflow would be vastly superior to the frankly nonsensical way we're using Mercurial right now. If anyone cares about such issues, you should come to Review Days at UW in March (tentatively scheduled for March 17-22), where we'll try to revamp how we use version control (among other things). There is funding available: e-mail me for details. David -- 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: log messages
Done! -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-notebook] Re: May I register sage-notebook [et al.] on Gmane?
On Mon, Feb 6, 2012 at 11:33, William Stein wst...@gmail.com wrote: More concerning is the lack of support for Google Groups from the Data Liberation Front at Google. If our group gets shut down for whatever reason, do we have a backup of all messages? How can we get a backup? I'm subscribed to all mailing lists, and I have all my email in Thunderbird's mbox's on my laptop. So there's that. But having a Gmane copy of all the messages is of course much better. We should always set that up for all sage-related groups. OK, that's excellent news. I will register on Gmane all the lists mentioned on the `Information for Developers`_ page on sagemath.org. Once they are all set up and listening for new messages, perhaps I can ask you to extract from your personal Thunderbox mbox and compile mbox files for each of them to submit to Gmane as backlogs? Thanks! -Keshav .. _Information for Developers: http://sagemath.org/development.html 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-notebook] Re: May I register sage-notebook [et al.] on Gmane?
On Wed, Feb 8, 2012 at 14:25, Keshav Kini keshav.k...@gmail.com wrote: Thunderbox Er. Thunderbird. -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: Are the Sage binaries for OS X are crap?
On Feb 8, 2012, at 1:18 AM, Jason Grout wrote: On 2/7/12 4:28 PM, Ivan Andrus wrote: I'm fairly certain #11881 (which still needs review) will solve the problem. At least the most common problem. Do you, by chance, mean http://trac.sagemath.org/sage_trac/ticket/12161 #11881 is a huge ticket with lots of patches. Thanks, Jason Err, yes of course. Sorry for the confusion. -Ivan Has anyone tried the work around I mentioned below? -Ivan On Feb 7, 2012, at 8:34 PM, William Stein wrote: Hi, I just got yet another (almost daily now) bug report about our OS X binaries being complete crap. This time from a Fields Medalist! So why don't we deal with this? The traceback he sent me is exactly the same as the one that started this thread.This is really stupid. -- William On Sun, Feb 5, 2012 at 9:07 AM, Ivan Andrusdarthand...@gmail.com wrote: FWIW you should be able to work around the problem by opening Terminal.app before starting sage. At least if it's the manifestation of the problem that I think it is. -Ivan On Feb 4, 2012, at 7:52 PM, Mike OS wrote: Just corroborating. I encountered the same problem this week installing sage for the first time on a laptop running 10.6.8. I had no problem installing on a imac running 10.6.8 that already had an older copy of sage. -- 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 -- 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 -- 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
