Re: [sage-combinat-devel] AlgebraWithBasis, GradedAlgebraWithBasis (again)
Hi John, Extremely short answer (I must catch a train)... On Mon, May 24, 2010 at 09:46:54PM -0700, John H Palmieri wrote: Some questions about defining an AlgebraWithBasis or a GradedAlgebraWithBasis: - Do these need to be defined using CombinatorialFreeModule, as in the example? No ! Never ! Category are about mathematical structure. In a category, there is never any assumption about the data structure. - If so, in all of the examples I've seen, CombinatorialFreeModule needs a basis with an explicit indexing set. I don't know an explicit indexing set in the case I'm interested in; rather, I can define a function which produces the basis. (It's graded, so I can give a recursive function which defines the basis in degree d in terms of the bases in lower degrees.) So what can I do? Is it possible and is it a good idea to specify a spanning set instead (as the basis in CombinatorialFreeModule) -- I can just use words in the generators -- and then later on specify a linearly independent subset? - If I don't need to use CombinatorialFreeModule, what other choices do I have? Anyone ! Polynomials should clearly be in GradedAlgebraWithBasis for examples. As I said the goal of category is to formalize some assumption about the interface (a ring is a set with a multiplication, ...) and to provide generic tests and algorithm using methods implementing the interface... Cheers, Florent -- 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-de...@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] Re: [sage-algebra] AlgebraWithBasis, GradedAlgebraWithBasis (again)
Hi John! Again, I'll stick to a very short answer for the moment. Prompted by your questions, I now have a clearer idea of what sort of wizard-like document is needed by the developers when choosing the implementation for a parent. I'll try to work on it this week, and keep you updated when I'll have some draft. On Mon, May 24, 2010 at 09:46:54PM -0700, John H Palmieri wrote: Some questions about defining an AlgebraWithBasis or a GradedAlgebraWithBasis: - Do these need to be defined using CombinatorialFreeModule, as in the example? Not at all. CombinatorialFreeModule just provides you with a data structure (mostly for the elements, and a bit for the parent). But you can use your own data structure. - If so, in all of the examples I've seen, CombinatorialFreeModule needs a basis with an explicit indexing set. Yes. That's actually a prerequisite of AlgebrasWithBasis. Ok, the definition of AlgebrasWithBasis should be rewritten as: The category of algebras with a distinguished basis on which the elements are represented by their expansion. I don't know an explicit indexing set in the case I'm interested in; rather, I can define a function which produces the basis. (It's graded, so I can give a recursive function which defines the basis in degree d in terms of the bases in lower degrees.) So what can I do? Is it possible and is it a good idea to specify a spanning set instead (as the basis in CombinatorialFreeModule) -- I can just use words in the generators -- and then later on specify a linearly independent subset? Sounds like you probably just want to use the GradedAlgebras(QQ) category. And as of now, the categories won't give you that much, except for TestSuite, and not having to be refactored at some later point. On the other hand, it also sounds like your algebra is defined as a subalgebra of a larger ambient algebra. In that case, the upcoming #8881 patch could be of interest for you, your parent being in GradedAlgebras(QQ).Subobjects() with elements represented as elements thereof, wrapped in an ElementWrapper; sorry, that's work in progress, so there is not yet an example in sage.categories.example. With the sage-combinat patches installed (`sage -combinat install`), you can have a look at: Semigroups().Subquotients().example() for a related example for quotients. More on this in the upcoming document. - If I don't need to use CombinatorialFreeModule, what other choices do I have? Not much yet builtin, since FreeModule's haven't yet been refactored to use categories. But you can create your own ... Best, 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-de...@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] Re: [sage-algebra] AlgebraWithBasis, GradedAlgebraWithBasis (again)
On May 25, 12:46 am, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote: Hi John! Again, I'll stick to a very short answer for the moment. Prompted by your questions, I now have a clearer idea of what sort of wizard-like document is needed by the developers when choosing the implementation for a parent. I'll try to work on it this week, and keep you updated when I'll have some draft. Great! On Mon, May 24, 2010 at 09:46:54PM -0700, John H Palmieri wrote: Some questions about defining an AlgebraWithBasis or a GradedAlgebraWithBasis: - Do these need to be defined using CombinatorialFreeModule, as in the example? Not at all. CombinatorialFreeModule just provides you with a data structure (mostly for the elements, and a bit for the parent). But you can use your own data structure. If I use another data structure, are there methods that I should make sure to implement for it to be a well-implemented (Graded)AlgebraWithBasis? - If so, in all of the examples I've seen, CombinatorialFreeModule needs a basis with an explicit indexing set. Yes. That's actually a prerequisite of AlgebrasWithBasis. Ok, the definition of AlgebrasWithBasis should be rewritten as: The category of algebras with a distinguished basis on which the elements are represented by their expansion. When I say an explicit indexing set, I mean explicit from the point of view of Sage. I can give you a mathematically explicit indexing set -- ordered partitions satisfying certain explicit conditions -- but I can't give it as a list or tuple or anything else simple that already exists in Sage. This morning I thought of the possibility of implementing a subclass of Partitions and then using that for my indexing set; is that feasible? Maybe that's the right choice. I don't know an explicit indexing set in the case I'm interested in; When I said this, I meant that I don't know, for example, a closed- form expression for the dimension of the algebra in bidegree (s,t). But as I said above, I can write down a mathematically explicit expression for an indexing set for the basis. rather, I can define a function which produces the basis. (It's graded, so I can give a recursive function which defines the basis in degree d in terms of the bases in lower degrees.) So what can I do? Is it possible and is it a good idea to specify a spanning set instead (as the basis in CombinatorialFreeModule) -- I can just use words in the generators -- and then later on specify a linearly independent subset? Sounds like you probably just want to use the GradedAlgebras(QQ) category. And as of now, the categories won't give you that much, except for TestSuite, and not having to be refactored at some later point. On the other hand, it also sounds like your algebra is defined as a subalgebra of a larger ambient algebra. Well, it's actually a quotient of a free algebra, which by itself tells you absolutely nothing, since every algebra is such a quotient. But I have explicit generators and relations, and there is a distinguished collection of words (admissible words) in the generators which projects to a basis of the quotient algebra, and there is a clear procedure for rewriting any word in the generators as a sum of basis elements. -- John -- 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-de...@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] question about Partitions, Compositions, IntegerListsLex
I would like to construct the set of ordered partitions of a positive
integer n subject to a condition like this:
- if the partition is (l_1, l_2, ...), then I want to specify a
variant of slope: I want to specify integers a and b, or lists of
integers (a_1, a_2, ...) and (b_1, b_2, ...) and then I want to
replace the slope condition
max_slope = l_i - l_{i+1} = min_slope
with
max_slope = a_i * l_i - b_i * l_{i+1} = min_slope
For example, I want to be able to produce the ordered partitions (l_1,
l_2, ..., l_k) of n, with length k, such that
2l_i = l_{i+1}
for all i.
Can someone help me to alter IntegerListsLex (I think this is the
right class) so that it allows for this functionality? The code in
combinat/integer_list.py looks a little complicated, and I'm hoping
someone can provide a quick answer.
Thanks,
John
--
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-de...@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-devel] problem with graph.is_isomorphic
Ok, in case I get hit by lightning in the next twelve hours, I've at
least figured out what the bug is, but fixing it will take some
effort. Essentially, the bug is in double_coset.pyx, when we do the
first set of refinements to get the left partition stack and the first
partition stack set up. The problem is that the code is aborting early
instead of backtracking, in the loop {{{while not
PS_is_discrete(left_ps) and possible:}}}. What the code should do is
two separate loops: one to establish the left partition stack, and the
next to try to get a similar setup for the first partition stack. The
second loop, instead of aborting (right now the code does {{{
if not possible:
j = vertices_determining_current_stack[i] + 1
j = bitset_next(vertices_to_split[i], j)
if j == -1:
break
}}} ), where it says break it should actually be backtracking up the
first partition stack to try other combinations higher up.
Now that I understand the bug, my experience is it's best to sleep on
it, and tackle fixing it tomorrow. This way I've given myself a nice
outline towards doing that...
--
Robert L. Miller
http://www.rlmiller.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] Why is the executable 'sympow' copied to local/lib/sympow?
When on builds 'sympow', a directory $SAGE_LOCAL/lib/sympow is made, and the file 'sympow' executable copied there: drkir...@hawk:~/sage-4.4.2$ ./local/lib/sympow/sympow sympow 1.018 RELEASE (c) Mark Watkins --- see README and COPYING for details It seems a strange decision to copy an executable into a directory under 'lib' - I would have expected such a file to be copied to $SAGE_LOCAL/bin. Not that I guess it makes a huge difference, but it's a bit of an unconventional place to put an executable program. Dave -- 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: problem with graph.is_isomorphic
On 25 Mai, 09:07, Robert Miller r...@rlmiller.org wrote: combinations higher up. [...] Now that I understand the bug, my experience is it's best to sleep on it, and tackle fixing it tomorrow. This way I've given myself a nice outline towards doing that... This is good practice not just for fixing bugs. Can you put this in the Developer's Guide? ;-) -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
Re: [sage-devel] Why is the executable 'sympow' copied to local/lib/sympow?
I agree! John On 25 May 2010 08:44, Dr. David Kirkby david.kir...@onetel.net wrote: When on builds 'sympow', a directory $SAGE_LOCAL/lib/sympow is made, and the file 'sympow' executable copied there: drkir...@hawk:~/sage-4.4.2$ ./local/lib/sympow/sympow sympow 1.018 RELEASE (c) Mark Watkins --- see README and COPYING for details It seems a strange decision to copy an executable into a directory under 'lib' - I would have expected such a file to be copied to $SAGE_LOCAL/bin. Not that I guess it makes a huge difference, but it's a bit of an unconventional place to put an executable program. Dave -- 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
Re: [sage-devel] Why is the executable 'sympow' copied to local/lib/sympow?
When on builds 'sympow', a directory $SAGE_LOCAL/lib/sympow is made, and the file 'sympow' executable copied there: drkir...@hawk:~/sage-4.4.2$ ./local/lib/sympow/sympow sympow 1.018 RELEASE (c) Mark Watkins --- see README and COPYING for details It seems a strange decision to copy an executable into a directory under 'lib' - I would have expected such a file to be copied to $SAGE_LOCAL/bin. Not that I guess it makes a huge difference, but it's a bit of an unconventional place to put an executable program. Hi, sympow is a weird program. Not really completely standard. The problem is the datafiles folder for the data generated by sympow must be in the same folder as the one containing the executables and the sympow scripts. Which is a lot of fun when sympow is installed as root. In debian (and in gentoo) we elected to move the executable in /usr/share/sympow and install a script in /usr/bin/ to execute sympow in the proper place. No idea why the current scheme was chosen in sage, because of the datafiles you obviously don't want to put everything into $SAGE_LOCAL/bin. Francois -- 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: Problems building Sage 4.4.1
On 25 Mai, 02:13, Dr. David Kirkby david.kir...@onetel.net wrote: On 05/24/10 05:26 PM, leif wrote: Looks like the (fairly old) gcc/g++ in /usr/local is misconfigured; it definitely tries to link a 64-bit (x86_64) C++ program against the 32- bit libstdc++.so (in /usr/local/lib) instead of the 64-bit version in / usr/local/lib64. (Actually it is forced to do so by libtool.) I'm not so convinced this failure with 'libfplll' is a gcc problem, but rather it is a 'libfplll' problem. I'm seeing the exact same issue with 'libfplll' on OpenSolaris. http://trac.sagemath.org/sage_trac/ticket/7864 The fact the original poster, his colleague and myself are all seeing this, suggests to me that perhaps libfplll may be at fault in trying to link 64-bit objects to 32-bit libstdc++ Other parts of the Sage build process are correctly using the 64-bit version of libstdc++.so on my OpenSolaris box - see for example this line. What I wanted to say is that installing another version of gcc in /usr/ local on systems (like Linux distros) where there already is a native one (gcc) in /usr is non-trivial, i.e. this doesn't work out of the box. With the native gcc, -lstdc++ is passed to the linker (which would have worked in Matthew's installation, too), while with gcc in /usr/ local its absolute filename is passed. These are snippets from install.log, the first is from Sage 4.4.2 on Ubuntu 9.04 x86_64 with native gcc (4.3.3), the second is from Sage 4.4.2.rc0 on Ubuntu 9.04 x86_64 with gcc 4.5.0 in /usr/local: * native gcc in /usr: -8--8--8--8--8--8-- g++ -DPACKAGE_NAME=\libfplll\ -DPACKAGE_TARNAME=\libfplll\ - DPACKAGE_VERSION=\3.0.12\ -DPACKAGE_STRING=\libfplll 3.0.12\ - DPACKAGE_BUGREPORT=\\ -DPACKAGE=\libfplll\ -DVERSION=\3.0.12\ - DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 - DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 - DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 - DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBGMP=1 -DHAVE_LIBMPFR=1 - DSTDC_HEADERS=1 -DHAVE_FLOAT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_STDLIB_H=1 - DHAVE_SYS_TIME_H=1 -DHAVE_UNISTD_H=1 -DHAVE_STDBOOL_H=1 -DHAVE_FLOOR=1 -DHAVE_POW=1 -DHAVE_RINT=1 -DHAVE_SQRT=1 -DHAVE_STRTOL=1 - DHAVE_LIBGMP=1 -DHAVE_LIBMPFR=1 -I. -I. -I/home/leif64/Sage/sage-4.4.2- too/local/include/ -fPIC -I/home/leif64/Sage/sage-4.4.2-too/local/ include/ -L/home/leif64/Sage/sage-4.4.2-too/local/lib -MT dummy.lo -MD -MP -MF .deps/dummy.Tpo -c dummy.cpp -fPIC -DPIC -o .libs/dummy.o g++ -DPACKAGE_NAME=\libfplll\ -DPACKAGE_TARNAME=\libfplll\ - DPACKAGE_VERSION=\3.0.12\ -DPACKAGE_STRING=\libfplll 3.0.12\ - DPACKAGE_BUGREPORT=\\ -DPACKAGE=\libfplll\ -DVERSION=\3.0.12\ - DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 - DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 - DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 - DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBGMP=1 -DHAVE_LIBMPFR=1 - DSTDC_HEADERS=1 -DHAVE_FLOAT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_STDLIB_H=1 - DHAVE_SYS_TIME_H=1 -DHAVE_UNISTD_H=1 -DHAVE_STDBOOL_H=1 -DHAVE_FLOOR=1 -DHAVE_POW=1 -DHAVE_RINT=1 -DHAVE_SQRT=1 -DHAVE_STRTOL=1 - DHAVE_LIBGMP=1 -DHAVE_LIBMPFR=1 -I. -I. -I/home/leif64/Sage/sage-4.4.2- too/local/include/ -fPIC -I/home/leif64/Sage/sage-4.4.2-too/local/ include/ -L/home/leif64/Sage/sage-4.4.2-too/local/lib -MT dummy.lo -MD -MP -MF .deps/dummy.Tpo -c dummy.cpp -o dummy.o /dev/null 21 /bin/bash ./libtool --tag=CXX --mode=link g++ -fPIC -I/home/leif64/ Sage/sage-4.4.2-too/local/include/ -L/home/leif64/Sage/sage-4.4.2-too/ local/lib -o libfplll.la -rpath /home/leif64/Sage/sage-4.4.2-too/ local/lib -version-info 1:0:1 dummy.lo -lgmp -lmpfr -lmpfr -lgmp - lmpfr -lgmp g++ -shared -nostdlib /usr/lib/gcc/x86_64-linux-gnu/4.3.3/../../../../ lib/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.3.3/crtbeginS.o .libs/ dummy.o -Wl,--rpath -Wl,/home/leif64/Sage/sage-4.4.2-too/local/lib - Wl,--rpath -Wl,/home/leif64/Sage/sage-4.4.2-too/local/lib -L/home/ leif64/Sage/sage-4.4.2-too/local/lib /home/leif64/Sage/sage-4.4.2-too/ local/lib/libmpfr.so /home/leif64/Sage/sage-4.4.2-too/local/lib/ libgmp.so -L/home/leif64/Sage/sage-4.4.2-too/local/lib/../lib -L/usr/ lib/gcc/x86_64-linux-gnu/4.3.3 -L/usr/lib/gcc/x86_64-linux-gnu/ 4.3.3/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/ x86_64-linux-gnu/4.3.3/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/ x86_64-linux-gnu/4.3.3/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/ 4.3.3/../../../../lib/crtn.o -Wl,-soname -Wl,libfplll.so.0 -o .libs/ libfplll.so.0.1.0 (cd .libs rm -f libfplll.so.0 ln -s libfplll.so.0.1.0 libfplll.so.0) (cd .libs rm -f libfplll.so ln -s libfplll.so.0.1.0 libfplll.so) ar cru .libs/libfplll.a dummy.o ranlib .libs/libfplll.a creating libfplll.la (cd .libs rm -f libfplll.la ln -s ../libfplll.la libfplll.la) make[3]: Verlasse Verzeichnis '/home/leif64/Sage/sage-4.4.2-too/spkg/ build/libfplll-3.0.12.p0/src'
[sage-devel] Re: Why is the executable 'sympow' copied to local/lib/sympow?
On May 25, 11:14 am, François Bissey f.r.bis...@massey.ac.nz wrote:
Hi,
sympow is a weird program. Not really completely standard. The problem
is the datafiles folder for the data generated by sympow must be in the
same folder as the one containing the executables and the sympow scripts.
Which is a lot of fun when sympow is installed as root.
In debian (and in gentoo) we elected to move the executable in
/usr/share/sympow and install a script in /usr/bin/ to execute sympow in the
proper place.
Thats no more correct on gentoo - I have written a set of sed commands
which fixes this behaviour:
http://github.com/cschwan/sage-on-gentoo/blob/master/sci-mathematics/sympow/sympow-1.018.ebuild
(see lines 27 to 55).
I think this could be adapted for Sage, too, but this would be more
difficult because one cannot assume ${SAGE_LOCAL} to be /.
No idea why the current scheme was chosen in sage, because of the datafiles
you obviously don't want to put everything into $SAGE_LOCAL/bin.
Francois
--
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 athttp://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] Help me in debugging
Hi, I am debugging a patch of my own. Perhaps due to the patch, I get the following strange doctest failure. sage -t 4.4.2/devel/sage-main/sage/modules/free_module.py ** File /Users/Kwankyu/Sage/sage-4.4.2/devel/sage-main/sage/modules/ free_module.py, line 1125: sage: V.base_extend(QQ) Expected: Vector space of dimension 7 over Rational Field Got: V ** 1 items had failures: 1 of 4 in __main__.example_23 ***Test Failed*** 1 failures. For whitespace errors, see the file /Users/Kwankyu/.sage// tmp/.doctest_free_module.py [16.8 s] -- The following tests failed: sage -t 4.4.2/devel/sage-main/sage/modules/free_module.py Total time for all tests: 16.8 seconds However, if I type in the exactly same doctest found in lines 1124-1125 of free_module.py, then I get the correct result instead of just V, as you see below. athena:sage-main Kwankyu$ sage -- | Sage Version 4.4.2, Release Date: 2010-05-19 | | Type notebook() for the GUI, and license() for information.| -- sage: V = ZZ^7 sage: V.base_extend(QQ) Vector space of dimension 7 over Rational Field sage: How possibly could this happen? Why I get a different result in doctesting? I seek of your expertise. Thank you in advance. Kwankyu Lee -- 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: Why is the executable 'sympow' copied to local/lib/sympow?
On May 25, 11:14 am, François Bissey f.r.bis...@massey.ac.nz wrote:
Thats no more correct on gentoo - I have written a set of sed commands
which fixes this behaviour:
http://github.com/cschwan/sage-on-gentoo/blob/master/sci-mathematics/sympow
/sympow-1.018.ebuild
(see lines 27 to 55).
I think this could be adapted for Sage, too, but this would be more
difficult because one cannot assume ${SAGE_LOCAL} to be /.
Forgot that you touched that! Sorry.
Francois
--
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: Problems building Sage 4.4.1
On 25 Mai, 11:18, leif not.rea...@online.de wrote: What I wanted to say is that installing another version of gcc in /usr/ local on systems (like Linux distros) where there already is a native one (gcc) in /usr is non-trivial, i.e. this doesn't work out of the box. With the native gcc, -lstdc++ is passed to the linker (which would have worked in Matthew's installation, too), while with gcc in /usr/ local its absolute filename is passed. Oops, the custom gcc is actually installed in /usr, not /usr/local, but this shouldn't matter... ;-) (It is configured with --enable-version-specific-runtime-libs and -- program-suffix=) -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: Help me in debugging
On 25 Mai, 11:30, Kwankyu Lee ekwan...@gmail.com wrote: Hi, I am debugging a patch of my own. Perhaps due to the patch, I get the following strange doctest failure. sage -t 4.4.2/devel/sage-main/sage/modules/free_module.py ** File /Users/Kwankyu/Sage/sage-4.4.2/devel/sage-main/sage/modules/ free_module.py, line 1125: sage: V.base_extend(QQ) Expected: Vector space of dimension 7 over Rational Field Got: V ** 1 items had failures: 1 of 4 in __main__.example_23 ***Test Failed*** 1 failures. For whitespace errors, see the file /Users/Kwankyu/.sage// tmp/.doctest_free_module.py [16.8 s] -- The following tests failed: sage -t 4.4.2/devel/sage-main/sage/modules/free_module.py Total time for all tests: 16.8 seconds However, if I type in the exactly same doctest found in lines 1124-1125 of free_module.py, then I get the correct result instead of just V, as you see below. athena:sage-main Kwankyu$ sage -- | Sage Version 4.4.2, Release Date: 2010-05-19 | | Type notebook() for the GUI, and license() for information. | -- sage: V = ZZ^7 sage: V.base_extend(QQ) Vector space of dimension 7 over Rational Field sage: How possibly could this happen? Why I get a different result in doctesting? I seek of your expertise. Thank you in advance. This is a known issue, and most probably ;-) not related to your patch: See e.g. http://groups.google.com/group/sage-release/msg/dac6cb862ecf6a8e -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: Help me in debugging
On 25 Mai, 11:41, leif not.rea...@online.de wrote: This is a known issue, and most probably ;-) not related to your patch: See e.g.http://groups.google.com/group/sage-release/msg/dac6cb862ecf6a8e Direct link to the ticket: http://trac.sagemath.org/sage_trac/ticket/9003 -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: MPIR documentation and the GMP website
Someone has just pointed out that the mpir.texi document, from which
our pdf documentation is generated contains:
@c @author Original version by Torbj@orn Granlund, Swox AB - modified
by William Hart
@c @email{goodwillh...@gmail.com}
So, not only did we not remove the original author information, but we
correctly added additional author information!!
Now, we are looking into why this isn't appearing on the title page of
the pdf documentation. That appears to be a technical issue! We will
also add The GMP Development Team as per the latest GMP
documentation.
So, next time Mr. Granlund, check your facts before posting nonsense!
Bill.
On 24 May, 19:58, Bill Hart goodwillh...@googlemail.com wrote:
I don't think that is something we can cover on the MPIR website.
You might consider Windows support, FSF copyright assignment and
other issues It should just be clear that GMP won't, by and large,
just accept our contributions. You might also consider that numerous
individuals *did* try to contribute their improvements to GMP.
I agree the the fork was intimately tied up with this stuff. But
again, let's be positive about MPIR's current focus. I don't think we
need to revisit this on the website.
Bill.
On 24 May, 19:34, leif not.rea...@online.de wrote:
On 24 Mai, 20:13, Bill Hart goodwillh...@googlemail.com wrote:
OK, I made a little bit of a change to the about section of the MPIR
website. It now has:
MPIR is an open source multiprecision integer (bignum) library forked
from the a href=http://gmplib.org/;GMP (GNU Multi Precision)/a
project. It consists of much code from past GMP releases, in
combination with much original contributed code.
I doubt that addresses the concern you had, but it is, in my opinion,
clearer and simpler than what we had. In particular I removed the bit
about originally being a fork of GMP 4.2.1 (which was LGPL v2+), etc.
I don't think that information is particularly useful or serving any
definite purpose any more, though there wasn't anything particularly
wrong with it.
But again, I'm happy to change something if it isn't clear, or perhaps
I should say that the new MPIR webmaster will (I've just been
transferring credentials over for that).
(primary goals:) To maintain full interface support with GMP - MPIR
is a drop-in replacement for GMP.
So it isn't clear why MPIR forked rather than contributing their
enhancements to GMP.
(And one may ask himself why and when he should use MPIR instead of
GMP and vice versa.)
-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
athttp://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 athttp://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: Help me in debugging
Hi Leif, This doctest failure did not occur without applying my own patch, so I thought my patch was the cause. A weird bug indeed... Thank you for the pointers. Kwankyu -- 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: Help me in debugging
On 25 Mai, 14:01, Kwankyu Lee ekwan...@gmail.com wrote: This doctest failure did not occur without applying my own patch, so I thought my patch was the cause. A weird bug indeed... Interesting. Is this behavior reproducable (i.e. present in all test runs)? Is your patch on trac? This could help narrowing the origin. And what system are you on? (I guess it's some MacOS; CPU, 32bit?) It wouldn't be bad if you add this information to http://trac.sagemath.org/sage_trac/ticket/9003 -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: Help me in debugging
On May 25, 8:39 am, leif not.rea...@online.de wrote: On 25 Mai, 14:01, Kwankyu Lee ekwan...@gmail.com wrote: This doctest failure did not occur without applying my own patch, so I thought my patch was the cause. A weird bug indeed... Interesting. Is this behavior reproducable (i.e. present in all test runs)? Yes, please do put any and all information on that Trac ticket. According to the updates there, it seems like there may be something weird about the doctest framework. Do you get any problems when running the doctests manually (i.e., from the command line in sequential order)? - kcrisman Is your patch on trac? This could help narrowing the origin. And what system are you on? (I guess it's some MacOS; CPU, 32bit?) It wouldn't be bad if you add this information tohttp://trac.sagemath.org/sage_trac/ticket/9003 -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 athttp://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: [mpir-devel] Re: MPIR documentation and the GMP website
Hello, Bill. Now, we are looking into why this isn't appearing on the title page of the pdf documentation. That appears to be a technical issue! We will also add The GMP Development Team as per the latest GMP documentation. I think that when you fix _everything_ someone still will be able to write and made numerous crimes against humanity in the distant past in addition to receiving bloody money from Microsoft... :(( Well, we still have option of writing a petition to the GNU Project. Maybe it was better not to postpone petition because changes at the GMP website are mostly insignificant. -- With best regards, Sergey mailto:sergey.bochka...@alglib.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: [mpir-devel] Re: MPIR documentation and the GMP website
Oh, this is absolutely delicious!
Here is the author information from the gmp-4.2.1.tar.gz in doc/gmp.texi:
@c @author by Torbj@orn Granlund, Swox AB
@c @email{tege@@swox.com}
Note the @c comments here, which as far as I see, do indeed comment
out the author information!! I invite people to check this fact by
downloading the original GMP tarball here:
http://ftp.gnu.org/pub/gnu/gmp/gmp-4.2.1.tar.gz
So it is established that we are being accused of academic fraud for
removing the author information WHEN IT WAS DONE BY SOMEONE ON THE GMP
TEAM in the actual version of GMP we forked from!!
@sergey Thanks for your support. But I don't think we should do
anything further. I think what is currently on the GMP website is FAR
more damaging to the author of those comments than it is to us. Also,
there are two very significant changes on their website: 1) the
University of Washington is no longer mentioned, 2) the specific
specious implication that we knowingly downgraded licenses from v3 to
v2 has been removed. What is now alleged there is academic fraud, and
it is proved beyond a shadow of a doubt that this accusation is false.
We don't need to do anything further about this. Trust me, I know how
this works and it's over!
Bill.
On 25 May 2010 15:56, Jason Moxham ja...@njkfrudils.plus.com wrote:
On Tuesday 25 May 2010 12:38:34 Bill Hart wrote:
Someone has just pointed out that the mpir.texi document, from which
our pdf documentation is generated contains:
@c @author Original version by Torbj@orn Granlund, Swox AB - modified
by William Hart
@c @email{goodwillh...@gmail.com}
So, not only did we not remove the original author information, but we
correctly added additional author information!!
Now, we are looking into why this isn't appearing on the title page of
the pdf documentation. That appears to be a technical issue! We will
note the @c before the @author , that is a comment , I assume because @author
crashed earlier pdf makes
also add The GMP Development Team as per the latest GMP
documentation.
So, next time Mr. Granlund, check your facts before posting nonsense!
Bill.
On 24 May, 19:58, Bill Hart goodwillh...@googlemail.com wrote:
I don't think that is something we can cover on the MPIR website.
You might consider Windows support, FSF copyright assignment and
other issues It should just be clear that GMP won't, by and large,
just accept our contributions. You might also consider that numerous
individuals *did* try to contribute their improvements to GMP.
I agree the the fork was intimately tied up with this stuff. But
again, let's be positive about MPIR's current focus. I don't think we
need to revisit this on the website.
Bill.
On 24 May, 19:34, leif not.rea...@online.de wrote:
On 24 Mai, 20:13, Bill Hart goodwillh...@googlemail.com wrote:
OK, I made a little bit of a change to the about section of the
MPIR website. It now has:
MPIR is an open source multiprecision integer (bignum) library
forked from the a href=http://gmplib.org/;GMP (GNU Multi
Precision)/a project. It consists of much code from past GMP
releases, in combination with much original contributed code.
I doubt that addresses the concern you had, but it is, in my opinion,
clearer and simpler than what we had. In particular I removed the bit
about originally being a fork of GMP 4.2.1 (which was LGPL v2+), etc.
I don't think that information is particularly useful or serving any
definite purpose any more, though there wasn't anything particularly
wrong with it.
But again, I'm happy to change something if it isn't clear, or
perhaps I should say that the new MPIR webmaster will (I've just been
transferring credentials over for that).
(primary goals:) To maintain full interface support with GMP - MPIR
is a drop-in replacement for GMP.
So it isn't clear why MPIR forked rather than contributing their
enhancements to GMP.
(And one may ask himself why and when he should use MPIR instead of
GMP and vice versa.)
-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 athttp://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 athttp://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: Help me in debugging
Added information to the ticket http://trac.sagemath.org/sage_trac/ticket/9003 Kwankyu Lee -- 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: problem with graph.is_isomorphic
Fixed! http://trac.sagemath.org/sage_trac/ticket/9045 Note that the patch does not yet have any doctests. I'm waiting on a better description of the graphs which caused the bug in the first place. (Although we could use the graph6 strings for now, since having this merged is probably pretty important.) -- Robert L. Miller http://www.rlmiller.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: problem with graph.is_isomorphic
+1 to using Graph6 strings, and I'll review this tomorrow. On Tue, May 25, 2010 at 9:12 AM, Robert Miller r...@rlmiller.org wrote: Fixed! http://trac.sagemath.org/sage_trac/ticket/9045 Note that the patch does not yet have any doctests. I'm waiting on a better description of the graphs which caused the bug in the first place. (Although we could use the graph6 strings for now, since having this merged is probably pretty important.) -- Robert L. Miller http://www.rlmiller.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
Re: [sage-devel] Re: problem with graph.is_isomorphic
On Tue, May 25, 2010 at 9:17 AM, Tom Boothby tomas.boot...@gmail.com wrote: +1 to using Graph6 strings, and I'll review this tomorrow. OK, the doctest is in the patch, and all ready for review. -- Robert L. Miller http://www.rlmiller.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: [mpir-devel] Re: MPIR documentation and the GMP website
Hello, Bill. So it is established that we are being accused of academic fraud for removing the author information WHEN IT WAS DONE BY SOMEONE ON THE GMP TEAM in the actual version of GMP we forked from!! Confirmed. I think what is currently on the GMP website is FAR more damaging to the author of those comments than it is to us. We don't need to do anything further about this. Trust me, I know how this works and it's over! I just want to say that it is more damaging to the author of those comments only in eyes of those who knows all history. Imagine for a moment that I am just ordinary programmer who wants to download GMP from gmplib.org. What I see when I read about MPIR: * something accused of (past) LGPL violations * accused of academic fraud * accused of launching defamation campaing * funded by Microsoft (in such context - by Evil Empire Microsoft ) So I'll just conclude that MPIR team is evil, and won't read MPIR/SAGE forum where I can find the truth. I think that such situation is damaging enough to the MPIR (team) reputation to take _something_ to get this text out from gmplib.org However, it is up to you to decide what to do in this situation. If you'll decide to write something to someone, I'll be happy to sign it. Good luck! -- With best regards, Sergey mailto:sergey.bochka...@alglib.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] Changelogs in SPKG.txt
Hi all, I just had a new spkg (rightly) rejected because it didn't have a changelog entry in SPKG.txt , as specified by [1], Does anyone know why are we manually keeping a text changelog when the files under our control are already under revision control? - Robert [1] http://www.sagemath.org/doc/developer/producing_spkgs.html#the-file-spkg-txt . -- 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] Re: MPIR documentation and the GMP website
My point is, imagine how damaging it will be to the author of those comments if they just leave them there. Trust me, they'll go of their own accord. We don't need to touch this one. If someone else feels strongly that action needs to be taken, well I won't be getting in their way. As for me, on with my actual job!! Bill. On 25 May 2010 18:41, Sergey Bochkanov sergey.bochka...@alglib.net wrote: Hello, Bill. So it is established that we are being accused of academic fraud for removing the author information WHEN IT WAS DONE BY SOMEONE ON THE GMP TEAM in the actual version of GMP we forked from!! Confirmed. I think what is currently on the GMP website is FAR more damaging to the author of those comments than it is to us. We don't need to do anything further about this. Trust me, I know how this works and it's over! I just want to say that it is more damaging to the author of those comments only in eyes of those who knows all history. Imagine for a moment that I am just ordinary programmer who wants to download GMP from gmplib.org. What I see when I read about MPIR: * something accused of (past) LGPL violations * accused of academic fraud * accused of launching defamation campaing * funded by Microsoft (in such context - by Evil Empire Microsoft ) So I'll just conclude that MPIR team is evil, and won't read MPIR/SAGE forum where I can find the truth. I think that such situation is damaging enough to the MPIR (team) reputation to take _something_ to get this text out from gmplib.org However, it is up to you to decide what to do in this situation. If you'll decide to write something to someone, I'll be happy to sign it. Good luck! -- With best regards, Sergey mailto:sergey.bochka...@alglib.net -- 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
Re: [sage-devel] Changelogs in SPKG.txt
On Tue, May 25, 2010 at 10:41 AM, Robert Bradshaw rober...@math.washington.edu wrote: Hi all, I just had a new spkg (rightly) rejected because it didn't have a changelog entry in SPKG.txt , as specified by [1], Does anyone know why are we manually keeping a text changelog when the files under our control are already under revision control? Because of Abshoff Momentum? I can think of no other reason. I think this is silly. It makes more sense to reject a patch because the revision history comment is bad. Right now, with our dual system, the hg history comments can easily be bad, since one always has the SPKG.txt to back it up. So there are real negative consequences to the current confusing system. -- William - Robert [1] http://www.sagemath.org/doc/developer/producing_spkgs.html#the-file-spkg-txt . -- 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: [mpir-devel] Re: MPIR documentation and the GMP website
In fact, unless I am mistaken refresh your browser! Now let's all forget this ever happened and let's get on with our jobs. Bill. On 25 May 2010 18:47, Bill Hart goodwillh...@googlemail.com wrote: My point is, imagine how damaging it will be to the author of those comments if they just leave them there. Trust me, they'll go of their own accord. We don't need to touch this one. If someone else feels strongly that action needs to be taken, well I won't be getting in their way. As for me, on with my actual job!! Bill. On 25 May 2010 18:41, Sergey Bochkanov sergey.bochka...@alglib.net wrote: Hello, Bill. So it is established that we are being accused of academic fraud for removing the author information WHEN IT WAS DONE BY SOMEONE ON THE GMP TEAM in the actual version of GMP we forked from!! Confirmed. I think what is currently on the GMP website is FAR more damaging to the author of those comments than it is to us. We don't need to do anything further about this. Trust me, I know how this works and it's over! I just want to say that it is more damaging to the author of those comments only in eyes of those who knows all history. Imagine for a moment that I am just ordinary programmer who wants to download GMP from gmplib.org. What I see when I read about MPIR: * something accused of (past) LGPL violations * accused of academic fraud * accused of launching defamation campaing * funded by Microsoft (in such context - by Evil Empire Microsoft ) So I'll just conclude that MPIR team is evil, and won't read MPIR/SAGE forum where I can find the truth. I think that such situation is damaging enough to the MPIR (team) reputation to take _something_ to get this text out from gmplib.org However, it is up to you to decide what to do in this situation. If you'll decide to write something to someone, I'll be happy to sign it. Good luck! -- With best regards, Sergey mailto:sergey.bochka...@alglib.net -- 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: Changelogs in SPKG.txt
On May 25, 1:50 pm, William Stein wst...@gmail.com wrote: On Tue, May 25, 2010 at 10:41 AM, Robert Bradshaw rober...@math.washington.edu wrote: Hi all, I just had a new spkg (rightly) rejected because it didn't have a changelog entry in SPKG.txt , as specified by [1], Does anyone know why are we manually keeping a text changelog when the files under our control are already under revision control? Because of Abshoff Momentum? I can think of no other reason. I think this is silly. It makes more sense to reject a patch because the revision history comment is bad. Right now, with our dual system, the hg history comments can easily be bad, since one always has the SPKG.txt to back it up. So there are real negative consequences to the current confusing system. -- William Although I have to say that for someone looking to update an spkg, it is very helpful to have the big picture without scrolling through HG comments (esp. for HG-phobes), similarly to how it is quite useful to have the changelog.txt/HISTORY.txt file even though we have the HG log for Sage proper. It is much easier to look quickly to see what's been going on. Say, if one has a text editor open but has no interest in opening a terminal window and remembering the commands that get their HG working... and don't even get me started on trying to add HG from inside Sage to my PATH, that shouldn't be *required* to see what has happened in an spkg at the highest level. In fact, I'd say the solution is to start requiring better HG messages in *addition to* the spkg upgrades, just like has been happening slowly on the main patches. I'll also point out that someone said HG comments sometimes only show up one line at a time, or default display only one line, or something. So let's keep both, in the name of EVEN better documentation, but make it clear both should be good. Or am I the only one who finds SPKG.txt changes helpful? - 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: Changelogs in SPKG.txt
On 5/25/10 12:41 PM, Robert Bradshaw wrote: Hi all, I just had a new spkg (rightly) rejected because it didn't have a changelog entry in SPKG.txt , as specified by [1], Does anyone know why are we manually keeping a text changelog when the files under our control are already under revision control? +1 to just making the commit messages more descriptive, as well as insisting that things like: Applying a patch; this patch should be removed when this package is updated because the patch has been applied upstream are documented in the SPKG.txt. 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: Changelogs in SPKG.txt
On May 25, 2010, at 11:23 AM, kcrisman wrote: On May 25, 1:50 pm, William Stein wst...@gmail.com wrote: On Tue, May 25, 2010 at 10:41 AM, Robert Bradshaw rober...@math.washington.edu wrote: Hi all, I just had a new spkg (rightly) rejected because it didn't have a changelog entry in SPKG.txt , as specified by [1], Does anyone know why are we manually keeping a text changelog when the files under our control are already under revision control? Because of Abshoff Momentum? I can think of no other reason. I think this is silly. It makes more sense to reject a patch because the revision history comment is bad. Right now, with our dual system, the hg history comments can easily be bad, since one always has the SPKG.txt to back it up. So there are real negative consequences to the current confusing system. -- William Although I have to say that for someone looking to update an spkg, it is very helpful to have the big picture without scrolling through HG comments (esp. for HG-phobes), similarly to how it is quite useful to have the changelog.txt/HISTORY.txt file even though we have the HG log for Sage proper. It is much easier to look quickly to see what's been going on. $SAGE_ROOT/HISTORY.txt is woefully out of date. Hello folks, Sage 3.2.3 was released on January 5th, 2009. It is available at http://www.sagemath.org/download.html * About Sage (http://www.sagemath.org) Say, if one has a text editor open but has no interest in opening a terminal window and remembering the commands that get their HG working... and don't even get me started on trying to add HG from inside Sage to my PATH, that shouldn't be *required* to see what has happened in an spkg at the highest level. In fact, I'd say the solution is to start requiring better HG messages in *addition to* the spkg upgrades, just like has been happening slowly on the main patches. I'll also point out that someone said HG comments sometimes only show up one line at a time, or default display only one line, or something. So let's keep both, in the name of EVEN better documentation, but make it clear both should be good. Or am I the only one who finds SPKG.txt changes helpful? I think they are valuable, e.g. for recording license, build, maintainer, and build information. If people are averse to actually firing up hg to see what changed, we could always dump hg log to CHANGELOG.txt or something like that on packaging it up, rather than force users to put two separate, quality commit messages in. - 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: Changelogs in SPKG.txt
On Tue, May 25, 2010 at 11:23 AM, kcrisman kcris...@gmail.com wrote: On May 25, 1:50 pm, William Stein wst...@gmail.com wrote: On Tue, May 25, 2010 at 10:41 AM, Robert Bradshaw rober...@math.washington.edu wrote: Hi all, I just had a new spkg (rightly) rejected because it didn't have a changelog entry in SPKG.txt , as specified by [1], Does anyone know why are we manually keeping a text changelog when the files under our control are already under revision control? Because of Abshoff Momentum? I can think of no other reason. I think this is silly. It makes more sense to reject a patch because the revision history comment is bad. Right now, with our dual system, the hg history comments can easily be bad, since one always has the SPKG.txt to back it up. So there are real negative consequences to the current confusing system. -- William Although I have to say that for someone looking to update an spkg, it is very helpful to have the big picture without scrolling through HG comments (esp. for HG-phobes), similarly to how it is quite useful to have the changelog.txt/HISTORY.txt file even though we have the HG log for Sage proper. It is much easier to look quickly to see what's been going on. Say, if one has a text editor open but has no interest in opening a terminal window and remembering the commands that get their HG working... and don't even get me started on trying to add HG from inside Sage to my PATH, that shouldn't be *required* to see what has happened in an spkg at the highest level. In fact, I'd say the solution is to start requiring better HG messages in *addition to* the spkg upgrades, just like has been happening slowly on the main patches. I'll also point out that someone said HG comments sometimes only show up one line at a time, or default display only one line, or something. So let's keep both, in the name of EVEN better documentation, but make it clear both should be good. -1 If the problem is really that it is way too hard for you to remember sage -hg log then we can just put that line in SPKG.txt.E.g., == History == Please type sage -hg log for a log of all changes to this spkg. -- Or if that is too hard, then the sage -pkg script could just have a line sage -hg log LOG.txt in it... -- 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: Changelogs in SPKG.txt
On May 25, 2010, at 11:26 AM, Jason Grout wrote: On 5/25/10 12:41 PM, Robert Bradshaw wrote: Hi all, I just had a new spkg (rightly) rejected because it didn't have a changelog entry in SPKG.txt , as specified by [1], Does anyone know why are we manually keeping a text changelog when the files under our control are already under revision control? +1 to just making the commit messages more descriptive, as well as insisting that things like: Applying a patch; this patch should be removed when this package is updated because the patch has been applied upstream are documented in the SPKG.txt. This information is very useful, and probably better not in a changelog, where it will scroll off the bottom and be forgotten. I'd be up for a requirement that every patch we make should be listed in SPKG.txt, with a bit of explanation of why (and, when, if ever, it will become unnecessary), right next to the version information. That'd be helpful. - 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: Changelogs in SPKG.txt
On 5/25/10 1:23 PM, kcrisman wrote: On May 25, 1:50 pm, William Steinwst...@gmail.com wrote: On Tue, May 25, 2010 at 10:41 AM, Robert Bradshaw rober...@math.washington.edu wrote: Hi all, I just had a new spkg (rightly) rejected because it didn't have a changelog entry in SPKG.txt , as specified by [1], Does anyone know why are we manually keeping a text changelog when the files under our control are already under revision control? Because of Abshoff Momentum? I can think of no other reason. I think this is silly. It makes more sense to reject a patch because the revision history comment is bad. Right now, with our dual system, the hg history comments can easily be bad, since one always has the SPKG.txt to back it up. So there are real negative consequences to the current confusing system. -- William Although I have to say that for someone looking to update an spkg, it is very helpful to have the big picture without scrolling through HG comments (esp. for HG-phobes), similarly to how it is quite useful to have the changelog.txt/HISTORY.txt file even though we have the HG log for Sage proper. It is much easier to look quickly to see what's been going on. Say, if one has a text editor open but has no interest in opening a terminal window and remembering the commands that get their HG working... and don't even get me started on trying to add HG from inside Sage to my PATH, that shouldn't be *required* to see what has happened in an spkg at the highest level. In fact, I'd say the solution is to start requiring better HG messages in *addition to* the spkg upgrades, just like has been happening slowly on the main patches. I'll also point out that someone said HG comments sometimes only show up one line at a time, or default display only one line, or something. So let's keep both, in the name of EVEN better documentation, but make it clear both should be good. Or am I the only one who finds SPKG.txt changes helpful? When updating an spkg, one must check in their changes via mercurial anyway, so I'm not sure how using mercurial to check old changes is such a burden. Note that right now, the changelog includes two pieces of information that should be separated: 1. tips for updating an spkg, including why patches are in the spkg and when the patches should possibly be deleted 2. Chronological update information. I agree with Robert that (1) should stay in the spkg, but not organized in a changelog, but instead organized by patch, or in the updating this spkg section. (2) is not usually really that useful in a file, and is what is redundant with a mercurial log. 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: Changelogs in SPKG.txt
On Tue, May 25, 2010 at 11:36 AM, Robert Bradshaw rober...@math.washington.edu wrote: On May 25, 2010, at 11:26 AM, Jason Grout wrote: On 5/25/10 12:41 PM, Robert Bradshaw wrote: Hi all, I just had a new spkg (rightly) rejected because it didn't have a changelog entry in SPKG.txt , as specified by [1], Does anyone know why are we manually keeping a text changelog when the files under our control are already under revision control? +1 to just making the commit messages more descriptive, as well as insisting that things like: Applying a patch; this patch should be removed when this package is updated because the patch has been applied upstream are documented in the SPKG.txt. This information is very useful, and probably better not in a changelog, where it will scroll off the bottom and be forgotten. I'd be up for a requirement that every patch we make should be listed in SPKG.txt, with a bit of explanation of why (and, when, if ever, it will become unnecessary), right next to the version information. That'd be helpful. Having info about patches is a good idea. I'm definitely not convinced SPKG.txt is the right place for it. I would install propose something *like* for every patch foo, having a file foo.wtf (or something) in patches/ that explains the patch. E.g., $ cd patches $ ls foo foo.patch foo.wtf The file foo.wtf would document why foo is done. Doing things like this will greatly increase the chances that docs are updated when they should be. This is similar to having docstrings in functions, instead of some other distant place. 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: Changelogs in SPKG.txt
changelog, where it will scroll off the bottom and be forgotten. I'd This is my main point, as well as for those who in the future will just be learning hg and find going the right directory etc. difficult. As for HISTORY.txt, I don't understand why that isn't updated, since http://www.sagemath.org/mirror/src/changelogs/HISTORY.txt is just fine! -- 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: Changelogs in SPKG.txt
On May 25, 2010, at 11:50 AM, William Stein wrote: On Tue, May 25, 2010 at 11:36 AM, Robert Bradshaw rober...@math.washington.edu wrote: On May 25, 2010, at 11:26 AM, Jason Grout wrote: On 5/25/10 12:41 PM, Robert Bradshaw wrote: Hi all, I just had a new spkg (rightly) rejected because it didn't have a changelog entry in SPKG.txt , as specified by [1], Does anyone know why are we manually keeping a text changelog when the files under our control are already under revision control? +1 to just making the commit messages more descriptive, as well as insisting that things like: Applying a patch; this patch should be removed when this package is updated because the patch has been applied upstream are documented in the SPKG.txt. This information is very useful, and probably better not in a changelog, where it will scroll off the bottom and be forgotten. I'd be up for a requirement that every patch we make should be listed in SPKG.txt, with a bit of explanation of why (and, when, if ever, it will become unnecessary), right next to the version information. That'd be helpful. Having info about patches is a good idea. I'm definitely not convinced SPKG.txt is the right place for it. I would install propose something *like* for every patch foo, having a file foo.wtf (or something) in patches/ that explains the patch. E.g., $ cd patches $ ls foo foo.patch foo.wtf The file foo.wtf would document why foo is done. Doing things like this will greatly increase the chances that docs are updated when they should be. This is similar to having docstrings in functions, instead of some other distant place. I actually think that this will make it less likely to get looked at and appropriately cleaned up when versions are bumped. When I'd go to SPKG.txt to update the version information, I would see Version x.y.z, with these patches: ... and if there are notes about stuff being fixed upstream, I'd take care of it then, rather than having to look at each patch/about file individually. - 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: Changelogs in SPKG.txt
On Tue, May 25, 2010 at 12:02 PM, kcrisman kcris...@gmail.com wrote: changelog, where it will scroll off the bottom and be forgotten. I'd This is my main point, as well as for those who in the future will just be learning hg and find going the right directory etc. difficult. sage -hg log |more ?? As for HISTORY.txt, I don't understand why that isn't updated, since http://www.sagemath.org/mirror/src/changelogs/HISTORY.txt is just fine! -- 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: Changelogs in SPKG.txt
On 5/25/10 2:01 PM, Robert Bradshaw wrote: On May 25, 2010, at 11:50 AM, William Stein wrote: Having info about patches is a good idea. I'm definitely not convinced SPKG.txt is the right place for it. I would install propose something *like* for every patch foo, having a file foo.wtf (or something) in patches/ that explains the patch. E.g., $ cd patches $ ls foo foo.patch foo.wtf The file foo.wtf would document why foo is done. Doing things like this will greatly increase the chances that docs are updated when they should be. This is similar to having docstrings in functions, instead of some other distant place. I actually think that this will make it less likely to get looked at and appropriately cleaned up when versions are bumped. When I'd go to SPKG.txt to update the version information, I would see Version x.y.z, with these patches: ... and if there are notes about stuff being fixed upstream, I'd take care of it then, rather than having to look at each patch/about file individually. +1 to Robert's comments. Already, I don't ever make or use foo.patch files anymore because they are completely redundant and one more easily-forgotten step to make (they should be totally automated if they are required). If we added foo.why files (I think 'why' is a nicer extension :), that would just add a layer of complexity onto the updating process. So +1 to having all of the necessary instructions/metadata for updating an spkg right in the SPKG.txt file. 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: [mpir-devel] Re: MPIR documentation and the GMP website
Hello, Bill. In fact, unless I am mistaken refresh your browser! Now let's all forget this ever happened and let's get on with our jobs. +1! -- With best regards, Sergey mailto:sergey.bochka...@alglib.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: Changelogs in SPKG.txt
On May 25, 3:05 pm, William Stein wst...@gmail.com wrote: On Tue, May 25, 2010 at 12:02 PM, kcrisman kcris...@gmail.com wrote: changelog, where it will scroll off the bottom and be forgotten. I'd This is my main point, as well as for those who in the future will just be learning hg and find going the right directory etc. difficult. sage -hg log |more ?? Example: r-2.10.1.p1 Changes for .p0: hg log version changeset: 33:66f45042d4b4 user:David Kirkby david.kir...@onetel.net date:Tue Feb 16 20:54:03 2010 + summary: #8285 Update R's spkg-install to work on Solaris SPKG.txt version === r-2.10.1.p0 (David Kirkby, February 16th 2010) === * Several items all covered by #8285 * Added the undocumented option --without-ICU on Solaris, as that allows R to build - otherwise it fails. I suspect the ideal solution would be to add the ICU library from http://site.icu-project.org/ but this option does allow R to build. * Ensure SAGE64 will add the -m64 option on any platform, not just OS X as before. * Removed all references to the option --with-iconv=no, as R needs iconv now - it is no longer optional - see http://trac.sagemath.org/sage_trac/ticket/8191 * Implement a test for X on Solaris, as the previous test in spkg-install would always fail on Solaris, as Solaris lacks the header file checked for, despite the fact X support works fine. So now I check for a library on Solaris. Are you really suggesting that the commit message should be this long? Maybe they should be! But I've never seen one that long in Sage, so at least there is a defacto rule that commit message are short short short. This sort of thing should be somewhere, and to be honest having it all in one place is very nice. I agree that other messages I've seen (both in SPKG.txt or commit messages) are less informative. And I reiterate that I recall somewhere a suggestion on sage-devel that commit messages should be one line long. Does no one else remember that? Or did it mean it should not have any carriage returns, but be as long as it wants (in which case this was not clear at all)? - 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
Re: [sage-devel] Re: Changelogs in SPKG.txt
On May 25, 2010, at 12:30 PM, Jason Grout jason-s...@creativetrax.com wrote: On 5/25/10 2:01 PM, Robert Bradshaw wrote: On May 25, 2010, at 11:50 AM, William Stein wrote: Having info about patches is a good idea. I'm definitely not convinced SPKG.txt is the right place for it. I would install propose something *like* for every patch foo, having a file foo.wtf (or something) in patches/ that explains the patch. E.g., $ cd patches $ ls foo foo.patch foo.wtf The file foo.wtf would document why foo is done. Doing things like this will greatly increase the chances that docs are updated when they should be. This is similar to having docstrings in functions, instead of some other distant place. I actually think that this will make it less likely to get looked at and appropriately cleaned up when versions are bumped. When I'd go to SPKG.txt to update the version information, I would see Version x.y.z, with these patches: ... and if there are notes about stuff being fixed upstream, I'd take care of it then, rather than having to look at each patch/about file individually. +1 to Robert's comments. Already, I don't ever make or use foo.patch files anymore because they are completely redundant and one more easily-forgotten step to make (they should be totally automated if they are required). Interesting If we added foo.why files (I think 'why' is a nicer extension :), that would just add a layer of complexity onto the updating process. So +1 to having all of the necessary instructions/metadata for updating an spkg right in the SPKG.txt file. 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
Re: [sage-devel] Re: Changelogs in SPKG.txt
On May 25, 2010, at 12:30 PM, Jason Grout jason-s...@creativetrax.com wrote: On 5/25/10 2:01 PM, Robert Bradshaw wrote: On May 25, 2010, at 11:50 AM, William Stein wrote: Having info about patches is a good idea. I'm definitely not convinced SPKG.txt is the right place for it. I would install propose something *like* for every patch foo, having a file foo.wtf (or something) in patches/ that explains the patch. E.g., $ cd patches $ ls foo foo.patch foo.wtf The file foo.wtf would document why foo is done. Doing things like this will greatly increase the chances that docs are updated when they should be. This is similar to having docstrings in functions, instead of some other distant place. I actually think that this will make it less likely to get looked at and appropriately cleaned up when versions are bumped. When I'd go to SPKG.txt to update the version information, I would see Version x.y.z, with these patches: ... and if there are notes about stuff being fixed upstream, I'd take care of it then, rather than having to look at each patch/about file individually. +1 to Robert's comments. Already, I don't ever make or use foo.patch files anymore because they are completely redundant Interesting. If I remember correctly, you and I had a long discussion about those patch files, in which I was totally against them, and you argued for them. I think they are there now mostly because of you. I'm still against them and consider them a waste of time, just like the log in SPKG.txt. I am glad we now agree. and one more easily-forgotten step to make (they should be totally automated if they are required). If we added foo.why files (I think 'why' is a nicer extension :), that would just add a layer of complexity onto the updating process. So +1 to having all of the necessary instructions/metadata for updating an spkg right in the SPKG.txt file. There is a layer of complexity with either approach. One puts the instructions next to the file being patched, and one puts them in a separate file. It's just like putting docs in docstrings versus the Sage Constructions Guide. 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: Changelogs in SPKG.txt
On 5/25/10 2:52 PM, William A. Stein wrote: +1 to Robert's comments. Already, I don't ever make or use foo.patch files anymore because they are completely redundant and one more easily-forgotten step to make (they should be totally automated if they are required). Interesting I'm not sure what to make of your short comment, so let me elaborate. Typically, to update an spkg, I move the old src/ directory to src-old, untar the new source into src/, and then do a 3-way merge: kdiff3 src-old/file src/file patch/file saving the result in the patch/ directory. Most of the time this is easy, but occasionally there are conflicts that need to be sorted out. 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: Changelogs in SPKG.txt
On May 25, 2010, at 12:35 PM, kcrisman wrote: On May 25, 3:05 pm, William Stein wst...@gmail.com wrote: On Tue, May 25, 2010 at 12:02 PM, kcrisman kcris...@gmail.com wrote: changelog, where it will scroll off the bottom and be forgotten. I'd This is my main point, as well as for those who in the future will just be learning hg and find going the right directory etc. difficult. sage -hg log |more ?? Example: r-2.10.1.p1 Changes for .p0: hg log version changeset: 33:66f45042d4b4 user:David Kirkby david.kir...@onetel.net date:Tue Feb 16 20:54:03 2010 + summary: #8285 Update R's spkg-install to work on Solaris SPKG.txt version === r-2.10.1.p0 (David Kirkby, February 16th 2010) === * Several items all covered by #8285 * Added the undocumented option --without-ICU on Solaris, as that allows R to build - otherwise it fails. I suspect the ideal solution would be to add the ICU library from http://site.icu-project.org/ but this option does allow R to build. * Ensure SAGE64 will add the -m64 option on any platform, not just OS X as before. * Removed all references to the option --with-iconv=no, as R needs iconv now - it is no longer optional - see http://trac.sagemath.org/sage_trac/ticket/8191 * Implement a test for X on Solaris, as the previous test in spkg-install would always fail on Solaris, as Solaris lacks the header file checked for, despite the fact X support works fine. So now I check for a library on Solaris. Are you really suggesting that the commit message should be this long? Maybe they should be! Yes, I've got no problem with long commit messages, the more info the better (especially for obscure build files and configure scripts, where the changes are far from self documenting). There are some nice commit messages in the combinat code too. But I've never seen one that long in Sage, so at least there is a defacto rule that commit message are short short short. This is probably due to laziness more than anything, though for some things short messages are sufficient (e.g. the code should have enough documentation that #X - implemented Y may be sufficient). This sort of thing should be somewhere, and to be honest having it all in one place is very nice. I agree that other messages I've seen (both in SPKG.txt or commit messages) are less informative. And I reiterate that I recall somewhere a suggestion on sage-devel that commit messages should be one line long. Does no one else remember that? Or did it mean it should not have any carriage returns, but be as long as it wants (in which case this was not clear at all)? Only the first line shows up by default so it should be self-contained and concise (so that the listings are short). hg log -v will show long commit messages, and hg log -p will print out the patches as well. - 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] A function to compute Bezout coefficients ?
Hello, everyone ! I've been looking for a function that allows one to compute Bezout coefficients of two numbers (say natural numbers). There is the GCD function, but I haven't found anything about Bezout coefficients. This is not complicated to write one, but it would be better if it was included somehwere in Sage. Is there already something like that ? Thank you for your help ! Alex -- 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: Can LaTeX of strings be improved?
On May 24, 9:11 pm, ablondin alexandre.blondin.ma...@gmail.com
wrote:
You're right ! It doesn't work with the view() function. On the other
hand, when I select latex instead of sage and I enter the command
\sage{A()}
it displays 123 on the first line and 23 on the second line, with the
2's aligned properly, i.e. it handles the newlines and indentation as
desired. That said, I guess it's not a clean solution...
Another not clean solution: typeset strings with
\begin{verbatim}
string
\end{verbatim}
and then put \\begin{verbatim} in the jsmath_avoid list. This
results in inconsistent behavior: jsMath output appears in blue, while
LaTeX output appears in black.
Another option: use the \verb option for jsMath, but break the string
at newlines and typeset each line individually, inserting line breaks
explicitly in the html produced by the JSMath class in sage/misc/
latex.py.
--
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: Changelogs in SPKG.txt
And I reiterate that I recall somewhere a suggestion on sage-devel that commit messages should be one line long. Does no one else remember that? Or did it mean it should not have any carriage returns, but be as long as it wants (in which case this was not clear at all)? Only the first line shows up by default so it should be self-contained and concise (so that the listings are short). hg log -v will show long commit messages, and hg log -p will print out the patches as well. Okay, this must be what I am remembering. In that case I say we should start asking officially in the developer's guide for long commit messages with short intros, and with a very explicit mention there that hg_sage.log(verbose=True) will give full info. I agree that the sage-combinat folks have nice long informative ones! I still like the redundancy, and see that as much less of an obstacle to developing than cryptic documents, but so be it. There remains one additional problem. If we have been putting long information into SPKG.txt for a while with almost no information in the commit messages, getting rid of the SPKG.txt ones will leave a fairly large piece of their history mysterious at best. Solutions? - 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
Re: [sage-devel] A function to compute Bezout coefficients ?
Hello, I've been looking for a function that allows one to compute Bezout coefficients of two numbers (say natural numbers). There is the GCD function, but I haven't found anything about Bezout coefficients. This is not complicated to write one, but it would be better if it was included somehwere in Sage. Is there already something like that ? You should use xgcd: sage: xgcd(5, 7) (1, 3, -2) sage: g,a,b = xgcd(5, 7) sage: a*5 + b*7 1 --Mike -- 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: Changelogs in SPKG.txt
On 5/25/10 2:56 PM, William A. Stein wrote: On May 25, 2010, at 12:30 PM, Jason Groutjason-s...@creativetrax.com wrote: On 5/25/10 2:01 PM, Robert Bradshaw wrote: On May 25, 2010, at 11:50 AM, William Stein wrote: Having info about patches is a good idea. I'm definitely not convinced SPKG.txt is the right place for it. I would install propose something *like* for every patch foo, having a file foo.wtf (or something) in patches/ that explains the patch. E.g., $ cd patches $ ls foo foo.patch foo.wtf The file foo.wtf would document why foo is done. Doing things like this will greatly increase the chances that docs are updated when they should be. This is similar to having docstrings in functions, instead of some other distant place. I actually think that this will make it less likely to get looked at and appropriately cleaned up when versions are bumped. When I'd go to SPKG.txt to update the version information, I would see Version x.y.z, with these patches: ... and if there are notes about stuff being fixed upstream, I'd take care of it then, rather than having to look at each patch/about file individually. +1 to Robert's comments. Already, I don't ever make or use foo.patch files anymore because they are completely redundant Interesting. If I remember correctly, you and I had a long discussion about those patch files, in which I was totally against them, and you argued for them. I think they are there now mostly because of you. I'm still against them and consider them a waste of time, just like the log in SPKG.txt. I am glad we now agree. Yes. I (and at least one other developer that refused to work on spkgs while we didn't use the standard distribute patch files method) argued that we should only have patch files, while you and Michael argued that we should only have the actual patched files. I've learned to deal with it now, and the three-way merging step makes the patch file largely unnecessary, though it's still an extra step and hassle to figure out exactly what file under src/ a patched file in patches/ corresponds to. If we just distributed patch files, that information would be contained in the patch, automating yet one more mindless tedious thing that takes time and resources. In fact, I believe we (you?) proposed adding a foo.file file as well that would just contain the file path to the file that foo patched. I worked up a shell script to automatically apply patched files based on that, but alas, the foo.file file never caught on... and one more easily-forgotten step to make (they should be totally automated if they are required). If we added foo.why files (I think 'why' is a nicer extension :), that would just add a layer of complexity onto the updating process. So +1 to having all of the necessary instructions/metadata for updating an spkg right in the SPKG.txt file. There is a layer of complexity with either approach. One puts the instructions next to the file being patched, and one puts them in a separate file. It's just like putting docs in docstrings versus the Sage Constructions Guide. I agree that both solutions require work. The layer of complexity I was talking about was the needing to open yet more files to make sure that you covered all of your bases in updating an spkg. It seems much easier to have all the necessary information in one place (easier to remember, find, and update). 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: Changelogs in SPKG.txt
On Tue, May 25, 2010 at 12:56 PM, William A. Stein wst...@gmail.com wrote: Interesting. If I remember correctly, you and I had a long discussion about those patch files, in which I was totally against them, and you argued for them. I think they are there now mostly because of you. I'm still against them and consider them a waste of time, just like the log in SPKG.txt. I am glad we now agree. The one use they do have is that they allow you to view previous changes in the history without having to go back and download the original version of source file in order to see the differences. For example, if I wanted to see the state of a patch from a few versions ago, then I couldn't just look in the history, I'd have to go download the old version, find the file, and then run diff. --Mike -- 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: Changelogs in SPKG.txt
On 5/25/10 3:07 PM, kcrisman wrote: There remains one additional problem. If we have been putting long information into SPKG.txt for a while with almost no information in the commit messages, getting rid of the SPKG.txt ones will leave a fairly large piece of their history mysterious at best. Solutions? Make the delete commit have the deleted changelog as the commit message? :) 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: Changelogs in SPKG.txt
On May 25, 2010, at 1:11 PM, Jason Grout wrote: On 5/25/10 2:56 PM, William A. Stein wrote: On May 25, 2010, at 12:30 PM, Jason Groutjason- s...@creativetrax.com wrote: On 5/25/10 2:01 PM, Robert Bradshaw wrote: On May 25, 2010, at 11:50 AM, William Stein wrote: Having info about patches is a good idea. I'm definitely not convinced SPKG.txt is the right place for it. I would install propose something *like* for every patch foo, having a file foo.wtf (or something) in patches/ that explains the patch. E.g., $ cd patches $ ls foo foo.patch foo.wtf The file foo.wtf would document why foo is done. Doing things like this will greatly increase the chances that docs are updated when they should be. This is similar to having docstrings in functions, instead of some other distant place. I actually think that this will make it less likely to get looked at and appropriately cleaned up when versions are bumped. When I'd go to SPKG.txt to update the version information, I would see Version x.y.z, with these patches: ... and if there are notes about stuff being fixed upstream, I'd take care of it then, rather than having to look at each patch/about file individually. +1 to Robert's comments. Already, I don't ever make or use foo.patch files anymore because they are completely redundant Interesting. If I remember correctly, you and I had a long discussion about those patch files, in which I was totally against them, and you argued for them. I think they are there now mostly because of you. I'm still against them and consider them a waste of time, just like the log in SPKG.txt. I am glad we now agree. Yes. I (and at least one other developer that refused to work on spkgs while we didn't use the standard distribute patch files method) argued that we should only have patch files, while you and Michael argued that we should only have the actual patched files. I've learned to deal with it now, and the three-way merging step makes the patch file largely unnecessary, though it's still an extra step and hassle to figure out exactly what file under src/ a patched file in patches/ corresponds to. If we just distributed patch files, that information would be contained in the patch, automating yet one more mindless tedious thing that takes time and resources. In fact, I believe we (you?) proposed adding a foo.file file as well that would just contain the file path to the file that foo patched. I worked up a shell script to automatically apply patched files based on that, but alas, the foo.file file never caught on... One difficulty is that there are some (if I remember) patches that are only done to some systems, but not others. I too would find it easier if the /patches directory were actual patches that were applied to / src automatically, but that's not a big sticking point for me. Was the problem that then patch became a dependancy? and one more easily-forgotten step to make (they should be totally automated if they are required). If we added foo.why files (I think 'why' is a nicer extension :), that would just add a layer of complexity onto the updating process. So +1 to having all of the necessary instructions/metadata for updating an spkg right in the SPKG.txt file. There is a layer of complexity with either approach. One puts the instructions next to the file being patched, and one puts them in a separate file. It's just like putting docs in docstrings versus the Sage Constructions Guide. I agree that both solutions require work. The layer of complexity I was talking about was the needing to open yet more files to make sure that you covered all of your bases in updating an spkg. It seems much easier to have all the necessary information in one place (easier to remember, find, and update). +1, especially for your example of applied upstream, not needed after version Z. - 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: Changelogs in SPKG.txt
On May 25, 2010, at 1:17 PM, Jason Grout wrote: On 5/25/10 3:07 PM, kcrisman wrote: There remains one additional problem. If we have been putting long information into SPKG.txt for a while with almost no information in the commit messages, getting rid of the SPKG.txt ones will leave a fairly large piece of their history mysterious at best. Solutions? Make the delete commit have the deleted changelog as the commit message? :) Or we can use queues to retroactively flesh out the history (though does this destroy timestamp information?) - 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] A function to compute Bezout coefficients ?
Is anyone else getting duplicate copies of Sage messages? -- Tim Mike Hansen wrote: Hello, I've been looking for a function that allows one to compute Bezout coefficients of two numbers (say natural numbers). There is the GCD function, but I haven't found anything about Bezout coefficients. This is not complicated to write one, but it would be better if it was included somehwere in Sage. Is there already something like that ? You should use xgcd: sage: xgcd(5, 7) (1, 3, -2) sage: g,a,b = xgcd(5, 7) sage: a*5 + b*7 1 --Mike -- 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: A function to compute Bezout coefficients ?
Thanks ! I would never have guessed the name ! Alex On 25 mai, 16:28, Tim Daly d...@axiom-developer.org wrote: Is anyone else getting duplicate copies of Sage messages? -- Tim Mike Hansen wrote: Hello, I've been looking for a function that allows one to compute Bezout coefficients of two numbers (say natural numbers). There is the GCD function, but I haven't found anything about Bezout coefficients. This is not complicated to write one, but it would be better if it was included somehwere in Sage. Is there already something like that ? You should use xgcd: sage: xgcd(5, 7) (1, 3, -2) sage: g,a,b = xgcd(5, 7) sage: a*5 + b*7 1 --Mike -- 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 and Amazon EC2?
Way to go... this would be excellent - instant scalable sage computing: check out the kind of thing BIx folks are doing for the community: http://bcbio.wordpress.com/2010/05/08/automated-build-environment-for-bioinformatics-cloud-images/ You have to get sage into this party - actually I think a friend of mine has done an AMI with sage (+ a comprehensive R environment) But the idea of pulling down the latest build and creating a sage based AMI each release is just bang on... Perhaps there's a collaboration opportunity with these guys. They have some config and build stuff that looks very friendly for customizing the image. Obviously to run a server instance there would be some storage to configure but it looks like the folks at bluecollar etc. are discussing this stuff relative to their build. -- 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: A function to compute Bezout coefficients ?
On May 25, 2010, at 1:42 PM, ablondin wrote: Thanks ! I would never have guessed the name ! Alex And I had never heard of the term Bezout coefficients :). The is an abbreviation for extended gcd. On 25 mai, 16:28, Tim Daly d...@axiom-developer.org wrote: Is anyone else getting duplicate copies of Sage messages? -- Tim Mike Hansen wrote: Hello, I've been looking for a function that allows one to compute Bezout coefficients of two numbers (say natural numbers). There is the GCD function, but I haven't found anything about Bezout coefficients. This is not complicated to write one, but it would be better if it was included somehwere in Sage. Is there already something like that ? You should use xgcd: sage: xgcd(5, 7) (1, 3, -2) sage: g,a,b = xgcd(5, 7) sage: a*5 + b*7 1 --Mike -- 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] sage days 23 in Leiden, Holland
Hi, If you've very interested in attending Sage Days 23 http://wiki.sagemath.org/days23 Please send me an offlist email. There may be some funding left for additional people (mainly lodging and possibly travel within Europe). It would be good to have a few more people around at that workshop who are just generally interested in Sage, and not necessarily the specific topics of the workshops (which aren't that specific: number theory and algebra). -- 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: Can LaTeX of strings be improved?
I couldnt see a solution to this in this thread so heres a related question
The following produces the exact output Id like to produce (to assign to the
_repr_ property of a class)
%latex
N(\mu,\sigma^2)
How can I set things up to do this in a (_repr_) function (as a sage
statement/function call)?
Does a function exist so I call it to produce such an output?
I was hoping something like this would work
from sage.misc.latex import pretty_print
pretty_print_default(True)
pretty_print('N('+'\mu'+','+'\sigma^2'+')')
but all it displays is
N(\mu,\sigma^2)
(hope I didnt miss something too obvious - thanks)
--
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] Make Cephes a standard spkg
Hello, I propose to make Cephes ( http://moshier.net/ and http://www.netlib.org/cephes/ ) a standard SPKG in Sage. In order to complete the Cygwin port on Windows, we need support for c99 complex numbers which the SPKG provides (amongst other things). The SPKG can be found at #8780. The spkg will not install anything except under Cygwin. --Mike -- 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] Make Cephes a standard spkg
On Tue, May 25, 2010 at 6:16 PM, Mike Hansen mhan...@gmail.com wrote: Hello, I propose to make Cephes ( http://moshier.net/ and http://www.netlib.org/cephes/ ) a standard SPKG in Sage. In order to complete the Cygwin port on Windows, we need support for c99 complex numbers which the SPKG provides (amongst other things). The SPKG can be found at #8780. The spkg will not install anything except under Cygwin. = I vote [ X ] Yes! [ ] No, I don't want Sage to work on Windows. 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
Re: [sage-devel] Make Cephes a standard spkg
Is license info available? On Tue, May 25, 2010 at 9:16 PM, Mike Hansen mhan...@gmail.com wrote: Hello, I propose to make Cephes ( http://moshier.net/ and http://www.netlib.org/cephes/ ) a standard SPKG in Sage. In order to complete the Cygwin port on Windows, we need support for c99 complex numbers which the SPKG provides (amongst other things). The SPKG can be found at #8780. The spkg will not install anything except under Cygwin. --Mike -- 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: Make Cephes a standard spkg
On 5/25/10 8:49 PM, David Joyner wrote: Is license info available? According to http://www.netlib.org/cephes/readme Some software in this archive may be from the book _Methods and Programs for Mathematical Functions_ (Prentice-Hall or Simon Schuster International, 1989) or from the Cephes Mathematical Library, a commercial product. In either event, it is copyrighted by the author. What you see here may be used freely but it comes with no support or guarantee. 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: Make Cephes a standard spkg
On Tue, May 25, 2010 at 9:56 PM, Jason Grout jason-s...@creativetrax.com wrote: On 5/25/10 8:49 PM, David Joyner wrote: Is license info available? According to http://www.netlib.org/cephes/readme Some software in this archive may be from the book _Methods and Programs for Mathematical Functions_ (Prentice-Hall or Simon Schuster International, 1989) or from the Cephes Mathematical Library, a commercial product. In either event, it is copyrighted by the author. What you see here may be used freely but it comes with no support or guarantee. Is used freely ambiguous? Does it mean use without cost or freedom to use as you wish? 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
Re: [sage-devel] Re: Make Cephes a standard spkg
On Tue, May 25, 2010 at 6:56 PM, Jason Grout jason-s...@creativetrax.com wrote: On 5/25/10 8:49 PM, David Joyner wrote: Is license info available? It's included in Debian as GPL -- we can just obtain a copy from them. See http://www.mail-archive.com/debian-bugs-clo...@lists.debian.org/msg165325.html --Mike -- 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: Make Cephes a standard spkg
On Tue, May 25, 2010 at 10:00 PM, Mike Hansen mhan...@gmail.com wrote: On Tue, May 25, 2010 at 6:56 PM, Jason Grout jason-s...@creativetrax.com wrote: On 5/25/10 8:49 PM, David Joyner wrote: Is license info available? It's included in Debian as GPL -- we can just obtain a copy from them. See http://www.mail-archive.com/debian-bugs-clo...@lists.debian.org/msg165325.html Thanks, but doesn't this email suggest it is GPLv2? --Mike -- 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
Re: [sage-devel] Re: Make Cephes a standard spkg
On Tue, May 25, 2010 at 7:05 PM, David Joyner wdjoy...@gmail.com wrote: On Tue, May 25, 2010 at 10:00 PM, Mike Hansen mhan...@gmail.com wrote: On Tue, May 25, 2010 at 6:56 PM, Jason Grout jason-s...@creativetrax.com wrote: On 5/25/10 8:49 PM, David Joyner wrote: Is license info available? It's included in Debian as GPL -- we can just obtain a copy from them. See http://www.mail-archive.com/debian-bugs-clo...@lists.debian.org/msg165325.html Thanks, but doesn't this email suggest it is GPLv2? It says the authors' permission email (in the debian/copyright file) does not specify a particular version. --Mike -- 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] Very weird doctest failure on some Macs - help!
Please see http://trac.sagemath.org/sage_trac/ticket/9003 for details. The reason I'm bringing this up on sage-devel is that apparently (I can't really believe this is the actual reason, which is why I say apparently) the following changeset causes a totally unrelated failure - one which does NOT show up when doing the commands by hand (in modules/free_module.py). We would appreciate any ideas, no matter how wacky. - kcrisman changeset: 14321:1451c00a8d44 tag: tip user:Minh Van Nguyen nguyenmi...@gmail.com date:Wed May 19 00:55:29 2010 -0700 summary: 4.4.2 diff -r 26a4be28b4ef -r 1451c00a8d44 sage/version.py --- a/sage/version.py Wed May 19 00:55:29 2010 -0700 +++ b/sage/version.py Wed May 19 00:55:29 2010 -0700 @@ -1,2 +1,2 @@ nodoctests -version='4.4.2.rc0'; date='2010-05-12' +version='4.4.2'; date='2010-05-19' -- 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: A function to compute Bezout coefficients ?
In fact, I'm not sure the term Bezout coefficients is standard, but you can find it on Wikipedia. http://en.wikipedia.org/wiki/B%C3%A9zout%27s_identity They also call these Bezout numbers, since they're linked to the Bezout identity. Alex On 25 mai, 16:44, Robert Bradshaw rober...@math.washington.edu wrote: On May 25, 2010, at 1:42 PM, ablondin wrote: Thanks ! I would never have guessed the name ! Alex And I had never heard of the term Bezout coefficients :). The is an abbreviation for extended gcd. On 25 mai, 16:28, Tim Daly d...@axiom-developer.org wrote: Is anyone else getting duplicate copies of Sage messages? -- Tim Mike Hansen wrote: Hello, I've been looking for a function that allows one to compute Bezout coefficients of two numbers (say natural numbers). There is the GCD function, but I haven't found anything about Bezout coefficients. This is not complicated to write one, but it would be better if it was included somehwere in Sage. Is there already something like that ? You should use xgcd: sage: xgcd(5, 7) (1, 3, -2) sage: g,a,b = xgcd(5, 7) sage: a*5 + b*7 1 --Mike -- 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 athttp://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
Re: [sage-devel] Make Cephes a standard spkg
On 26 May 2010 02:16, Mike Hansen mhan...@gmail.com wrote: Hello, I propose to make Cephes ( http://moshier.net/ and http://www.netlib.org/cephes/ ) a standard SPKG in Sage. In order to complete the Cygwin port on Windows, we need support for c99 complex numbers which the SPKG provides (amongst other things). The SPKG can be found at #8780. The spkg will not install anything except under Cygwin. --Mike It sounds quite a reasonable idea to me. You might want to discuss with Peter Jeremy whether it is desirable to install this on FreeBSD too. It would probably help on older HP-UX releases too, if someone did an HP-UX port. There's some interesting things on http://moshier.net/ (for my engineering mind at least). Dave -- 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
