[sage-devel] Re: sage-2.8.7
On Oct 16, 4:26 pm, David Joyner [EMAIL PROTECTED] wrote: Hi David, This version does not upgrade or install on suse 9.1 amd64. As far as I can tell Suse 9.1 AMD64 ships with gcc 3.3, which is not C99 conform. So flint won't build, you need at least gcc 3.4 or higher. I would not make it a priority since these machines are due to be upgraded, but thought I'd let you know. However, it does not install on suse 10.2 either! In case this helps: Could you please post the lets say 60-100 lines before that? Cheers, Michael sage: An error occurred while installing flint-0.2.p4 Please email sage-develhttp://groups.google.com/group/sage-devel explaining the problem and send the relevant part of of /home/wdj/sagefiles/sage-2.8.7/install.log. Describe your computer, operating system, etc. If you want to try to fix the problem, yourself *don't* just cd to /home/wdj/sagefiles/sage-2.8.7/spkg/build/flint-0.2.p4 and type 'make'. Instead (using bash) type source local/bin/sage-env from the directory /home/wdj/sagefiles/sage-2.8.7 in order to set all environment variables correctly, then cd to /home/wdj/sagefiles/sage-2.8.7/spkg/build/flint-0.2.p4 make[1]: *** [installed/flint-0.2.p4] Error 1 make[1]: Leaving directory `/home/wdj/sagefiles/sage-2.8.7/spkg' real6m3.763s user5m22.186s sys 0m33.797s [EMAIL PROTECTED]:~/sagefiles/sage-2.8.7 ./sage -- | SAGE Version 2.8.7, Release Date: 2007-10-15 | | Type notebook() for the GUI, and license() for information.| -- /usr/bin/env: sage.bin: No such file or directory /home/wdj/sagefiles/sage-2.8.7/local/bin/sage-sage: /home/wdj/sagefiles/sage-2.8.7/local/bin/sage-ipython: sage.bin: bad interpreter: No such file or directory [EMAIL PROTECTED]:~/sagefiles/sage-2.8.7 On 10/16/07, William Stein [EMAIL PROTECTED] wrote: Hi, I have released sage-2.8.7. You can upgrade via sage -upgrade or download the source from sagemath.org. Binaries will be available tomorrow. For a list of patches see: http://sagemath.org/announce/sage-2.8.7.txt I huge number of people helped a great deal with this release, especially Carl Witty, Craig Citro, Robert Bradshaw, Joel Mohler, Michael Abshoff, Martin Albrecht, and *many* other people. Thanks! William -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sage-2.8.7
On Oct 16, 5:46 pm, David Joyner [EMAIL PROTECTED] wrote: On 10/16/07, mabshoff [EMAIL PROTECTED] wrote: On Oct 16, 4:26 pm, David Joyner [EMAIL PROTECTED] wrote: Hi David, Hi David, This version does not upgrade or install on suse 9.1 amd64. As far as I can tell Suse 9.1 AMD64 ships with gcc 3.3, which is not C99 conform. So flint won't build, you need at least gcc 3.4 or higher. I would not make it a priority since these machines are due to be upgraded, but thought I'd let you know. However, it does not install on suse 10.2 either! Okay, but is seems that is unrelated to flint, because the error is caused by cython's pari glue code (see below) In case this helps: Could you please post the lets say 60-100 lines before that? I'm not sure if this is enough or not, but I hope it helps: SNIP that was plenty ;) running install running build running build_py running build_ext building 'sage.libs.pari.gen' extension gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/home/wdj/sagefiles/sage-2.8.7/local//include -I/home/wdj/sagefiles/sage-2.8.7/local//include/csage -I/home/wdj/sagefiles/sage-2.8.7/devel//sage/sage/ext -I/home/wdj/sagefiles/sage-2.8.7/local/include/python2.5 -c sage/libs/pari/gen.c -o build/temp.linux-x86_64-2.5/sage/libs/pari/gen.o -w sage/libs/pari/gen.c: In function '__pyx_f_py_3gen_3gen_factor': sage/libs/pari/gen.c:19784: internal compiler error: in merge_alias_info, at tree-ssa-copy.c:235 Please submit a full bug report, with preprocessed source if appropriate. gcc blows up, there is little we can do about that. Please check if there are updates compilers available for SuSE 10.2. If not you can either install your own gcc from sources or install the optional gcc.spkg. In that case you need to modify $LD_LIBRARY_PATH to also include $SAGE_LOCAL/lib64 before $SAGE_LOCAL/lib on an AMD 64 box. I will have a look at sage/libs/pari/gen.c:19784 and see if there is anything suspicious in that area. Could you please open a ticket along the lines of paru/gen.c causes internal compiler error on OpenSuSE 10.2 and give us uname -a and gcc -v. Cheers, Michael See URL:http://www.suse.de/feedback for instructions. error: command 'gcc' failed with exit status 1 sage: There was an error installing modified sage library code. real0m12.882s user0m8.653s sys 0m1.840s ERROR installing SAGE real10m8.202s user7m25.064s sys 0m12.473s sage: An error occurred while installing sage-2.8.7 Please email sage-develhttp://groups.google.com/group/sage-devel explaining the problem and send the relevant part of of /home/wdj/sagefiles/sage-2.8.7/install.log. Describe your computer, operating system, etc. If you want to try to fix the problem, yourself *don't* just cd to /home/wdj/sagefiles/sage-2.8.7/spkg/build/sage-2.8.7 and type 'make'. Instead (using bash) type source local/bin/sage-env from the directory /home/wdj/sagefiles/sage-2.8.7 in order to set all environment variables correctly, then cd to /home/wdj/sagefiles/sage-2.8.7/spkg/build/sage-2.8.7 make[1]: *** [installed/sage-2.8.7] Error 1 make[1]: Leaving directory `/home/wdj/sagefiles/sage-2.8.7/spkg' real89m8.498s user48m0.352s sys 7m49.213s [EMAIL PROTECTED]:~/sagefiles/sage-2.8.7 ./sage -- | SAGE Version 2.8.7, Release Date: 2007-10-15 | | Type notebook() for the GUI, and license() for information.| -- --- type 'exceptions.ImportError' Traceback (most recent call last) /home/wdj/sagefiles/sage-2.8.7/local/bin/string in module() type 'exceptions.ImportError': No module named sage.misc.preparser_ipython WARNING: Failure executing code: 'import sage.misc.preparser_ipython; sage.misc.preparser_ipython.magma_colon_equals=True' --- type 'exceptions.ImportError' Traceback (most recent call last) /home/wdj/sagefiles/sage-2.8.7/local/bin/ipython console in module() type 'exceptions.ImportError': No module named sage.misc.misc ERROR: name 'sage_prompt' is not defined ERROR: name 'sage_prompt' is not defined [EMAIL PROTECTED]:~/sagefiles/sage-2.8.7 uname -a Linux tinah 2.6.16.13-4-default #1 Wed May 3 04:53:23 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux [EMAIL PROTECTED]:~/sagefiles/sage-2.8.7 Cheers, Michael sage: An error occurred while installing flint-0.2.p4 Please email sage-develhttp://groups.google.com/group/sage-devel explaining the problem and send the relevant part of of /home/wdj/sagefiles/sage-2.8.7/install.log. Describe your computer, operating system, etc. If you want to try to fix the problem, yourself *don't* just cd
[sage-devel] Re: sage-2.8.7
On Oct 16, 6:09 pm, David Joyner [EMAIL PROTECTED] wrote: On 10/16/07, mabshoff [EMAIL PROTECTED] wrote: Hi David, SNIP gcc blows up, there is little we can do about that. Please check if there are updates compilers available for SuSE 10.2. If not you can either install your own gcc from sources or install the optional gcc.spkg. In that case you need to modify $LD_LIBRARY_PATH to also include $SAGE_LOCAL/lib64 before $SAGE_LOCAL/lib on an AMD 64 box. I will have a look at sage/libs/pari/gen.c:19784 and see if there is anything suspicious in that area. Could you please open a ticket along the lines of paru/gen.c causes internal compiler error on OpenSuSE 10.2 and give us uname -a and gcc -v. Done.http://sagetrac.org/sage_trac/ticket/908 Some poking around reveals that this is a known regression with pari and gcc 4.1.0. See: http://gcc.gnu.org/ml/gcc-bugs/2006-04/msg00700.html http://lists.debian.org/debian-gcc/2006/05/msg00139.html This is on a work machine, so is not that easy to access, but I'll try to do some more testing. Well, could you just for fun rebuild pari? I think the compiler should blow up in that case, too, and I am curious why pari's build system doesn't catch it. Regarding a solution: I have discussed this with William before but I plan to offer a complete optional tool chain for compiling Sage that is integrated into the make system just for cases like this where the system's compiler screws us. The optional gcc spkg should work for you for now provided you fix $LD_LIBRARY_PATH in the way I mentioned earlier. If you do so first install the gcc spkg and then force a rebuild of pretty much every spkg with the exception of prereq I believe. The gcc compilers ends up in $SAGE_LOCAL, so there is no chance it could screw up your system or have side effects on other components. Cheers, Michael SNIP --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Another cython?
On Oct 16, 7:23 pm, John Voight [EMAIL PROTECTED] wrote: This must be a different cython, no? http://campbell.nu/oscar/cython/cython-doc.html Weird! Definitely, but it is something completely different. It also seems dead, last update was at the end of 2000. JV Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Secure Notebook Deployment
On Oct 17, 1:09 am, William Stein [EMAIL PROTECTED] wrote: On 10/16/07, Timothy Clemans [EMAIL PROTECTED] wrote: I don't think it is the main jails you would block since they have to receive and send data in order for the public to access them. Maybe you would block the pool of sage__ users from accessing the net using Iptables. (this might be helpful -- http://www.thescripts.com/forum/thread705507.html) Also maybe you could have a whitelist for the sloane database and the others. You're right; that's exactly what I want to do. I want to make it so the working pool sage* users can't use the network in any way. They are users in the chroot jail, so the question is -- how can I make it so a given user can't use the internet on a unix machine, assuming said user doesn't hack the machine and become a different user? I would suggest not to actually use unixy infrastructure to create the users. But that certainly involves a decent amount of coding to do your own user creation/permission management and so on. Trying to secure unix user accounts seems doomed in my opinion. Using IP tables is also pointless because you have http[s] access and can bring in everything you need that way. It is just a little bit more effort. And yes, I know, if only I would release a SageLite that was the sage notebook without the hard-to-build Sage math library, then all kinds of unix gurus would just solve all these problems for me (since then the notebook would be popular and independently interesting beyond Sage). I really want to do that. I agree. William Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: NTL build issues
On Oct 17, 7:45 pm, William Stein [EMAIL PROTECTED] wrote:
On 10/17/07, Mike Hansen [EMAIL PROTECTED] wrote:
I just upgraded to Ubuntu 7.10, and I have some issues building the NTL
wrapper.
Try moving your sage-main repository and trying again with a clean one, then
pull in the changes in your personal repository. I had the same problem, and
this solved it, I think.
Anyway, I'm using Ubuntu 7.10 myself, so there must have been some simple
fix like the above to get around the problem below.
William
g++ -o src/ntl_wrap.os -c -fPIC -I/opt/sage/local/include
-I/opt/sage/local/include/python2.5 -I/opt/sage/local/include/NTL
-Iinclude src/ntl_wrap.cpp
src/ntl_wrap.cpp: In function 'NTL::ZZ_pX ZZ_pE_to_ZZ_pX(ZZ_pE)':
src/ntl_wrap.cpp:794: error: 'x' has incomplete type
src/ntl_wrap.cpp:794: error: forward declaration of 'struct ZZ_pE'
ZZ_pE.h is included via ntl_wrap.h
src/ntl_wrap.cpp: At global scope:
src/ntl_wrap.cpp:912: error: expected constructor, destructor, or type
conversion before '*' token
src/ntl_wrap.cpp:923: error: expected constructor, destructor, or type
conversion before '*' token
src/ntl_wrap.cpp:1082: error: expected constructor, destructor, or
type conversion before '*' token
src/ntl_wrap.cpp:1087: error: expected constructor, destructor, or
type conversion before '*' token
src/ntl_wrap.cpp:1092: error: variable or field 'ZZ_pEContext_restore'
declared void
src/ntl_wrap.cpp:1092: error: 'ZZ_pEContext' was not declared in this scope
src/ntl_wrap.cpp:1092: error: 'ctx' was not declared in this scope
src/ntl_wrap.cpp:1093: error: expected ',' or ';' before '{' token
scons: *** [src/ntl_wrap.os] Error 1
ERROR: There was an error building c_lib.
Here is the ouput of g++ -v
[EMAIL PROTECTED]:/opt/sage$ g++ -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1
--enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug
--enable-mpfr --enable-checking=release x86_64-linux-gnu
Thread model: posix
gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
I've submitted ahttp://trac.sagemath.org/sage_trac/ticket/914
--Mike
If you look at the g++ command
g++ -o src/ntl_wrap.os -c -fPIC -I/opt/sage/local/include -I/opt/sage/
local/include/python2.5 -I/opt/sage/local/include/NTL -Iinclude src/
ntl_wrap.cpp
it includes -Iinclude where ntl_wrap.h should be. Maybe this is a
scons issues and we should include
-I$SAGE_ROOT/devel/sage/c_lib/include
On a side node: ntl_wrap.cpp includes a couple NTL headers directly.
Maybe those should move to ntl_wrap.h
Cheers,
Michael
--
William Stein
Associate Professor of Mathematics
University of Washingtonhttp://wstein.org
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Bug Day 4 reminder: October 20th, 2007, 10am PST till ...
Hello, this Saturday, October 20th 2007, starting at 10am pacific standard time will be Bug Day 4. It will go on officially for about 10 hours, but it is pretty much open ended ;). Everybody is welcome to join in #sage-devel and discuss, report and hopefully fix lots of bugs If you are interested in participating check out http://wiki.sagemath.org/bug4 and add yourself to the list of participants with optional information about the are you would like to work on. William might or might not post a tarball the night before that will be used as the basis for the bug day. But you should have a current build (2.8.7 at the moment) ready to go as basis anyway. Let us know if have any questions. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] [test by ...] byline in trac
Hello, recently we have started using [tested by ..] in trac. This seems to have lead to some misunderstanding, see http://www.sagetrac.org/sage_trac/ticket/910 [but I have fixed that now, see check out the log toward the end] The idea behind [tested by ...] is not that the original author of a patch tested it with -testall [that ought to be generally assumed I hope], but that it was tested with the combined other patches targeted for a particular milestone, in order to flush out side effects with the other patches. For 2.8.7 Carl Witty volunteered to do that, so that is why a lot of the patches for 2.8.7 carry the byline [tested by cwitty]. Hope that clears things up, I plan to spend at least some time during Bug Day 4 to get the text from my presentation about trac from SD5 ready for inclusion in the documentation. Does anybody have suggestions where this should go? At least some of it should end up in the wiki to have a page where I keep a log of what has been changed and updated. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] potential cause for #557: cython missing dictionary deallocation
Hello,
for every module Cython generates runtime support code that is place
at the end of the converted file. Each one of those has an
__Pyx_Import function that gets called from
PyMODINIT_FUNC init$MODULENAME(void)
static PyObject *__Pyx_Import(PyObject *name, PyObject *from_list) {
PyObject *__import__ = 0;
PyObject *empty_list = 0;
PyObject *module = 0;
PyObject *global_dict = 0;
PyObject *empty_dict = 0;
PyObject *list;
__import__ = PyObject_GetAttrString(__pyx_b, __import__);
if (!__import__)
goto bad;
if (from_list)
list = from_list;
else {
empty_list = PyList_New(0);
if (!empty_list)
goto bad;
list = empty_list;
}
global_dict = PyModule_GetDict(__pyx_m);
if (!global_dict)
goto bad;
empty_dict = PyDict_New();
if (!empty_dict)
goto bad;
module = PyObject_CallFunction(__import__, ,
name, global_dict, empty_dict, list);
bad:
Py_XDECREF(empty_list);
Py_XDECREF(__import__);
Py_XDECREF(empty_dict);
return module;
}
In that function PyMODINIT_FUNC init$MODULENAME(void) we also call
__Pyx_ImportType quite often:
static PyTypeObject *__Pyx_ImportType(char *module_name, char
*class_name,
long size)
{
PyObject *py_module_name = 0;
PyObject *py_class_name = 0;
PyObject *py_name_list = 0;
PyObject *py_module = 0;
PyObject *result = 0;
py_module_name = PyString_FromString(module_name);
if (!py_module_name)
goto bad;
py_class_name = PyString_FromString(class_name);
if (!py_class_name)
goto bad;
py_name_list = PyList_New(1);
if (!py_name_list)
goto bad;
Py_INCREF(py_class_name);
if (PyList_SetItem(py_name_list, 0, py_class_name) 0)
goto bad;
py_module = __Pyx_Import(py_module_name, py_name_list);
if (!py_module)
goto bad;
result = PyObject_GetAttr(py_module, py_class_name);
if (!result)
goto bad;
if (!PyType_Check(result)) {
PyErr_Format(PyExc_TypeError,
%s.%s is not a type object,
module_name, class_name);
goto bad;
}
if (((PyTypeObject *)result)-tp_basicsize != size) {
PyErr_Format(PyExc_ValueError,
%s.%s does not appear to be the correct type object,
module_name, class_name);
goto bad;
}
goto done;
bad:
Py_XDECREF(result);
result = 0;
done:
Py_XDECREF(py_module_name);
Py_XDECREF(py_class_name);
Py_XDECREF(py_name_list);
return (PyTypeObject *)result;
}
As one can see certain PyObject have refcounts greater 0 when
initialization is successful. But I cannot find a cleanup function
that would decrease the reference count upon exit. Consequently
python's garbage collector never frees those dictionaries, which in
most cases doesn't matter because we are exiting python anyway [some
people claim that one shouldn't care about still reachable memory,
because cleaning it up the nice way just slows down the termination of
a process because the system will reap the heap and stack
automatically]. But it pollutes the memcheck log, which is why I care
about this.
The usual way to call those functions for each module would be to
register an atexit function, see
http://docs.python.org/lib/module-atexit.html
So if anybody want to write am autogenerated cleanup function for
Cython and register it via atexit that person would be very welcome :)
Cheers,
Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: potential cause for #557: cython missing dictionary deallocation
On Oct 18, 6:16 am, Robert Bradshaw [EMAIL PROTECTED]
wrote:
Hi Robert,
No cleanup function is ever generated, but atexit sounds perfect.
Good that you seem to agree with my analysis. I ran across it be sheer
accident while looking at some linker issue that roed asked me about.
I'm the obvious person to implement this,
Pretty much 100% what I just claimed in IRC, but cwitty might look at
it during Bug Day 4.
I'll see if I can find the time to do so soon.
Let's hope so.
- Robert
Cheers,
Michael
On Oct 17, 2007, at 9:04 PM, mabshoff wrote:
Hello,
for every module Cython generates runtime support code that is place
at the end of the converted file. Each one of those has an
__Pyx_Import function that gets called from
PyMODINIT_FUNC init$MODULENAME(void)
static PyObject *__Pyx_Import(PyObject *name, PyObject *from_list) {
PyObject *__import__ = 0;
PyObject *empty_list = 0;
PyObject *module = 0;
PyObject *global_dict = 0;
PyObject *empty_dict = 0;
PyObject *list;
__import__ = PyObject_GetAttrString(__pyx_b, __import__);
if (!__import__)
goto bad;
if (from_list)
list = from_list;
else {
empty_list = PyList_New(0);
if (!empty_list)
goto bad;
list = empty_list;
}
global_dict = PyModule_GetDict(__pyx_m);
if (!global_dict)
goto bad;
empty_dict = PyDict_New();
if (!empty_dict)
goto bad;
module = PyObject_CallFunction(__import__, ,
name, global_dict, empty_dict, list);
bad:
Py_XDECREF(empty_list);
Py_XDECREF(__import__);
Py_XDECREF(empty_dict);
return module;
}
In that function PyMODINIT_FUNC init$MODULENAME(void) we also call
__Pyx_ImportType quite often:
static PyTypeObject *__Pyx_ImportType(char *module_name, char
*class_name,
long size)
{
PyObject *py_module_name = 0;
PyObject *py_class_name = 0;
PyObject *py_name_list = 0;
PyObject *py_module = 0;
PyObject *result = 0;
py_module_name = PyString_FromString(module_name);
if (!py_module_name)
goto bad;
py_class_name = PyString_FromString(class_name);
if (!py_class_name)
goto bad;
py_name_list = PyList_New(1);
if (!py_name_list)
goto bad;
Py_INCREF(py_class_name);
if (PyList_SetItem(py_name_list, 0, py_class_name) 0)
goto bad;
py_module = __Pyx_Import(py_module_name, py_name_list);
if (!py_module)
goto bad;
result = PyObject_GetAttr(py_module, py_class_name);
if (!result)
goto bad;
if (!PyType_Check(result)) {
PyErr_Format(PyExc_TypeError,
%s.%s is not a type object,
module_name, class_name);
goto bad;
}
if (((PyTypeObject *)result)-tp_basicsize != size) {
PyErr_Format(PyExc_ValueError,
%s.%s does not appear to be the correct type object,
module_name, class_name);
goto bad;
}
goto done;
bad:
Py_XDECREF(result);
result = 0;
done:
Py_XDECREF(py_module_name);
Py_XDECREF(py_class_name);
Py_XDECREF(py_name_list);
return (PyTypeObject *)result;
}
As one can see certain PyObject have refcounts greater 0 when
initialization is successful. But I cannot find a cleanup function
that would decrease the reference count upon exit. Consequently
python's garbage collector never frees those dictionaries, which in
most cases doesn't matter because we are exiting python anyway [some
people claim that one shouldn't care about still reachable memory,
because cleaning it up the nice way just slows down the termination of
a process because the system will reap the heap and stack
automatically]. But it pollutes the memcheck log, which is why I care
about this.
The usual way to call those functions for each module would be to
register an atexit function, see
http://docs.python.org/lib/module-atexit.html
So if anybody want to write am autogenerated cleanup function for
Cython and register it via atexit that person would be very welcome :)
Cheers,
Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: sage-2.8.8 release
On Oct 19, 10:34 pm, William Stein [EMAIL PROTECTED] wrote: Hi, I'm planning to release sage-2.8.8 sometime tonight. I'll start working on it at about 4pm my time. I'll be on #sage-devel irc, in case you want to help out. http://trac.sagemath.org/sage_trac/milestone/sage-2.8.8 You can already help by looking at patches posted above, trying them out, and posting any comments about them (are they great, bad, need work, etc.) I will carefully check all posted comments about trac tickets, and any comments on other people's patches will be greatly appreciated (they do help a lot). mhansen and I did go through the open tickets against 2.9 and we ended up assigning some of them against 2.8.8 because we assume/believe that the issue has been closed. Check out the log for #sage-devel, otherwise I will be in IRC later if you have any questions. -- William Cheers, Michael -- William Stein Associate Professor of Mathematics University of Washingtonhttp://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: zombies attack sage.math!
On Oct 19, 5:13 pm, [EMAIL PROTECTED] wrote: Ok... this isn't an early haloween scare. Hi boothby, There are two lisp.run processes taking up 100% processor, attached to the users jen and jacobml. Those are the only processes under those users, so I'm thinking they shouldn't be there. Bug in the cleaner? Nope those are not zombies, the only zombie on sage.math at the moment is a defunct sshd child. The processes you mention are not running under a notebook as far as I can tell because I thought we had dedicated notebook users. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Rules for closing tickets in trac
Hello, since this has come up repeatedly I would like to clarify: Do not close any tickets in trac unless you have been explicitly told to do so by either malb, was, cwitty or mabshoff. This is to avoid having issues slip through the cracks. Once a ticket is closed and off the top of the time line chances are nobody will ever look at it again unless you stumble across it by accident. Just like the [with patch] byline we should come up with something to indicate that a ticket should be looked at like [should be closed], [is invalid] or [is won'tfix]. In addition you should give a reason why you think the action you requested should be taken (the more precise the better) and retag the ticket against the current target, i.e. 2.8.9 at the moment. If you leave it in 2.9 for now it is unlikely to be found and looked at because there are another 140 tickets open against that one. William can configure trac so that closing tickets is limited to a few, but so far he has not done so. But as we have to deal with an ever increasing number of tickets we need to follow the process in order to avoid losing issues and also keep the confusion and the work to deal with tickets to a minimum. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Rules for closing tickets in trac
On Oct 22, 10:40 am, Martin Albrecht [EMAIL PROTECTED] wrote: On Monday 22 October 2007, mabshoff wrote: Hello, Hello, since this has come up repeatedly I would like to clarify: Do not close any tickets in trac unless you have been explicitly told to do so by either malb, was, cwitty or mabshoff. This is to avoid having issues slip through the cracks. Once a ticket is closed and off the top of the time line chances are nobody will ever look at it again unless you stumble across it by accident. Just like the [with patch] byline we should come up with something to indicate that a ticket should be looked at like [should be closed], [is invalid] or [is won'tfix]. In addition you should give a reason why you think the action you requested should be taken (the more precise the better) and retag the ticket against the current target, i.e. 2.8.9 at the moment. If you leave it in 2.9 for now it is unlikely to be found and looked at because there are another 140 tickets open against that one. William can configure trac so that closing tickets is limited to a few, but so far he has not done so. But as we have to deal with an ever increasing number of tickets we need to follow the process in order to avoid losing issues and also keep the confusion and the work to deal with tickets to a minimum. I got a clarification for the clarification: Michael mentioned me (malb) and Carl (cwitty) because William (was) asked us to prepare the next release. So for 2.8.9 the three of us are the release managers and consequently we are supposed to close tickets. and a question: Take ticket 729 as an example (http://trac.sagemath.org/sage_trac/ticket/729): It was closed by Robert (rml) because the bugfix/feature request was invalid. Michael (mabshoff) reopened it due to the rule state above. But there is nothing for the release manager to do and I feel perfectly comfortable with rml closing invalid tickets for the Graph subsystem. So I think in those cases it makes perfectly sense to just close tickets. Well, I see it the same way: rml is responsible for the graph subsystem, so he is the person with the expertise to determine that the ticket is invalid. But he closed that ticket against 2.9, while it is customary to close invalid tickets against the sage-duplicate/ invalid milestone. The same applies for #731. It is not so much the marking the ticket invalid, it just ended up against the wrong milestone. What caused me to actually raise the issue is #656: That one is clearly not a duplicate. #968 is an enhancement relative to #656. During Bug Day 4 William also told rlm not to close tickets until the issue had been officially resolved. IMHO this rule could be relaxed if we had the e-mail subsystem working (I know it is being worked on). Because in that case, the submitter and the owner of a ticket get an e-mail and can complain if it isn't actually fixed. Yep, that has been requested for quite some time. William has enabled smtp support for trac IIRC, but it doesn't work (yet). Martin Cheers, Michael -- name: Martin Albrecht _pgp:http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _www:http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Rules for closing tickets in trac
On Oct 22, 11:13 am, Martin Albrecht [EMAIL PROTECTED] wrote: Take ticket 729 as an example (http://trac.sagemath.org/sage_trac/ticket/729):It was closed by Robert (rml) because the bugfix/feature request was invalid. Michael (mabshoff) reopened it due to the rule state above. But there is nothing for the release manager to do and I feel perfectly comfortable with rml closing invalid tickets for the Graph subsystem. So I think in those cases it makes perfectly sense to just close tickets. Well, I see it the same way: rml is responsible for the graph subsystem, so he is the person with the expertise to determine that the ticket is invalid. But he closed that ticket against 2.9, while it is customary to close invalid tickets against the sage-duplicate/ invalid milestone. The same applies for #731. It is not so much the marking the ticket invalid, it just ended up against the wrong milestone. Why do we need to change the milestone for invalid tickets? The idea is to collect all invalid tickets in one milestone so that they can be found by accessing one milestone. You can pull all of them via custom query, but that is not as transparent. I only recently started doing that, so there are invalid tickets attached to older milestones, but I had a discussion with William about that in IRC before creating that special milestone. The discussion happened about 3 weeks ago. Martin Cheers, Michael -- name: Martin Albrecht _pgp:http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _www:http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Rules for closing tickets in trac
On Oct 22, 5:17 pm, Robert Miller [EMAIL PROTECTED] wrote: What caused me to actually raise the issue is #656: That one is clearly not a duplicate. #968 is an enhancement relative to #656. During Bug Day 4 William also told rlm not to close tickets until the issue had been officially resolved. Hello Robert, I'm assuming you're talking about 956. You are right, sorry for the type. The reason I closed 956 and deferred to 968 was because the patches are both to the same area of code, and if you apply the patch in #956, then the ones in 968, funny stuff might happen. The recommended patches in #968 will cover both, so... Well, #968 has two patches, one of which is idential to the one attached to #656 except that it is rebased against the tree after your fixes went in. I would have suggested to attach the updated version for #656 to that ticket and add a comment not to apply the first, but the second version due to the rewrite attached to #968. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: 2.8.8.1 on Ubuntu
On Oct 22, 6:52 pm, John Voight [EMAIL PROTECTED] wrote: Hi all, I did a fresh install of Ubuntu, downloaded 2.8.7, then did a sage - upgrade, and got the following error: [EMAIL PROTECTED]:/home/kostadm/sage# ./sage -upgrade [...] GCC Version gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c+ +,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with- system-zlib --libexecdir=/usr/lib --without-included-gettext --enable- threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/ 4.1.3 --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486- linux-gnu Thread model: posix gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) make[1]: Entering directory `/home/kostadm/sage/spkg/build/ singular-3-0-3-2-20071020/src' make[1]: *** No rule to make target `distclean'. Stop. make[1]: Leaving directory `/home/kostadm/sage/spkg/build/ singular-3-0-3-2-20071020/src' rm: cannot remove `/home/kostadm/sage/local/bin/Singular*': No such file or directory creating cache ./config.cache checking uname for singular... ix86-Linux checking for gcc... gcc checking whether the C compiler (gcc -fPIC -O3 ) works... no configure: error: installation or configuration problem: C compiler cannot create executables. Unable to configure Singular. Command exited with non-zero status 1 0.41user 0.31system 0:01.31elapsed 55%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+40811minor)pagefaults 0swaps sage: An error occurred while installing singular-3-0-3-2-20071020 Please email sage-develhttp://groups.google.com/group/sage-devel explaining the problem and send the relevant part of of /home/kostadm/sage/install.log. Describe your computer, operating system, etc. If you want to try to fix the problem, yourself *don't* just cd to /home/kostadm/sage/spkg/build/singular-3-0-3-2-20071020 and type 'make'. Instead (using bash) type source local/bin/sage-env from the directory /home/kostadm/sage in order to set all environment variables correctly, then cd to /home/kostadm/sage/spkg/build/singular-3-0-3-2-20071020 make: *** [installed/singular-3-0-3-2-20071020] Error 1 Command exited with non-zero status 2 11.77user 1.40system 0:30.39elapsed 43%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+47241minor)pagefaults 0swaps Hello John, I'm sure I must need to do something trivial, but what is that trivial thing? according to the configure script you have a gcc, but it fails to compile with -fPIC -O3 checking for gcc... gcc checking whether the C compiler (gcc -fPIC -O3 ) works... no configure: error: installation or configuration problem: C compiler cannot create executables. Unable to configure Singular. Command exited with non-zero status 1 Could you try compiling hello world or some or simple C program with the same options and see if anything pops up? The autoconf run of Singular also leaves a log around. There you should find the exact failure why that config test failed. Thanks, JV Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: problem with showing plots from command line
On Oct 23, 8:20 am, Jonathan Bober [EMAIL PROTECTED] wrote: Hi folks. Hello Jonathan, I tried to send the following email a few hours ago (but I put the email address in wrong) and I don't feel like rewriting it all. So I should add to it now that I have upgraded sage (so I am running 2.8.8.1) and the error still occurs. Perhaps I should open a ticket for this, but perhaps I should also wait to see it anyone else can duplicate this problem. - Hi all. I apologize for not upgrading to the latest version of sage before writing this email, but I didn't see any tickets about this on the since 2.8.7.2, so perhaps no one else has had this problem. (And I am upgrading now, but if I don't send this email now, I might forget about it for a few days). Anyway, the following takes place on a Intel Core Duo (not Core 2, so just 32 bits) newly upgraded to Ubuntu 7.10, and running sage 2.8.7.2. Briefly, plot().show() isn't working for me. After looking into the problem a little bit, I modified the code for show() so that it would print out the command line that it was using, along with any errors. I get the following: sage: f(x) = x*exp(-4*x) sage: P = f.plot() sage: P.show() xdg-open /home/bober/.sage//temp/bober/11314//tmp_0.png sage: eog: symbol lookup error: /usr/lib/libxml2.so.2: undefined symbol: gzopen64 Could you give us the output from echo 'LD_LIBRARY_PATH' and 'ldd xdg- open' with and without sourcing sage-env. If you add an 'echo LD_LIBRARY_PATH' right before xdg-open is called in P.show() From the name of the symbol I would guess that it is a libz incompability. There was a patch to the launch code for firefox/ iceweasel that malb made because of a similar issue. Maybe we need to reset LD_LIBRARY_PATH to the old value before we modify it in sage-env in case we launch external helper applications. So there is some sort of library problem. But if I execute the same command from a plain shell: [EMAIL PROTECTED]:~$ xdg-open /home/bober/.sage//temp/bober/11314//tmp_0.png eog opens the file just fine. So it seems that sage is somehow screwing up library search paths, or perhaps when eog is run from within sage it is trying to use some libraries that sage provides and some libraries that Ubuntu provides, and those libraries don't play nice together. Or something like that is going on. plot().show() also does not work anymore for me when running sage 2.8.2, and it certainly used to before I upgraded Ubuntu, so it is probably safe to assume that it is getting the same error, and that this error was caused by the upgrade. (I haven't actually taken the time to verify that eog gives the same library error when run from 2.8.2, however.) This is probably beyond my ability to debug any further without spending many hours, so hopefully someone knows how to fix this easily, or can at least point me in the right direction. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Unhandled SIGSEGV: Ticket #973
On Oct 23, 1:23 pm, Jaap Spies [EMAIL PROTECTED] wrote: Last year after less than two days I could finish a calculation and write to William: Original Message Subject: dance(10) Date: Thu, 09 Mar 2006 00:10:19 +0100 From: Jaap Spies [EMAIL PROTECTED] To: William Stein [EMAIL PROTECTED] William, Some time ago, dance(10) finished: sage: time dance(10) [1, 90, 3405, 71040, 901152, 7225344, 36862960, 117340800, 221170456, 220658800, 87396728] h^10 - 35*h^9 + 675*h^8 - 8610*h^7 + 78435*h^6 - 523467*h^5 + 2562525*h^4 - 9008160*h^3 + 21623220*h^2 - 31840760*h + 21750840 CPU times: user 141822.70 s, sys: 18387.03 s, total: 160209.74 s Wall time: 165997.13 Jaap To day I got with sage-2.8.8.1: sage: time dance(10) Unhandled SIGSEGV: A segmentation fault occured in SAGE. This probably occured because a *compiled* component of SAGE has a bug in it (typically accessing invalid memory) or is not properly wrapped with _sig_on, _sig_off. You might want to run SAGE under gdb with 'sage -gdb' to debug this. SAGE will now terminate (sorry). With sage -gdb: sage: time dance(9) h^9 - 27*h^8 + 414*h^7 - 4158*h^6 + 29421*h^5 - 148743*h^4 + 530796*h^3 - 1276992*h^2 + 1866384*h - 1255608 CPU times: user 1786.82 s, sys: 23.05 s, total: 1809.87 s Wall time: 1831.52 sage: time dance(10) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208523072 (LWP 30162)] 0x0064d473 in strlen () from /lib/libc.so.6 (gdb) The program (see below) uses methods from sage.matrix.matrix2.pyx Jaap Hello Jaap, I am looking into this, but I am pressed for time until Thursday, so don't expect any solution before that. It will take forever to valgrind this anyway. If you still have that gdb session it would be great to get a backtrace. I did run the code with smaller parameters, i.e. dance(4) and dance(5), under valgrind and nothing popped up there. So I am suspecting that the code might smash the stack with large parameters, but that ought to be taken with a grain of salt until I get a backtrace and some valgrind output Cheers, Michael ## # Copyright (C) 2006 Jaap Spies, [EMAIL PROTECTED] # # Distributed under the terms of the GNU General Public License (GPL): # # http://www.gnu.org/licenses/ ## Usage from sage sage: attach 'dancing.sage' sage: dance(4) h^4 - 2*h^3 + 9*h^2 - 8*h + 6 # use variable 'h' in the polynomial ring over the rationals h = QQ['h'].gen() def dance(m): Generates the polynomial solutions of the Dancing School Problem Based on a modification of theorem 7.2.1 from Brualdi and Ryser, Combinatorial Matrix Theory. See NAW 5/7 nr. 4 december 2006 p. 285 INPUT: integer m OUTPUT: polynomial in 'h' EXAMPLE: sage: dance(4) h^4 - 2*h^3 + 9*h^2 - 8*h + 6 AUTHOR: Jaap Spies (2006) n = 2*m-2 M = MatrixSpace(ZZ, m, n) A = M([0 for i in range(m*n)]) for i in range(m): for j in range(n): if i j or j i + n - m: A[i,j] = 1 rv = A.rook_vector() # print rv s = sum([(-1)^k*rv[k]*falling_factorial(m+h-k, m-k) for k in range(m+1)]) print s --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Unhandled SIGSEGV: Ticket #973
On Oct 24, 12:31 pm, Jaap Spies [EMAIL PROTECTED] wrote: Michael, Hello Jaap, You wrote: dance(10) computes fine on sage.math (in about 6 hours under gdb), I am running dance(11) to see if it finishes [I guess you would like the result ;)]. Yes, sure! Ok, should it finish I will send you the output. So, any chance you are running the computation on a 32 bit box and/or run out of memory/have highly fragmented memory after a long uptime? There is a long uptime, but I saw in the system console a steady line on 80% memory usage. Ok. I have to wait for the valgrind run to finish (which will take a long, long time), to say something definite, but I will look into it some more. Below the output from bt Thanks. Thanks! Jaap sage: time dance(10) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208297792 (LWP 3914)] 0x0a6c2a64 in ?? () (gdb) bt #0 0x0a6c2a64 in ?? () #1 0x08087aa2 in PyObject_RichCompare (v=0x8f94f44, w=0x8f94f44, op=2) at Objects/object.c:914 #2 0x080c3862 in PyEval_EvalFrameEx (f=0xa7bb864, throwflag=0) at Python/ceval.c:3980 #3 0x0810b4ed in gen_send_ex (gen=0xa70a3ec, arg=0x16, exc=0) at Objects/genobject.c:82 #4 0x080c00cd in PyEval_EvalFrameEx (f=0xa7bd5e4, throwflag=0) at Python/ceval.c:2164 #5 0x0810b4ed in gen_send_ex (gen=0xa70a32c, arg=0x16, exc=0) at Objects/genobject.c:82 #6 0x080c00cd in PyEval_EvalFrameEx (f=0xa7bd15c, throwflag=0) at Python/ceval.c:2164 #7 0x0810b4ed in gen_send_ex (gen=0xa70a72c, arg=0x16, exc=0) at Objects/genobject.c:82 #8 0x080c00cd in PyEval_EvalFrameEx (f=0xa7bc4fc, throwflag=0) at Python/ceval.c:2164 #9 0x0810b4ed in gen_send_ex (gen=0xa70a70c, arg=0x16, exc=0) at Objects/genobject.c:82 #10 0x080c00cd in PyEval_EvalFrameEx (f=0xa7bea2c, throwflag=0) at Python/ceval.c:2164 #11 0x0810b4ed in gen_send_ex (gen=0xa70a6ec, arg=0x16, exc=0) at Objects/genobject.c:82 #12 0x080c00cd in PyEval_EvalFrameEx (f=0xa7be134, throwflag=0) at Python/ceval.c:2164 #13 0x0810b4ed in gen_send_ex (gen=0xa70a68c, arg=0x16, exc=0) at Objects/genobject.c:82 #14 0x080c00cd in PyEval_EvalFrameEx (f=0xa7bf77c, throwflag=0) at Python/ceval.c:2164 #15 0x0810b4ed in gen_send_ex (gen=0xa70a6cc, arg=0x16, exc=0) at Objects/genobject.c:82 #16 0x080c00cd in PyEval_EvalFrameEx (f=0xa7be434, throwflag=0) at Python/ceval.c:2164 #17 0x0810b4ed in gen_send_ex (gen=0xa70aa2c, arg=0x16, exc=0) at Objects/genobject.c:82 #18 0x080c00cd in PyEval_EvalFrameEx (f=0xa7bb9dc, throwflag=0) at Python/ceval.c:2164 #19 0x0810b4ed in gen_send_ex (gen=0xa70a66c, arg=0x16, exc=0) at Objects/genobject.c:82 #20 0x0805a213 in PyIter_Next (iter=0xa70a66c) at Objects/abstract.c:2375 #21 0x0121c5bd in __pyx_f_py_7matrix2_6Matrix_permanent (__pyx_v_self=0x9c37194, unused=0x0) at sage/matrix/matrix2.c:1633 The above corresponds to the following lines in matrix2.pyx:279-281: tmp = [] for cols in lst: tmp.append(self.prod_of_row_sums(cols)) The crash itself happens when the tmp.append() fails. That indicates a problem with python's memory management and not an issue in the Sage code. I would expect python to throw some kind of allocation error, but since python uses pymalloc it usually asks for a large amount of memory to parcel out smaller chunks for the requests it receives. That could explain why despite having consumed roughly 80% of memory available the allocation fails. The other 20% might also be taken up to a large extent by the kernel and user space, so that makes a situation where you encounter a no more memory situation very likely. The matrix code in Sage does throw a RuntimeError when it fails to allocate memory, so I think it is off the hook for now. Because you run at about 80% memory consumption and have a large uptime I would suggest to do a reboot and see if the computation still fails; hopefully your heap fragmentation problem is gone due to the reboot and the computation will succeed. Depending on the version of Sage you last tried this with the memory footprint of Sage might have grown in relative terms so that the computation no longer succeeds with the amount of RAM you have, so another possibility would be to increase the amount of swap you have in that box. Adding more physical RAM will probably makes the problem go away, too. If anything pops up from the still running debug sessions I will let you know. Cheers, Michael #22 0x0805a277 in PyObject_Call (func=0x92c1a54, arg=0xb7f6d02c, kw=0x0) at Objects/abstract.c:1860 ---Type return to continue, or q return to quit--- #23 0x080be7cc in PyEval_CallObjectWithKeywords (func=0xa71282c, arg=0xb7f6d02c, kw=0x0) at Python/ceval.c:3433 #24 0x0805a490 in PyObject_CallObject (o=0xa71282c, a=0x0) at Objects/abstract.c:1851 #25 0x0121b491 in __pyx_f_py_7matrix2_6Matrix_permanental_minor (__pyx_v_self=0x9c37fa4, __pyx_arg_k=0x8f94ee4) at
[sage-devel] Re: Unhandled SIGSEGV: Ticket #973
On Oct 24, 6:52 pm, Jaap Spies [EMAIL PROTECTED] wrote:
mabshoff wrote:
On Oct 24, 6:27 pm, William Stein [EMAIL PROTECTED] wrote:
On 10/24/07, Jaap Spies [EMAIL PROTECTED] wrote:
I am on that, I got a 32 bit build of 2.8.9.alpha0.
By the way, could you remind me where dance is defined?
sage: search_src('dance')
[nothing]
sage:
It is not in matrix2.pyx, It is on the bottom of my first message and heer
below.
It uses some functions/methods present in matrix2.pyx:
rook_vector, permanental_minor, prod_of_row_sums, permanent.
Yep, you are obviously right, sorry for the confusion.
increase the amount of swap you have in that box. Adding more physical
RAM will probably makes the problem go away, too.
I rebooted with no succes. Same error using 50-60% of 1 GB memory.
Swap space is 5 GB.
Jaap
Ok, I will investigate on a 32 bit box then. Could you give us
distribution/gcc and so on please? It might be related to specific
compilers.
Linux paix 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 23:10:59 EDT 2007 i686 i686 i386
GNU/Linux
gcc (GCC) 4.1.2 20070925 (Red Hat 4.1.2-27)
Great, I have
Linux localhost.localdomain 2.6.22.1-41.fc7 #1 SMP Fri Jul 27 17:26:33
EDT 2007 i686 i686 i386 GNU/Linux
gcc version 4.1.2 20070626 (Red Hat 4.1.2-13)
so I will apply the latest FC7 updates.
Jaap
Cheers,
Michael
---
##
# Copyright (C) 2006 Jaap Spies, [EMAIL PROTECTED]
#
# Distributed under the terms of the GNU General Public License (GPL):
#
# http://www.gnu.org/licenses/
##
Usage from sage
sage: attach 'dancing.sage'
sage: dance(4)
h^4 - 2*h^3 + 9*h^2 - 8*h + 6
# use variable 'h' in the polynomial ring over the rationals
h = QQ['h'].gen()
def dance(m):
Generates the polynomial solutions of the Dancing School Problem
Based on a modification of theorem 7.2.1 from Brualdi and Ryser,
Combinatorial Matrix Theory.
See NAW 5/7 nr. 4 december 2006 p. 285
INPUT: integer m
OUTPUT: polynomial in 'h'
EXAMPLE:
sage: dance(4)
h^4 - 2*h^3 + 9*h^2 - 8*h + 6
AUTHOR: Jaap Spies (2006)
n = 2*m-2
M = MatrixSpace(ZZ, m, n)
A = M([0 for i in range(m*n)])
for i in range(m):
for j in range(n):
if i j or j i + n - m:
A[i,j] = 1
rv = A.rook_vector()
# print rv
s = sum([(-1)^k*rv[k]*falling_factorial(m+h-k, m-k) for k in
range(m+1)])
print s
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: edit_module patch updated
On Oct 24, 6:50 pm, William Stein [EMAIL PROTECTED] wrote:
On 10/24/07, Nils Bruin [EMAIL PROTECTED] wrote:
I understand that the bg= hack is a quick way of getting the
configurability you want, but frankly, I would find it hard to explain
the existence of that option independent of the very particular usage
scenario you describe.
To you, since you don't use it, it is a very particular usage scenario.
To me it is the normal very common (for me at least) usage scenario.
Jf we want sage to pop up the appropriate editor, the user should
not be required to give an extra option like that.
I certainly don't propose that they have to give the extra option.
It is optional. There should still be the default proposal you implemented.
edit(.., bg=None)
does the default
edit(..., bg=True)
does the background = True mode,
edit(..., bg = False)
does the background = False mode.
In the model I
proposed (which clearly is inconvenient to you, so we need to see how
to wrap this), the solution would be to put into your init.sage
(basically following a suggestion Justin made):
if os.environ.haskey('DISPLAY'):
sage.misc.edit_module.set_edit_template('emacs +${line} ${file}
')
else:
sage.misc.edit_module.set_edit_template('emacs +${line} ${file}')
So, if you're sure that this does for emacs what you want, we could
I'm sure that does *not* do what I want. When I login to my laptop
under Linux the DISPLAY environment variable is not even set, yet
emacs pops up in a window.When I login remotely to another machine
(or my laptop, from OS X), it can easily be that DISPLAY is not set.
I also have a similar issue with my office desktop, which I use both
remotely and when I'm actually in my office at the console.
wrap this into the set_editor command instead of the bg= option.
Then the appropriate magic gets executed if either 'EDITOR=emacs' or
if set_editor('emacs'), and currently even if edit(..,
editor='emacs').
Guessing a user's configuration and preferences will stay hackish
guesswork. I'm happy to put some guesses into set_editor. Ultimately,
however, people should just put personal configuration stuff into
init.sage. (either that or every user patches sage.misc.edit_module
^
That doesn't work for me, since in my usage the init.sage is the same
in both cases, and I often switch between both usage scenarios.
Another solution would be two possible editor templates: emacs-fg
and emacs-bg.
I just want to type
sage: edit(name)
and have it work. If it happens to be that a window pops up, and will
say to myself -- gee, I need this to be backgrounded so I can type
command still, and I'll instead do
sage; edit(name, bg=True).
Anyway, I can't see the problem with having that option, and your only
argument against it is that it is difficult to explain in the documentation.
-- William
On Oct 23, 11:03 pm, William Stein [EMAIL PROTECTED] wrote:
On 10/22/07, Nils Bruin [EMAIL PROTECTED] wrote:
See:
http://sagetrac.org/sage_trac/ticket/768
I have updated the attached patch to be clean against 2.8.8.1. When I
checked the edit() command in sage 2.8.8.1, I realized it was really
broken -- It doesn't work if EDITOR is unset in the environment. The
patch attached to the trac ticket is supposed to fix that.
I'm generally happy with this patch, though I don't agree with removing
the bg option. Perhaps you're removing that functionality because
your particular workflow is more rigid than mine. For example, I use
emacs quite a lot, both in a console (especially when I login to other
machines), but also as a popup separate application. When I use emacs
in console mode, putting the editor in the background is very frusting,
and doesn't work at all. When I use emacs as a separate popup
application, it
is very very frustrating if the console session freezes, since often the
reason
I'm popping up the editor is to create some examples in the console and
paste them into the docstring of a function. In both cases the command
name is exactly the same emacs.
So please change the patch back to have the bg option.
This is a lot like black on white versus white on black. Most people
exclusively
use one or the other mode, and it's impossible to know which from the
application's point of view.So applications have to support both and
make
it easy to switch between generating colors for each. I often switch
between
using emacs and vi, both in window and console mode, and between black
on white and white on black, depending on my mood, eye strain, computing
I'm logged into, etc. So it needs to be easy to support changing modes.
The bg= option to edit is 3 lines of code and does just that; it allows
one to
very easily override automatic defaults on a per-use basis.
-- William
Hello
[sage-devel] Re: potential cause for #557: cython missing dictionary deallocation
On Oct 24, 9:01 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: Robert, I've implemented a function and hook to do this in the new version of Cython, Cool. but I'm not sure how well it will work in practice on the entire SAGE library. It will decref local variable and all, but then if anything (e.g. other destructors) ever try and use any of the module again it will crash with high probability (because the expected variables will no longer be set). Well, if it crashes upon exit I would consider that a bug and we can hopefully fix them. If you have an inofficial spkg I would really like to take it for a spin. - Robert Cheers, Michael SNIP --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Notices this month
On Oct 24, 8:44 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: Hello, I've noticed sometimes the public sage notebook is really, really slow, for instance when someone is running a lot of dsage or valgrind jobs. since you mention valgrind I would like to remark that I usually limit myself to one long term and one short term job on sage.math, so it wasn't me :) Perhaps it would be good to consider an intensive job blackout period for moments of potential big publicity so that the public notebook can provide a good impression. That is certainly a valid point. - Robert Cheers, Michael On Oct 24, 2007, at 11:20 AM, Timothy Clemans wrote: It would be interesting to see the number of visitors to sagemath.org who come from that pdf on ams. Seehttp://www.apacheweek.com/features/logfilesand search for referrer On 10/24/07, cwitty [EMAIL PROTECTED] wrote: On Oct 23, 9:52 pm, William Stein [EMAIL PROTECTED] wrote: Hi, Our opinion piece Open Source Mathematical Software appeared in the Notices of the AMS this month: http://www.ams.org/notices/200710/ The link to the article is on the upper-right corner of the page. Thanks to everybody who helped with the article! This article is featured as a news picks item on Groklaw (http:// www.groklaw.net) right now. Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] sloccount of sage-2.8.9.rc1
Hello, I ran sloccount on the latest rc1 and here are the results: SLOCDirectory SLOC-by-Language (Sorted) 687172 python-2.5.1.p7 ansic=354375,python=315376,asm=6567,sh=3895,lisp=3683, perl=2520,objc=756 422885 scipy-20070817 cpp=120609,ansic=112030,python=10,fortran=80892, objc=424,sh=42 366515 lapack-20070723 fortran=366387,pascal=116,sh=12 289667 maxima-5.13.0 lisp=246582,fortran=14666,perl=14325,tcl=10222,sh=3386, ansic=471,python=8,awk=7 243569 matplotlib-0.90.0.p4 python=143836,cpp=86548,ansic=13166,sh=19 217702 singular-3-0-3-2-20071020 cpp=178602,ansic=22558,perl=5570,lisp=4063, sh=3454,yacc=1702,lex=1398,csh=189,python=163,sed=3 180146 gsl-1.9 ansic=177097,sh=3038,python=11 148822 gmp-4.2.1.p10 ansic=71142,asm=51587,cpp=13109,sh=9189,perl=3247, yacc=226,lisp=203,lex=95,fortran=24 146962 sage-2.8.9.rc1 python=137419,cpp=7261,ansic=2175,sh=107 138581 clisp-2.41.p8 lisp=74381,ansic=40568,sh=11561,fortran=6692,cpp=2660, objc=2481,perl=164,sed=55,python=19 136483 twisted-2.5.0.p8 python=134313,ansic=2132,sh=38 126094 numpy-20070816 ansic=74659,python=50778,fortran=248,cpp=197,sh=115, f90=97 122683 gap-4.4.10 ansic=116320,sh=3008,lisp=1804,perl=1545,awk=6 120578 pari-2.3.2.p3 ansic=114629,lisp=5173,sh=603,perl=153,python=20 99638 gnutls-1.6.3ansic=95992,sh=1956,cpp=1046,perl=628,sed=16 89269 freetype-2.1.10 ansic=75080,sh=8160,python=6029 85877 sqlite-3.3.17.p1 ansic=62811,tcl=19241,sh=2839,yacc=806,awk=180 78638 symmetrica-0.3.3 ansic=78621,sh=17 78227 ntl-5.4.1.p6ansic=78132,sh=95 71706 sympy-0.5.3 python=71703,sh=3 69131 cvxopt-0.8.2.p3 ansic=64322,python=4019,fortran=777,sh=11,awk=2 68472 linbox-20070915 cpp=67991,sh=475,sed=4,perl=2 56976 mpfr-2.3.0 ansic=51542,sh=5434 48014 moin-1.5.7 python=35148,java=10704,perl=1424,php=642,sh=96 43165 doc-2.8.9.rc1 perl=25684,python=14518,lisp=2427,sh=473,ansic=61, sed=2 42891 libpng-1.2.18 ansic=34404,sh=8482,cpp=5 42128 libgcrypt-1.2.4 ansic=29468,sh=8048,asm=4612 41945 mercurial-0.9.5 python=27386,sh=8300,tcl=3484,lisp=1411,ansic=1364 40831 gd-2.0.33.p5ansic=32741,sh=7625,perl=420,tcl=45 36865 zodb3-3.7.0 python=29676,ansic=7183,sh=6 35272 ecm-6.1.3 ansic=17313,asm=13213,sh=4085,python=661 33854 f2c-20070816ansic=33833,sh=21 32399 mwrank-20070913 cpp=30167,sh=2232 31381 flint-0.2.p4ansic=29483,cpp=1540,python=246,sh=112 30135 readline-5.2ansic=22060,perl=4105,sh=3970 24248 cython-0.9.6.7.a python=21236,ansic=3012 23341 quaddouble-2.2.p7 cpp=8526,sh=8387,fortran=6428 21954 networkx-0.35.1 python=21950,sh=4 21542 scons-0.97 python=21536,sh=6 18624 givaro-3.2.6.p1 cpp=10211,sh=8409,sed=4 18272 ipython-0.8.1.p1 python=17982,lisp=262,sh=28 16862 zlib-1.2.3.p2 ansic=8912,asm=3281,ada=1681,pascal=1089,cpp=1001, cs=879,sh=19 16070 blas-20070724 fortran=16057,sh=13 13989 palp-1.1ansic=13978,sh=11 13519 tachyon-0.98beta.p2 ansic=13445,sh=41,perl=33 12660 gfan-0.2.2.p1 cpp=12637,sh=23 11948 libgpg_error-1.5 sh=8126,ansic=3254,awk=428,lisp=140 10342 pycrypto-2.0.1.p1 ansic=7302,python=3036,sh=4 9769cddlib-094b ansic=9036,sh=733 8974iml-1.0.1.p7ansic=6155,sh=2819 8923libfplll-2.1-20071024 cpp=5437,sh=3486 8151lcalc-20070107 cpp=4580,ansic=3548,sh=23 6771mpfi-1.3.4-rc3.p8 ansic=3960,sh=2811 6037opencdk-0.5.9 ansic=5456,perl=465,sh=116 5912ipython1-20070130 python=5818,ansic=68,sh=26 5491pysqlite-2.3.3 ansic=3377,python=2106,sh=8 4242python_gnutls-1.1.1 python=4213,ansic=23,sh=6 3796sympow-1.018.1.p3 ansic=3367,sh=429 3766weave-0.4.9 python=3760,sh=6 3584sage_scripts-2.8.9.rc1 python=1869,sh=1714,lisp=1 3527gdmodule-0.56.p4 ansic=3316,python=198,sh=13 3015extcode-2.8.9.rc1 objc=2765,java=176,lisp=62,sh=12 2224flintqs-20070817 cpp=1574,ansic=623,sh=27 1975genus2reduction-0.3 ansic=1962,sh=13 1329pexpect-2.0.p1 python=1322,sh=7 900 termcap-1.3.1 ansic=857,sh=43 783 examples-2.8.9.rc1 python=719,sh=30,lisp=18,fortran=13,ansic=3 140 fortran-20070912 python=130,sh=10 25 elliptic_curves-0.1 sh=25 17 java3d-20070901 sh=17 2 conway_polynomials-0.2 sh=2 2 graphs-20070722 sh=2 Totals grouped by language (dominant language first): ansic: 1907386 (39.59%) python: 1186092 (24.62%) cpp: 553701 (11.49%) fortran: 492184 (10.22%) lisp:340210 (7.06%) sh: 138356 (2.87%) asm: 79260 (1.65%) perl: 60285 (1.25%) tcl: 32992 (0.68%) java: 10880 (0.23%) objc: 6426 (0.13%) yacc: 2734 (0.06%) ada: 1681 (0.03%) lex: 1493 (0.03%) pascal:1205 (0.03%) cs: 879 (0.02%) php:642
[sage-devel] Re: sloccount of sage-2.8.9.rc1
Sorry to reply to myself so quickly, but as Carl Witty pointed out I need to run the code with --multiproject. In addition we now count pxd, pxi and pyx as python. With those settings we do get slighly smaller number, but still very impressive results: SLOCDirectory SLOC-by-Language (Sorted) 687172 python-2.5.1.p7 ansic=354375,python=315376,asm=6567,sh=3895,lisp=3683, perl=2520,objc=756 424057 scipy-20070817 cpp=120609,ansic=112030,python=110060,fortran=80892, objc=424,sh=42 366515 lapack-20070723 fortran=366387,pascal=116,sh=12 289667 maxima-5.13.0 lisp=246582,fortran=14666,perl=14325,tcl=10222,sh=3386, ansic=471,python=8,awk=7 243569 matplotlib-0.90.0.p4 python=143836,cpp=86548,ansic=13166,sh=19 217702 singular-3-0-3-2-20071020 cpp=178602,ansic=22558,perl=5570,lisp=4063, sh=3454,yacc=1702,lex=1398,csh=189,python=163,sed=3 214448 sage-2.8.9.rc1 python=204905,cpp=7261,ansic=2175,sh=107 180146 gsl-1.9 ansic=177097,sh=3038,python=11 148822 gmp-4.2.1.p10 ansic=71142,asm=51587,cpp=13109,sh=9189,perl=3247, yacc=226,lisp=203,lex=95,fortran=24 138581 clisp-2.41.p8 lisp=74381,ansic=40568,sh=11561,fortran=6692,cpp=2660, objc=2481,perl=164,sed=55,python=19 136954 twisted-2.5.0.p8 python=134784,ansic=2132,sh=38 127343 numpy-20070816 ansic=74659,python=52027,fortran=248,cpp=197,sh=115, f90=97 122683 gap-4.4.10 ansic=116320,sh=3008,lisp=1804,perl=1545,awk=6 120578 pari-2.3.2.p3 ansic=114629,lisp=5173,sh=603,perl=153,python=20 99638 gnutls-1.6.3ansic=95992,sh=1956,cpp=1046,perl=628,sed=16 89269 freetype-2.1.10 ansic=75080,sh=8160,python=6029 85877 sqlite-3.3.17.p1 ansic=62811,tcl=19241,sh=2839,yacc=806,awk=180 78638 symmetrica-0.3.3 ansic=78621,sh=17 78227 ntl-5.4.1.p6ansic=78132,sh=95 71706 sympy-0.5.3 python=71703,sh=3 69131 cvxopt-0.8.2.p3 ansic=64322,python=4019,fortran=777,sh=11,awk=2 68472 linbox-20070915 cpp=67991,sh=475,sed=4,perl=2 56976 mpfr-2.3.0 ansic=51542,sh=5434 48014 moin-1.5.7 python=35148,java=10704,perl=1424,php=642,sh=96 43165 doc-2.8.9.rc1 perl=25684,python=14518,lisp=2427,sh=473,ansic=61, sed=2 42891 libpng-1.2.18 ansic=34404,sh=8482,cpp=5 42128 libgcrypt-1.2.4 ansic=29468,sh=8048,asm=4612 41945 mercurial-0.9.5 python=27386,sh=8300,tcl=3484,lisp=1411,ansic=1364 40831 gd-2.0.33.p5ansic=32741,sh=7625,perl=420,tcl=45 36865 zodb3-3.7.0 python=29676,ansic=7183,sh=6 35272 ecm-6.1.3 ansic=17313,asm=13213,sh=4085,python=661 33854 f2c-20070816ansic=33833,sh=21 32399 mwrank-20070913 cpp=30167,sh=2232 31381 flint-0.2.p4ansic=29483,cpp=1540,python=246,sh=112 30135 readline-5.2ansic=22060,perl=4105,sh=3970 24965 cython-0.9.6.7.a python=21953,ansic=3012 23341 quaddouble-2.2.p7 cpp=8526,sh=8387,fortran=6428 21954 networkx-0.35.1 python=21950,sh=4 21542 scons-0.97 python=21536,sh=6 18624 givaro-3.2.6.p1 cpp=10211,sh=8409,sed=4 18272 ipython-0.8.1.p1 python=17982,lisp=262,sh=28 16862 zlib-1.2.3.p2 ansic=8912,asm=3281,ada=1681,pascal=1089,cpp=1001, cs=879,sh=19 16070 blas-20070724 fortran=16057,sh=13 13989 palp-1.1ansic=13978,sh=11 13519 tachyon-0.98beta.p2 ansic=13445,sh=41,perl=33 12660 gfan-0.2.2.p1 cpp=12637,sh=23 11948 libgpg_error-1.5 sh=8126,ansic=3254,awk=428,lisp=140 10342 pycrypto-2.0.1.p1 ansic=7302,python=3036,sh=4 9769cddlib-094b ansic=9036,sh=733 8974iml-1.0.1.p7ansic=6155,sh=2819 8923libfplll-2.1-20071024 cpp=5437,sh=3486 8151lcalc-20070107 cpp=4580,ansic=3548,sh=23 6771mpfi-1.3.4-rc3.p8 ansic=3960,sh=2811 6037opencdk-0.5.9 ansic=5456,perl=465,sh=116 5912ipython1-20070130 python=5818,ansic=68,sh=26 5491pysqlite-2.3.3 ansic=3377,python=2106,sh=8 4242python_gnutls-1.1.1 python=4213,ansic=23,sh=6 3796sympow-1.018.1.p3 ansic=3367,sh=429 3766weave-0.4.9 python=3760,sh=6 3584sage_scripts-2.8.9.rc1 python=1869,sh=1714,lisp=1 3527gdmodule-0.56.p4 ansic=3316,python=198,sh=13 3015extcode-2.8.9.rc1 objc=2765,java=176,lisp=62,sh=12 2224flintqs-20070817 cpp=1574,ansic=623,sh=27 1975genus2reduction-0.3 ansic=1962,sh=13 1856examples-2.8.9.rc1 python=1792,sh=30,lisp=18,fortran=13,ansic=3 1329pexpect-2.0.p1 python=1322,sh=7 900 termcap-1.3.1 ansic=857,sh=43 140 fortran-20070912 python=130,sh=10 25 elliptic_curves-0.1 sh=25 17 java3d-20070901 sh=17 2 conway_polynomials-0.2 sh=2 2 graphs-20070722 sh=2 Totals grouped by language (dominant language first): ansic: 1907386 (39.01%) python: 1258260 (25.73%) cpp: 553701 (11.32%) fortran: 492184 (10.07%) lisp:340210 (6.96%) sh: 138356 (2.83%) asm: 79260 (1.62%) perl: 60285 (1.23%) tcl: 32992 (0.67%) java: 10880 (0.22%) objc:
[sage-devel] Re: SAGE 2.8.9rc1
So far four issues have popped up:
1) sage-banner is zero bytes in size
2) On x86 linux we have the following failure:
[EMAIL PROTECTED] sage-2.8.9.rc1]$ ./sage -t devel/sage-main/sage/
rings/polynomial/multi_polynomial_ideal.py
sage -t devel/sage-main/sage/rings/polynomial/
multi_polynomial_ideal.py
**
File multi_polynomial_ideal.py, line 1078:
sage: V = I.variety(); V
Expected:
[{y: w^2 + 2, x: 2*w}, {y: w^2 + 2*w, x: 2*w + 2}, {y: w^2 + w, x:
2*w + 1}]
Got:
[{y: w^2 + w, x: 2*w + 1}, {y: w^2 + 2*w, x: 2*w + 2}, {y: w^2 +
2, x: 2*w}]
**
1 items had failures:
1 of 7 in __main__.example_27
***Test Failed*** 1 failures.
For whitespace errors, see the file .doctest_multi_polynomial_ideal.py
[5.4 s]
exit code: 256
--
3) pretty printing in maxima is broken:
[EMAIL PROTECTED] sage-2.8.9.rc1]$ ./sage -t devel/sage-main/sage/
calculus/equations.py
sage -t devel/sage-main/sage/calculus/equations.py
**
File equations.py, line 12:
sage: print solve(qe, x)
Expected:
[
2
- sqrt(b - 4 a c) - b
x == --
2 a,
2
sqrt(b - 4 a c) - b
x ==
2 a
]
Got:
[x == (-sqrt(b^2 - 4*a*c) - b)/(2*a), x == (sqrt(b^2 - 4*a*c) - b)/
(2*a)]
**
1 items had failures:
1 of 22 in __main__.example_0
***Test Failed*** 1 failures.
For whitespace errors, see the file .doctest_equations.py
[6.4 s]
exit code: 256
--
The following tests failed:
sage -t devel/sage-main/sage/calculus/equations.py
Total time for all tests: 6.5 seconds
[EMAIL PROTECTED] sage-2.8.9.rc1]$ ./sage -t devel/sage-main/sage/
schemes/elliptic_curves/ell_generic.py
sage -t devel/sage-main/sage/schemes/elliptic_curves/ell_generic.py
**
File ell_generic.py, line 249:
sage: print F.solve(y)
Expected:
[
3 2
- sqrt(4 x - 4 x - 40 x - 79) - 1
y == ---
2,
3 2
sqrt(4 x - 4 x - 40 x - 79) - 1
y == -
2
]
Got:
[y == (-sqrt(4*x^3 - 4*x^2 - 40*x - 79) - 1)/2, y == (sqrt(4*x^3 -
4*x^2 - 40*x - 79) - 1)/2]
**
1 items had failures:
1 of 21 in __main__.example_4
***Test Failed*** 1 failures.
For whitespace errors, see the file .doctest_ell_generic.py
[5.2 s]
exit code: 256
--
The following tests failed:
sage -t devel/sage-main/sage/schemes/elliptic_curves/
ell_generic.py
Total time for all tests: 5.2 seconds
[EMAIL PROTECTED] sage-2.8.9.rc1]$
All issues have had tickets opened. If you find anything else please
let us know as soon as possible, bonus points for fixes ;)
Cheers,
Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: potential cause for #557: cython missing dictionary deallocation
On Oct 25, 9:06 am, Robert Bradshaw [EMAIL PROTECTED] wrote: Hi Robert, Seehttp://sage.math.washington.edu/home/robertwb/cython/All tests pass with cleanup level 1 (now default). The command line option --cleanup n sets the level (0 = n = 3). Things crash on quit (in SAGE, though not with simple examples) with level 3. This may or may not fix #557, but is a start (but at the very least should make the memcheck logs somewhat cleaner). We can play with it from here). Excellent, I will play with this tonight and report back. - Robert Cheers, Michael SNIP --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Unhandled SIGSEGV: Ticket #973
On Oct 24, 7:00 pm, William Stein [EMAIL PROTECTED] wrote: On 10/24/07, Jaap Spies [EMAIL PROTECTED] wrote: It is not in matrix2.pyx, It is on the bottom of my first message and here below. It uses some functions/methods present in matrix2.pyx: rook_vector, permanental_minor, prod_of_row_sums, permanent. I think you should submit a patch to Sage so that this code gets included standard. It could go somewhere in the combinat directory. Is it a sloane sequences? It shouldn't be in sage.all by default, but should be easy for users to import. increase the amount of swap you have in that box. Adding more physical RAM will probably makes the problem go away, too. I rebooted with no succes. Same error using 50-60% of 1 GB memory. Swap space is 5 GB. Jaap Ok, I will investigate on a 32 bit box then. Could you give us distribution/gcc and so on please? It might be related to specific compilers. Linux paix 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 23:10:59 EDT 2007 i686 i686 i386 GNU/Linux gcc (GCC) 4.1.2 20070925 (Red Hat 4.1.2-27) Jaap --- ## # Copyright (C) 2006 Jaap Spies, [EMAIL PROTECTED] # # Distributed under the terms of the GNU General Public License (GPL): # # http://www.gnu.org/licenses/ ## Usage from sage sage: attach 'dancing.sage' sage: dance(4) h^4 - 2*h^3 + 9*h^2 - 8*h + 6 # use variable 'h' in the polynomial ring over the rationals h = QQ['h'].gen() def dance(m): Generates the polynomial solutions of the Dancing School Problem Based on a modification of theorem 7.2.1 from Brualdi and Ryser, Combinatorial Matrix Theory. See NAW 5/7 nr. 4 december 2006 p. 285 INPUT: integer m OUTPUT: polynomial in 'h' EXAMPLE: sage: dance(4) h^4 - 2*h^3 + 9*h^2 - 8*h + 6 AUTHOR: Jaap Spies (2006) n = 2*m-2 M = MatrixSpace(ZZ, m, n) A = M([0 for i in range(m*n)]) for i in range(m): for j in range(n): if i j or j i + n - m: A[i,j] = 1 rv = A.rook_vector() # print rv s = sum([(-1)^k*rv[k]*falling_factorial(m+h-k, m-k) for k in range(m+1)]) print s Hello folks, over night I got a better bt on my local 32 bit FC 7 box: sage: time dance(10) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208650048 (LWP 3143)] 0x00786473 in strlen () from /lib/libc.so.6 (gdb) (gdb) bt #0 0x00786473 in strlen () from /lib/libc.so.6 #1 0x0809354f in PyString_FromFormatV (format=0x811ef6c '%.200s' object cannot be interpreted as an index, vargs=value optimized out) at Objects/stringobject.c:202 #2 0x080d4ee0 in PyErr_Format (exception=0x813b560, format=0x811ef6c '%.200s' object cannot be interpreted as an index) at Python/errors.c:522 #3 0x0805d578 in PyNumber_Index (item=0x0) at Objects/abstract.c:965 #4 0x011ac5ee in __pyx_f_py_20matrix_integer_dense_20Matrix_integer_dense_prod_of_row_sums (__pyx_v_self=0xa4a8104, __pyx_v_cols=0xaf96ecc) at sage/matrix/matrix_integer_dense.c: 13576 #5 0x0805a277 in PyObject_Call (func=0x0, arg=0xa4a048c, kw=0x0) at Objects/abstract.c:1860 #6 0x080be7cc in PyEval_CallObjectWithKeywords (func=0xaf9b62c, arg=0xa4a048c, kw=0x0) at Python/ceval.c:3433 #7 0x0805a490 in PyObject_CallObject (o=0xaf9b62c, a=0xa4a048c) at Objects/abstract.c:1851 #8 0x07db98c6 in __pyx_f_py_7matrix2_6Matrix_permanent (__pyx_v_self=0xa4a8104, unused=0x0) at sage/matrix/matrix2.c:1657 #9 0x0805a277 in PyObject_Call (func=0x0, arg=0xb7f1702c, kw=0x0) at Objects/abstract.c:1860 #10 0x080be7cc in PyEval_CallObjectWithKeywords (func=0xaf9694c, arg=0xb7f1702c, kw=0x0) at Python/ceval.c:3433 #11 0x0805a490 in PyObject_CallObject (o=0xaf9694c, a=0x0) at Objects/ abstract.c:1851 #12 0x07db8711 in __pyx_f_py_7matrix2_6Matrix_permanental_minor (__pyx_v_self=0xa4a8a94, __pyx_arg_k=0x97f8ee4) at sage/matrix/matrix2.c:2077 #13 0x0805a277 in PyObject_Call (func=0x0, arg=0xa41c44c, kw=0x0) at Objects/abstract.c:1860 #14 0x080be7cc in PyEval_CallObjectWithKeywords (func=0xaf87cec, arg=0xa41c44c, kw=0x0) at Python/ceval.c:3433 #15 0x0805a490 in PyObject_CallObject (o=0xaf87cec, a=0xa41c44c) at Objects/abstract.c:1851 #16 0x07daf6e2 in __pyx_f_py_7matrix2_6Matrix_rook_vector (__pyx_v_self=0xa4a8a94, __pyx_args=0xb7f1702c, __pyx_kwds=0x0) at sage/matrix/matrix2.c:2402 #17 0x080c539c in PyEval_EvalFrameEx (f=0xb00497c, throwflag=0) at Python/ceval.c:3564 #18 0x080c57c5 in PyEval_EvalFrameEx (f=0xb004814, throwflag=0) at Python/ceval.c:3650 #19 0x080c65d5 in PyEval_EvalCodeEx (co=0xa4a8338, globals=0xaf1035c, locals=0xaf1035c,
[sage-devel] Re: trac ticket #1000?
On Oct 25, 2:48 pm, David Harvey [EMAIL PROTECTED] wrote: Does the lucky bug reporter get a prize? He/she will be allowed to fix it ;) - if that isn't price enough I don't know what would be *ducks* Two more tickets :) david Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sloccount of sage-2.8.9.rc1
On Oct 25, 6:14 pm, David Joyner [EMAIL PROTECTED] wrote: On 10/25/07, William Stein [EMAIL PROTECTED] wrote: Hello, On 10/25/07, Bill Hart [EMAIL PROTECTED] wrote: There are some real surprises on that list. MPFR has many more lines of code than I thought, Pari many fewer lines of code. It's amazing what it achieves with such a small code base. I think one should take everything in that table with a grain of salt, and verify it by hand if it is really surprising. That said, it does say something. FLINT is a bloated pig compared to NTL, given what the two packages actually do. What's really amazing is that GMP has so much more code than Pari. Maybe part of that is that GMP has lots of assembler code and dozens of different versions of the same function for dozens of different architectures. ? Yep, that inflates the line count by quite a bi, but overall we use quite a bit of those architectures. Also, aren't CoCoALib and MPC used in SAGE? Neither of them are used on Sage. A public version of CoCoALib was only fairly recently released, and by that time Sage already had a powerful library interface to Singular. I had wanted to use MPC in Sage at one point, but when I tried I was shocked by how far MPC was behind PARI in functionality, especially for special functions. At the time MPC wasn't very mature / stable either. Perhaps in a year both cocoalib and mpc could be in Sage; I don't know. Bill Page: For example, does the Lisp entry in mercurial-0.9.5 python=27386,sh=8300,tcl=3484,lisp=1411,ansic=1364 make sense? As far as I know mercurial does not use any Lisp, or does it? That's a huge surprise to me too. I can't imagine how mercurial would make use of lisp code. It certainly doesn't depend on lisp to be installed. The lisp lines in GAP are due to the emacs interface. Maybe mercurial is similar? Also, the number of lines of GAP code written in GAP's own interpretive language (which is the majority) is not counted at all ... Yep, there library code of Singular is also not counted at the moment. sloccount can easily be taught about those files types by just adding an extension in the right has and the plan is to do so in the future. If you see another package with suspicious stats please comment at ticket #999, especially if you know the file extensions that were probably overlooked. The numbers above resulted from a hey, wouldn't it be fun to ... moment in IRC, but it gives us a good idea about the sheer size of Sage, so hopefully we will get this automated soon. -- William Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: potential cause for #557: cython missing dictionary deallocation
On Oct 25, 11:25 am, mabshoff [EMAIL PROTECTED] dortmund.de wrote: On Oct 25, 9:06 am, Robert Bradshaw [EMAIL PROTECTED] wrote: Hi Robert, Seehttp://sage.math.washington.edu/home/robertwb/cython/Alltests pass with cleanup level 1 (now default). The command line option --cleanup n sets the level (0 = n = 3). Things crash on quit (in SAGE, though not with simple examples) with level 3. This may or may not fix #557, but is a start (but at the very least should make the memcheck logs somewhat cleaner). We can play with it from here). Excellent, I will play with this tonight and report back. Hmm, with 2.8.9 I get the following error when using http://sage.math.washington.edu/home/robertwb/cython/cython-0.9.6.8.spkg Building sage/matrix/misc.c because it depends on sage/matrix/ misc.pyx. touch sage/matrix/misc.pyx; cython --embed-positions --incref-local- binop -I/tmp/Work-mabshoff/sage-2.8.9/devel/sage-main -o sage/matrix/ misc.c sage/matrix/misc.pyx Error converting Pyrex file to C: ... 0, 0, 0) cdef mpz_t* L_row cdef mod_int* A_row for i from 0 = i A._nrows: L_row = L._matrix[i] A_row = A._matrix[i] ^ /tmp/Work-mabshoff/sage-2.8.9/devel/sage-main/sage/matrix/misc.pyx: 54:25: Cannot assign type 'sage.matrix.matrix_modn_dense.mod_int *' to 'sage.matrix.misc.mod_int *' sage: Error running cython. sage: There was an error installing modified sage library code. I don't think misc.pyx has changed in a while. Any ideas? - Robert Cheers, Michael SNIP --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: potential cause for #557: cython missing dictionary deallocation
On Oct 25, 8:04 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: On Oct 25, 2007, at 10:03 AM, mabshoff wrote: On Oct 25, 11:25 am, mabshoff [EMAIL PROTECTED] dortmund.de wrote: On Oct 25, 9:06 am, Robert Bradshaw [EMAIL PROTECTED] wrote: Hi Robert, Seehttp://sage.math.washington.edu/home/robertwb/cython/Alltests pass with cleanup level 1 (now default). The command line option --cleanup n sets the level (0 = n = 3). Things crash on quit (in SAGE, though not with simple examples) with level 3. This may or may not fix #557, but is a start (but at the very least should make the memcheck logs somewhat cleaner). We can play with it from here). Excellent, I will play with this tonight and report back. Hmm, with 2.8.9 I get the following error when using http://sage.math.washington.edu/home/robertwb/cython/ cython-0.9.6.8.spkg Building sage/matrix/misc.c because it depends on sage/matrix/ misc.pyx. touch sage/matrix/misc.pyx; cython --embed-positions --incref-local- binop -I/tmp/Work-mabshoff/sage-2.8.9/devel/sage-main -o sage/matrix/ misc.c sage/matrix/misc.pyx Error converting Pyrex file to C: ... 0, 0, 0) cdef mpz_t* L_row cdef mod_int* A_row for i from 0 = i A._nrows: L_row = L._matrix[i] A_row = A._matrix[i] ^ /tmp/Work-mabshoff/sage-2.8.9/devel/sage-main/sage/matrix/misc.pyx: 54:25: Cannot assign type 'sage.matrix.matrix_modn_dense.mod_int *' to 'sage.matrix.misc.mod_int *' sage: Error running cython. sage: There was an error installing modified sage library code. I don't think misc.pyx has changed in a while. Any ideas? Hi Robert, Did you apply the accompanying .hg patch to sage-main? nope, but that fixed the problem. It didn't seem obvious, so I ignored that bundle. With the old Cython: ==26784== LEAK SUMMARY: ==26784==definitely lost: 0 bytes in 0 blocks. ==26784== possibly lost: 251,078 bytes in 625 blocks. ==26784==still reachable: 36,000,918 bytes in 20,368 blocks. ==26784== suppressed: 0 bytes in 0 blocks. With the new Cython and n=1 I get: ==31741== LEAK SUMMARY: ==31741==definitely lost: 0 bytes in 0 blocks. ==31741== possibly lost: 253,574 bytes in 633 blocks. ==31741==still reachable: 36,244,988 bytes in 20,359 blocks. ==31741== suppressed: 0 bytes in 0 blocks. So there has been a slight decrease in the number of blocks that are still reachable or possibly lost, even thought the amount of memory increased. I will try with n=2 to see if anything changes. How do I change the default by the way? Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: potential cause for #557: cython missing dictionary deallocation
On Oct 25, 9:34 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: On Oct 25, 2007, at 12:14 PM, mabshoff wrote: On Oct 25, 8:04 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: On Oct 25, 2007, at 10:03 AM, mabshoff wrote: On Oct 25, 11:25 am, mabshoff [EMAIL PROTECTED] dortmund.de wrote: On Oct 25, 9:06 am, Robert Bradshaw [EMAIL PROTECTED] Did you apply the accompanying .hg patch to sage-main? nope, but that fixed the problem. It didn't seem obvious, so I ignored that bundle. There's often a few tweaks that need to be done to the SAGE codebase to get it to work with the new cython...that one there was fixing a hack that didn't work anymore. With the old Cython: ==26784== LEAK SUMMARY: ==26784==definitely lost: 0 bytes in 0 blocks. ==26784== possibly lost: 251,078 bytes in 625 blocks. ==26784==still reachable: 36,000,918 bytes in 20,368 blocks. ==26784== suppressed: 0 bytes in 0 blocks. With the new Cython and n=1 I get: ==31741== LEAK SUMMARY: ==31741==definitely lost: 0 bytes in 0 blocks. ==31741== possibly lost: 253,574 bytes in 633 blocks. ==31741==still reachable: 36,244,988 bytes in 20,359 blocks. ==31741== suppressed: 0 bytes in 0 blocks. So there has been a slight decrease in the number of blocks that are still reachable or possibly lost, even thought the amount of memory increased. More stuff is interned with the new cython (e.g. python int constants are pre-computed rather than constructed/destructed on the fly throughout the code) as well as other changes. I'm curious how n=0 vs. n=1 behaves, as well as, of course, n=2+. I will try with n=2 to see if anything changes. How do I change the default by the way? Hi Robert, Try adding --clean 2 to line 1008 of process_cython_file() in setup.py. that doesn't work yet, because the parsing of the command line doesn't seem to comprehend --clean yet, so I hardcoded the value I wanted for now. With n=2 I get the following which might be the cause for the memory corruption: ==14064== Invalid free() / delete / delete[] ==14064==at 0x4A1B74A: free (vg_replace_malloc.c:320) ==14064==by 0xB98B0D8: __pyx_f_4sage_5rings_7integer_fast_tp_dealloc (integer.c:13607) ==14064==by 0x4B0022: collect (gcmodule.c:714) ==14064==by 0x4B0373: PyGC_Collect (gcmodule.c:1265) ==14064==by 0x4A612C: Py_Finalize (pythonrun.c:387) ==14064==by 0x4A5C7A: handle_system_exit (pythonrun.c:1616) ==14064==by 0x4A5E78: PyErr_PrintEx (pythonrun.c:1062) ==14064==by 0x4A6686: PyRun_SimpleFileExFlags (pythonrun.c:976) ==14064==by 0x412319: Py_Main (main.c:134) ==14064==by 0x4FD94C9: (below main) (in /lib/libc-2.3.6.so) ==14064== Address 0x73287d8 is 0 bytes inside a block of size 8 free'd ==14064==at 0x4A1B74A: free (vg_replace_malloc.c:320) ==14064==by 0xB98B0D8: __pyx_f_4sage_5rings_7integer_fast_tp_dealloc (integer.c:13607) ==14064==by 0xB9847E2: cleanup (integer.c:15198) ==14064==by 0x415522: PyObject_Call (abstract.c:1860) ==14064==by 0x481ACA: PyEval_EvalFrameEx (ceval.c:3844) ==14064==by 0x484F3A: PyEval_EvalCodeEx (ceval.c:2831) ==14064==by 0x4CE527: function_call (funcobject.c:517) ==14064==by 0x415522: PyObject_Call (abstract.c:1860) ==14064==by 0x47C850: PyEval_CallObjectWithKeywords (ceval.c:3433) ==14064==by 0x4A60BC: Py_Finalize (pythonrun.c:1589) ==14064==by 0x4A5C7A: handle_system_exit (pythonrun.c:1616) ==14064==by 0x4A5E78: PyErr_PrintEx (pythonrun.c:1062) - Robert Carl Witty was also wondering whether your new Cython.spkg was ready for 2.8.10 or if we should wait. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: potential cause for #557: cython missing dictionary deallocation
On Oct 26, 5:18 am, Robert Bradshaw [EMAIL PROTECTED] wrote: On Oct 25, 2007, at 7:46 PM, mabshoff wrote: On Oct 25, 9:34 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: Hi Robert, Try adding --clean 2 to line 1008 of process_cython_file() in setup.py. that doesn't work yet, because the parsing of the command line doesn't seem to comprehend --clean yet, so I hardcoded the value I wanted for now. Sorry, that should have been --cleanup 2, but hardcoding works too. With n=2 I get the following which might be the cause for the memory corruption: ==14064== Invalid free() / delete / delete[] ==14064==at 0x4A1B74A: free (vg_replace_malloc.c:320) ==14064==by 0xB98B0D8: __pyx_f_4sage_5rings_7integer_fast_tp_dealloc (integer.c:13607) ==14064==by 0x4B0022: collect (gcmodule.c:714) ==14064==by 0x4B0373: PyGC_Collect (gcmodule.c:1265) ==14064==by 0x4A612C: Py_Finalize (pythonrun.c:387) ==14064==by 0x4A5C7A: handle_system_exit (pythonrun.c:1616) ==14064==by 0x4A5E78: PyErr_PrintEx (pythonrun.c:1062) ==14064==by 0x4A6686: PyRun_SimpleFileExFlags (pythonrun.c:976) ==14064==by 0x412319: Py_Main (main.c:134) ==14064==by 0x4FD94C9: (below main) (in /lib/libc-2.3.6.so) ==14064== Address 0x73287d8 is 0 bytes inside a block of size 8 free'd ==14064==at 0x4A1B74A: free (vg_replace_malloc.c:320) ==14064==by 0xB98B0D8: __pyx_f_4sage_5rings_7integer_fast_tp_dealloc (integer.c:13607) ==14064==by 0xB9847E2: cleanup (integer.c:15198) ==14064==by 0x415522: PyObject_Call (abstract.c:1860) ==14064==by 0x481ACA: PyEval_EvalFrameEx (ceval.c:3844) ==14064==by 0x484F3A: PyEval_EvalCodeEx (ceval.c:2831) ==14064==by 0x4CE527: function_call (funcobject.c:517) ==14064==by 0x415522: PyObject_Call (abstract.c:1860) ==14064==by 0x47C850: PyEval_CallObjectWithKeywords (ceval.c:3433) ==14064==by 0x4A60BC: Py_Finalize (pythonrun.c:1589) ==14064==by 0x4A5C7A: handle_system_exit (pythonrun.c:1616) ==14064==by 0x4A5E78: PyErr_PrintEx (pythonrun.c:1062) Hello Robert, This last one might be due to funny stuff we do with the fast alloc/ dealloc stuff. Try compiling just the integer file with --cleanup 1 and see if that fixes it. Yep, for n=2 and n=3 there isn't anything funny going on. Ironically valgrind pretty much reports the same amount of still reachable memory: ==17336== LEAK SUMMARY: ==17336==definitely lost: 0 bytes in 0 blocks. ==17336== possibly lost: 253,574 bytes in 633 blocks. ==17336==still reachable: 36,239,900 bytes in 20,342 blocks. ==17336== suppressed: 0 bytes in 0 blocks. Perhaps we could incref __pyx_v_4sage_5rings_7integer_global_dummy_Integer manually so it's never actually collected. Or it could be something more subtle. Carl Witty was also wondering whether your new Cython.spkg was ready for 2.8.10 or if we should wait. I believe so, it compiles all of SAGE and passes all doctests. Stefan (the other main Cython guy) is having trouble getting his code to work though. ok. One more thing: I compiled python --pydebug and I get the following crash related to nteger_fast_tp_dealloc, so it seems that something very odd is going on there: -- | SAGE Version 2.8.9.alpha0, Release Date: 2007-10-23| | Type notebook() for the GUI, and license() for information.| -- sage: Exiting SAGE (CPU time 0m0.07s, Wall time 0m2.15s). Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208604992 (LWP 20053)] 0x0078341b in free () from /lib/libc.so.6 (gdb) bt #0 0x0078341b in free () from /lib/libc.so.6 #1 0x00ea2f38 in __pyx_f_7integer_fast_tp_dealloc (__pyx_v_o=0x91c046c) at sage/rings/integer.c:15544 #2 0x08083bdf in dict_dealloc (mp=0x91b7334) at Objects/dictobject.c: 847 #3 0x08083bdf in dict_dealloc (mp=0x8cf7474) at Objects/dictobject.c: 847 #4 0x080d9659 in _PyImport_Fini () at Python/import.c:229 #5 0x080e4da4 in Py_Finalize () at Python/pythonrun.c:419 #6 0x080e48ea in handle_system_exit () at Python/pythonrun.c:1616 #7 0x080e4ae5 in PyErr_PrintEx (set_sys_last_vars=1) at Python/ pythonrun.c:1062 #8 0x080e5303 in PyRun_SimpleFileExFlags (fp=0x0, filename=0xbfa27cb3 /tmp/Work/sage-2.8.9.rc1/local/bin/sage-gdb- pythonstartup, closeit=0, flags=0xbfa268e8) at Python/pythonrun.c:976 #9 0x080571a6 in Py_Main (argc=0, argv=0xbfa269b4) at Modules/main.c: 134 #10 0x08056432 in main (argc=Cannot access memory at address 0x1 ) at ./Modules/python.c:23 (gdb) quit I will try with a clean build to see if I can get to the bottom of this. Cheers, Michael - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL
[sage-devel] Re: Unhandled SIGSEGV: Ticket #973
Hello Jaap, I assume you care about the following (computed on sage.math): sage: dance(11) h^11 - 44*h^10 + 1045*h^9 - 16500*h^8 + 187935*h^7 - 1595748*h^6 + 10199343*h^5 - 48691500*h^4 + 169140180*h^3 - 405230320*h^2 + 600311624*h - 415232800 I am currently computing dance(12) on sage.math. William: feel free to kill pid 5655 in case you consider this a waste of your resources. I had to kill the valgrind process on my local box because valgrind stopped counting errors after the 1,000,000th. I also extrapolated how long it would take and I am not willing to wait a month for it to finish (if it does at all). I started looking at the code itself to see if we cannot come up with an easier to run test case that segfaults and currently I am looking at the components like permanent() and so on that are using via rook_vector. So if you have any ideas where that code could overflow on 32 bit please let me know. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Unhandled SIGSEGV: Ticket #973
On Oct 27, 1:57 am, Jaap Spies [EMAIL PROTECTED] wrote: Jaap Spies wrote: Hello Jaap, Actually I'm running dance(10) now on my machine and I hope there will be no segfaults, because I simplified the code. It will take less than 3.5 hours to finish. Sorry, my hope was idle: same error!! Arrg, change of strategy: Since rook_vector() consumes the vast amount of time to compute I am trying to compute it on my box. If it does compute without segfaulting for dance(10) I will then run the rest of the code under valgrind, otherwise I will start adding debug print statements into the code the rook_vector() code and the components used. I am also running 2.8.9 + your patch from #931, which has already been merged for 2.8.10.alpha0. On a side note: Could you comment on #217? It is rather vague and there have been some improvements. If you have more improvements relative to #931 you should open another/more tickets for it/them. Jaap Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Unhandled SIGSEGV: Ticket #973
On Oct 27, 1:48 pm, Jaap Spies [EMAIL PROTECTED] wrote: Hi Michael, You wrote: On a side note: Could you comment on #217? It is rather vague and there have been some improvements. If you have more improvements relative to #931 you should open another/more tickets for it/them. Now you have changed #217 to milestone sage-2.8.10, I'll better send a patch here, so this old ticket can be closed. :), but feel free to change the title of the ticket and also the milestone it is tagged against. William said that it is one of those very vague generic milestones from the old days and we have been invalidating those and usually open more specific tickets in place of them. To be honnest, I never saw this ticket before! I came across it today by accident searching for another ticket, so you are not alone. dance(10) crashed for me inside rook_vector(), so I will be taking it from here by adding debug output to nail the exact place where it happens. Jaap Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Fun Things to do with a Sage Notebook
On Oct 27, 8:13 pm, TrixB4Kidz [EMAIL PROTECTED] wrote: Hello Brian, Here are a few fun things that anyone can do with a public Sage Notebook: 1. Use the Sage server as remote file storage. Take your pick between ftp, cvs, subversion, or even brew your own protocol. 2. Host your own web site. Remember: Apache is only a wget away! 3. Are your thesis simulations taking too long to run? Try distributing your algorithm to a cluster of Sage notebooks. 4. Build a process cluster that randomly kills Sage processes. For long-lasting effects, be sure that your processes can react to a partial discovery of their existence. 5. Deploy network crawlers. Who knows? You might even find another home for your remote file storage. 6. Access eJournals and other materials that are typically restricted outside of the campus network. My point: there really is no reason to root a Sage box because it already provides for many other opportunities. While rooting the box may allow you to get around the ulimit or quotas, these really do not pose serious problems anyway. The trick here is just to distribute your resource usage among the publicly-usable sageXX accounts. Well, a public notebook is like a public shell account, which we have all agreed upon that it is a bad idea. Even if you restrict the notebook to accounts you give out the problems you describe are still possible for the registered users, but that is mostly due that one has in fact a local shell accounts of one has a sage notebook account. And admins should be able to spot abuse there, that is usually what they get paid for. I'm doing some research into SELinux to see if there are any tricks that can be done to eliminate these issues. If possible, I would like to do the following: 1. Disallow the sageXX accounts from opening sockets in any program except Sage. This would prevent people from running open-source servers (such as subversion or apache), but it would not prevent them from writing their own servers within the Sage Notebook. Control over sockets is possible with SELinux. 2. Disallow killing processes by any sageXX account. This essentially means limiting the interrupts that can be issued. I am not sure if that is possible, at least the result would certainly not be in the spirit of Sage. And you would need to reinvent the wheel to do that, so that doesn't make it desirable. If you are really paranoid just set up each notebook for one user only and use different accounts for each individual sage process. That way you have isolation between users. 3. Limit the interprocess communication options to all sageXX accounts. As far as I can tell, there is no reason for any of them to be allowed to create shared memory segments, process semaphores, or message queues. Although this does not make it impossible to build process clusters, it sure makes it a lot more difficult. As long as one has Cython a dedicated technically advanced user can get around pretty much any security measurement you might come up with. And you don't want to limit the user to do something low level. 4. Limit the valid address range for outgoing sockets for sageXX accounts. One could easily disallow connections to any system on the campus network by banning the campus's IP range. The sageXX accounts should only be allowed to establish connections with known mathematical databases; however, the addresses of these databases can change due to IP reassignment within ISP's. Rather than having the sageXX processes perform DNS lookups (which requires establishing connections to arbitrary addresses), you could have an external process (such as server2) periodically perform the lookups and store the results in a hosts file. That would complicate the setup of DSage on a cluster and I am not sure what the benefits are. What are you going to do with those databases? Install a rogue elliptic curve database? These adjustments certainly do not prevent the attacks I mentioned, but they do make them quite a bit more difficult to perform. Let me know if any of these adjustments would break Sage as a whole. In the meantime, I'll continue investigating SELinux to see whether or not these proposals are feasible. Great, as a first step you should create a script that relabels all files under Sage so that you can actually run Sage under SELinux. That is ticket #480 in trac. Overall I believe that you have to trust the user to some extent, but use normal diligence to spot abuse. Locking down the Sage notebook will make it harder to use, and I think that the ease of use is what is so great about the Sage notebook. -- Brian Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs:
[sage-devel] Re: potential cause for #557: cython missing dictionary deallocation
On Oct 27, 1:26 am, Robert Bradshaw [EMAIL PROTECTED] wrote: On Oct 25, 2007, at 9:35 PM, mabshoff wrote: Carl Witty was also wondering whether your newCython.spkg was ready for 2.8.10 or if we should wait. I believe so, it compiles all of SAGE and passes all doctests. Stefan (the other mainCythonguy) is having trouble getting his code to work though. ok. Hi Robert, BTW, I just uploaded a new spkg with one more tiny fix (has to do with error reporting). For 2.8.10.alpha1+Craig's fix and python compiled using --without- pymalloc I get with the default cleanup level 1: ==6569== LEAK SUMMARY: ==6569==definitely lost: 181,030 bytes in 2,926 blocks. ==6569== possibly lost: 266,925 bytes in 747 blocks. ==6569==still reachable: 29,184,388 bytes in 179,707 blocks. ==6569== suppressed: 0 bytes in 0 blocks. With cleanup level 3 in general and cleanup level 1 just for integer.pyx I get ==23818== LEAK SUMMARY: ==23818==definitely lost: 181,117 bytes in 2,927 blocks. ==23818== possibly lost: 266,838 bytes in 746 blocks. ==23818==still reachable: 29,157,453 bytes in 179,383 blocks. ==23818== suppressed: 0 bytes in 0 blocks. So my conclusion is that you are on the right way with the cleanup code. Hopefully once we can compile integer.pyx with cleanup level 3 and not crash the amount of still reachable memory should decrease tremendously because integer.pyx should just about be referenced in every extension we have. - Robert Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Unhandled SIGSEGV: Ticket #973
Okay, I got some new results: Changing permanent() slightly in matrix2.pyx: print entering permanent() - m: ,m, n: ,n from sage.rings.arith import binomial for r from 1 = r m+1: lst = _choose(n, r) print lst, lst tmp = [] for cols in lst: tmp.append(self.prod_of_row_sums(cols)) s = sum(tmp) # sn = (-1)^(m-r) if (m - r) % 2 == 0: sn = 1 else: sn = -1 perm = perm + sn * binomial(n-r, m-r) * s print exiting permanent() - perm: , perm Where _choose is defined as: def _choose(int n, int t): Returns all possible sublists of length t from range(n) Based on algoritm L from Knuth's taocp part 4: 7.2.1.3 p.4 AUTHOR: -- Jaap Spies (2007-10-22) x = [] c = range(t) c.append(n) c.append(0) j = 0 while j t: x.append(c[:t]) j = 0 while c[j]+1 == c[j+1]: c[j] = j j = j+1 c[j] = c[j]+1 return x [end of _choose code] At some point the refcount for the list elements goes FUBAR (this is not the first occurence of this, but those scrolled off my screen): We should get (r=1 in this case): entering permanent() - m: 7 n: 7 lst [[1],[2],[3],[4],[5],[6]] But we get: entering permanent() - m: 7 n: 7 lst [[refcnt -2137432134 at 0x92f70ac], [refcnt -2137432183 at 0x92f70a0], [refcnt -2137464436 at 0x92f7094], [refcnt -2138866030 at 0x92f7088], [4], [5], [6]] I assume on 64 bit boxen the refcount is 64 bit, so we never see the issue on sage.math. So does anybody have any idea what is wrong? Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: potential cause for #557: cython missing dictionary deallocation
On Oct 28, 9:48 am, Robert Bradshaw [EMAIL PROTECTED] wrote: On Oct 28, 2007, at 1:29 AM, mabshoff wrote: Hi Robert, For 2.8.10.alpha1+Craig's fix and python compiled using --without- pymalloc I get with the default cleanup level 1: ==6569== LEAK SUMMARY: ==6569==definitely lost: 181,030 bytes in 2,926 blocks. ==6569== possibly lost: 266,925 bytes in 747 blocks. ==6569==still reachable: 29,184,388 bytes in 179,707 blocks. ==6569== suppressed: 0 bytes in 0 blocks. With cleanup level 3 in general and cleanup level 1 just for integer.pyx I get ==23818== LEAK SUMMARY: ==23818==definitely lost: 181,117 bytes in 2,927 blocks. ==23818== possibly lost: 266,838 bytes in 746 blocks. ==23818==still reachable: 29,157,453 bytes in 179,383 blocks. ==23818== suppressed: 0 bytes in 0 blocks. With the patch valgrind says: ==3482== LEAK SUMMARY: ==3482==definitely lost: 181,235 bytes in 2,929 blocks. ==3482== possibly lost: 266,720 bytes in 744 blocks. ==3482==still reachable: 29,157,648 bytes in 179,395 blocks. ==3482== suppressed: 0 bytes in 0 blocks. So the number are slightly worst. So my conclusion is that you are on the right way with the cleanup code. What is our goal (i.e. what is a clean python run?) It's a bit better but it seems like we've barely made a dent in it--are the dictionaries we were looking at decrefing earlier still around? (They could be holding onto a lot of stuff.) Hopefully once we can compile integer.pyx with cleanup level 3 and not crash Try the below patch--this will prevent the double-free from the global dummy integer. There might be a better fix, as this will make it so that this integer object is never freed. with the patch everything compiles and runs fine with cleanup level 3. the amount of still reachable memory should decrease tremendously because integer.pyx should just about be referenced in every extension we have. It doesn't matter how many things reference integer.pyx, only how many things are referenced by integer.pyx (which isn't too much, but may include such things as element.pyx). Ok, but I plan to actually play with this using only a couple small modules independent of Sage in order to understand the problem better. The only valgrind complaint I get is the following: ==3482== Invalid free() / delete / delete[] ==3482==at 0x4A1B74A: free (vg_replace_malloc.c:320) ==3482==by 0x43FE9A: dict_dealloc (dictobject.c:847) ==3482==by 0x43FE9A: dict_dealloc (dictobject.c:847) ==3482==by 0x499E5B: _PyImport_Fini (import.c:229) ==3482==by 0x4A5D66: Py_Finalize (pythonrun.c:419) ==3482==by 0x4A58AA: handle_system_exit (pythonrun.c:1616) ==3482==by 0x4A5AA8: PyErr_PrintEx (pythonrun.c:1062) ==3482==by 0x4A62B6: PyRun_SimpleFileExFlags (pythonrun.c:976) ==3482==by 0x412319: Py_Main (main.c:134) ==3482==by 0x4FD94C9: (below main) (in /lib/libc-2.3.6.so) ==3482== Address 0xb2de9f8 is 32 bytes inside a block of size 80 alloc'd ==3482==at 0x4A1BB35: malloc (vg_replace_malloc.c:207) ==3482==by 0x4B0079: _PyObject_GC_Malloc (gcmodule.c:1321) ==3482==by 0x454C29: PyType_GenericAlloc (typeobject.c:454) ==3482==by 0x975D160: __pyx_tp_new_4sage_9structure_7element_Element (element.c:14429) ==3482==by 0xAC89AAA: __pyx_tp_new_4sage_5rings_7integer_Integer (integer.c:14228) ==3482==by 0x458D92: type_call (typeobject.c:422) ==3482==by 0x415542: PyObject_Call (abstract.c:1860) ==3482==by 0x47C480: PyEval_CallObjectWithKeywords (ceval.c:3433) ==3482==by 0xAC85823: initinteger (integer.c:15100) ==3482==by 0x49E17D: _PyImport_LoadDynamicModule (importdl.c:53) ==3482==by 0x49C08D: import_submodule (import.c:2394) ==3482==by 0x49C550: load_next (import.c:2214) It might be related. I also get a lot of the following: ==3482== 45 bytes in 1 blocks are definitely lost in loss record 525 of 10,255 ==3482==at 0x4A1BB35: malloc (vg_replace_malloc.c:207) ==3482==by 0x44D68B: PyString_FromString (stringobject.c:130) ==3482==by 0x13B4DF15: __Pyx_ImportType (real_double_vector.c: 3786) ==3482==by 0x13B52202: initreal_double_vector (real_double_vector.c:3255) ==3482==by 0x49E17D: _PyImport_LoadDynamicModule (importdl.c:53) ==3482==by 0x49C08D: import_submodule (import.c:2394) ==3482==by 0x49C550: load_next (import.c:2214) ==3482==by 0x49C7AD: import_module_level (import.c:2002) ==3482==by 0x49CBF4: PyImport_ImportModuleLevel (import.c:2066) ==3482==by 0x47BEE8: builtin___import__ (bltinmodule.c:47) ==3482==by 0x415542: PyObject_Call (abstract.c:1860) ==3482==by 0x47C480: PyEval_CallObjectWithKeywords (ceval.c:3433) - Robert Cheers, Michael no-collect-integer.patch 1KDownload --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email
[sage-devel] Re: potential cause for #557: cython missing dictionary deallocation
On Oct 28, 11:26 am, mabshoff [EMAIL PROTECTED] dortmund.de wrote: On Oct 28, 10:33 am, Robert Bradshaw [EMAIL PROTECTED] wrote: On Oct 28, 2007, at 2:17 AM, mabshoff wrote: Hi Robert, On Oct 28, 9:48 am, Robert Bradshaw [EMAIL PROTECTED] wrote: On Oct 28, 2007, at 1:29 AM, mabshoff wrote: Hi Robert, For 2.8.10.alpha1+Craig's fix and python compiled using --without- pymalloc I get with the default cleanup level 1: ==6569== LEAK SUMMARY: ==6569==definitely lost: 181,030 bytes in 2,926 blocks. ==6569== possibly lost: 266,925 bytes in 747 blocks. ==6569==still reachable: 29,184,388 bytes in 179,707 blocks. ==6569== suppressed: 0 bytes in 0 blocks. With cleanup level 3 in general and cleanup level 1 just for integer.pyx I get ==23818== LEAK SUMMARY: ==23818==definitely lost: 181,117 bytes in 2,927 blocks. ==23818== possibly lost: 266,838 bytes in 746 blocks. ==23818==still reachable: 29,157,453 bytes in 179,383 blocks. ==23818== suppressed: 0 bytes in 0 blocks. With the patch valgrind says: ==3482== LEAK SUMMARY: ==3482==definitely lost: 181,235 bytes in 2,929 blocks. ==3482== possibly lost: 266,720 bytes in 744 blocks. ==3482==still reachable: 29,157,648 bytes in 179,395 blocks. ==3482== suppressed: 0 bytes in 0 blocks. So the number are slightly worst. Hmm... strange. I wonder if the dummy integer was getting decrefed somewhere else. Also, how deterministic are these numbers? The amount of memory leaked can vary a little, but the number of blocks is usually constant. Hopefully once we can compile integer.pyx with cleanup level 3 and not crash Try the below patch--this will prevent the double-free from the global dummy integer. There might be a better fix, as this will make it so that this integer object is never freed. with the patch everything compiles and runs fine with cleanup level 3. Good, though it looks like not all issues are resolved (as seen below). Well, it is certainly a step by step process and we are making progress, so I am happy. the amount of still reachable memory should decrease tremendously because integer.pyx should just about be referenced in every extension we have. It doesn't matter how many things reference integer.pyx, only how many things are referenced by integer.pyx (which isn't too much, but may include such things as element.pyx). Ok, but I plan to actually play with this using only a couple small modules independent of Sage in order to understand the problem better. That sound like a good idea. Yep, all I now need is the time to actually do it. The only valgrind complaint I get is the following: ==3482== Invalid free() / delete / delete[] ==3482==at 0x4A1B74A: free (vg_replace_malloc.c:320) ==3482==by 0x43FE9A: dict_dealloc (dictobject.c:847) ==3482==by 0x43FE9A: dict_dealloc (dictobject.c:847) ==3482==by 0x499E5B: _PyImport_Fini (import.c:229) ==3482==by 0x4A5D66: Py_Finalize (pythonrun.c:419) ==3482==by 0x4A58AA: handle_system_exit (pythonrun.c:1616) ==3482==by 0x4A5AA8: PyErr_PrintEx (pythonrun.c:1062) ==3482==by 0x4A62B6: PyRun_SimpleFileExFlags (pythonrun.c:976) ==3482==by 0x412319: Py_Main (main.c:134) ==3482==by 0x4FD94C9: (below main) (in /lib/libc-2.3.6.so) ==3482== Address 0xb2de9f8 is 32 bytes inside a block of size 80 alloc'd ==3482==at 0x4A1BB35: malloc (vg_replace_malloc.c:207) ==3482==by 0x4B0079: _PyObject_GC_Malloc (gcmodule.c:1321) ==3482==by 0x454C29: PyType_GenericAlloc (typeobject.c:454) ==3482==by 0x975D160: __pyx_tp_new_4sage_9structure_7element_Element (element.c:14429) ==3482==by 0xAC89AAA: __pyx_tp_new_4sage_5rings_7integer_Integer (integer.c:14228) ==3482==by 0x458D92: type_call (typeobject.c:422) ==3482==by 0x415542: PyObject_Call (abstract.c:1860) ==3482==by 0x47C480: PyEval_CallObjectWithKeywords (ceval.c:3433) ==3482==by 0xAC85823: initinteger (integer.c:15100) ==3482==by 0x49E17D: _PyImport_LoadDynamicModule (importdl.c:53) ==3482==by 0x49C08D: import_submodule (import.c:2394) ==3482==by 0x49C550: load_next (import.c:2214) This looks like it has something to do with the very first integer created, though I'm not totally sure how to read the log. It might be related. I also get a lot of the following: ==3482== 45 bytes in 1 blocks are definitely lost in loss record 525 of 10,255 ==3482==at 0x4A1BB35: malloc (vg_replace_malloc.c:207) ==3482==by 0x44D68B: PyString_FromString (stringobject.c:130) ==3482==by 0x13B4DF15: __Pyx_ImportType (real_double_vector.c: 3786) ==3482==by 0x13B52202: initreal_double_vector (real_double_vector.c:3255) ==3482==by 0x49E17D: _PyImport_LoadDynamicModule
[sage-devel] Re: LiDIA
On Oct 29, 2:22 am, Bill Hart [EMAIL PROTECTED] wrote: On 28 Oct, 20:26, John Cremona [EMAIL PROTECTED] wrote: OK, so I wasn't trying to suggest that I was the first to have got as far but every little helps, and if Johannes remembers to ask Christoph then he may be sprred into action. As for physically GPL-ing the code, here's what I did for mwrank, where admittedly the source code was not split into so many dir- and subdirectories: I made a separate file containg the GPL info. I made sure that every source file had basic identification in line 1 only, followed by a coupld of blank lines; then a simple sed script inserted the GPL text into every file after line 1. Done! I thnk the same coud work with LiDIA source if combined with a find script to apply this to every .cc and .h file there is. That sounds good. The individual tar.gz files for Lidia are in my home directory on host-57-71 if you want to have a go. But in order to maintain the integrity of LiDIA it would be necessary to unpack each of the tar.gz files in turn and apply the script to the tree and rearchive. I'm not sure how svn can be used in a way that would keep each of the modules of LiDIA separate but still allow one to check out all of LiDIA in one go into a single directory tree. Do you know if cvs can do this? I would behappy to do that -- but with all of us including JB onto him, maybey CL will do it himself. Reading the LiDIA list it seems that Christoff has a few patches he's got to merge as well. But we can probably do quite a lot with just the GPL'ing done. Perhaps one of the things putting him off is that he has so many things that need to be done to get it all into shape. Either way, it sounds as if you (Bill) are the one with most LiDIA expertise on the Sage team by now! Ha ha! I've contributed precisely nothing to LiDIA. I contend that you are the only expert here John! Bill. FYI: [23:24] rpw I'll try to talk to christopher and JB about GPLing the LiDIA code tomorrow. [23:25] rpw I actuallys set up a subversion repo for LiDIA a couple of weeks ago. [23:25] mabshoff Jep, I figured you were the right guy to do that in person :) [23:25] rpw further details on sage-devel (ml) tomorrow morning. [23:25] mabshoff mk [23:25] rpw I'm to tired to type straight atm. I've been awake too long. [23:26] rpw see you guys in about 8 hours. So you might want to wait a day for rpw. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Announcement for Sage Bug Day 5: November 3rd, 10am PST
Hello folks, Bug Day 5 is now planned for Saturday, November 3rd, 2007. Official start will be 10am PST, but as usual people from European time zones or the east coast might start earlier and finish a little sooner. I you would like to participate add your name to the list at http://wiki.sagemath.org/bug5 - which also contains all the usual info. The plan is to do a 2.8.11 release the day before to be used as a basis for the Bug Day. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 2.8.10 is released
On Oct 29, 7:13 am, William Stein [EMAIL PROTECTED] wrote: On 10/28/07, Carl Witty [EMAIL PROTECTED] wrote: Sage 2.8.10 has been released. Download from http://sagemath.org/download.htmlor upgrade with sage -upgrade, as usual. This release includes updated spkg's prepared by Robert Bradshaw and Carl Witty, and patches created by Carl Witty, William Stein, Jaap Spies, Joel Mohler, Robert Miller, David Joyner, Mike Hansen, Jason Grout, Craig Citro, Nils Bruin, Robert Bradshaw, Martin Albrecht, and Michael Abshoff (listed in REVERSE alphabetical order, so that I get to be FIRST. Hah! Take that, Mr. Abshoff and Mr. Albrecht!) :) There is also a nice list of changes and tickets here: http://sagemath.org/announce/sage-2.8.10.txt This is also the second release that I did almost none of the work on, which is a great thing :-) Michael Abshoff will be the release manager for the next release (2.8.11), which is due out on Friday. Jep, more about that in a separate email soon. One more thing for the early adopters of OSX 10.5, aka Leopard: the binary build for 10.4 that ought to show up shortly will work fine in 32 bit mode, but so far the automated build on 10.5 itself fails. We plan to change that until 2.8.11. -- William Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Unhandled SIGSEGV: Ticket #973
I did look into this some more and I did verify that the refcounts wraps: lst [[0, 1, 2, 3, 4, 5, 6]] lst [[0], [1], [2], [3], [4], [5], [6]] lst [[0, 1], [0, 2], [1, 2], [0, 3], [1, 3], [2, 3], [0, 4], [1, 4], [2, 4], [3, 4], [0, 5], [1, 5], [2, 5], [3, 5], [4, 5], [0, 6], [1, 6], [2, 6], [3, 6], [4, 6], [5, 6]] lst [[0, 1, 2], [0, 1, 3], [0, 2, 3], [1, 2, 3], [0, 1, 4], [0, 2, 4], [1, 2, 4], [0, 3, 4], [1, 3, 4], [2, 3, 4], [0, 1, 5] , [0, 2, 5], [1, 2, 5], [0, 3, 5], [1, 3, 5], [2, 3, 5], [0, 4, 5], [1, 4, 5], [2, 4, 5], [3, 4, 5], [0, 1, 6], [0, 2, 6], [ 1, 2, 6], [0, 3, 6], [1, 3, 6], [2, 3, 6], [0, 4, 6], [1, 4, 6], [2, 4, 6], [3, 4, 6], [0, 5, 6], [1, 5, 6], [2, 5, 6], [3, 5, 6], [4, 5, 6]] lst [[refcnt -2147483582 at 0x97550ac, 1, 2, 3], [refcnt -2147483582 at 0x97550ac, 1, 2, 4], [refcnt -2147483582 at 0x9 7550ac, 1, 3, 4], [refcnt -2147483582 at 0x97550ac, 2, 3, 4], [1, 2, 3, 4], [refcnt -2147483582 at 0x97550ac, 1, 2, 5], [refcnt -2147483582 at 0x97550ac, 1, 3, 5], [refcnt -2147483582 at 0x97550ac, 2, 3, 5], [1, 2, 3, 5], [refcnt -2147483 582 at 0x97550ac, 1, 4, 5], [refcnt -2147483582 at 0x97550ac, 2, 4, 5], [1, 2, 4, 5], [refcnt -2147483582 at 0x97550ac, 3, 4, 5], [1, 3, 4, 5], [2, 3, 4, 5], [refcnt -2147483582 at 0x97550ac, 1, 2, 6], [refcnt -2147483582 at 0x97550ac, 1, 3, 6], [refcnt -2147483582 at 0x97550ac, 2, 3, 6], [1, 2, 3, 6], [refcnt -2147483582 at 0x97550ac, 1, 4, 6], [refcnt -2 147483582 at 0x97550ac, 2, 4, 6], [1, 2, 4, 6], [refcnt -2147483582 at 0x97550ac, 3, 4, 6], [1, 3, 4, 6], [2, 3, 4, 6], [ refcnt -2147483582 at 0x97550ac, 1, 5, 6], [refcnt -2147483582 at 0x97550ac, 2, 5, 6], [1, 2, 5, 6], [refcnt -214748358 2 at 0x97550ac, 3, 5, 6], [1, 3, 5, 6], [2, 3, 5, 6], [refcnt -2147483582 at 0x97550ac, 4, 5, 6], [1, 4, 5, 6], [2, 4, 5, 6], [3, 4, 5, 6]] lst [[refcnt -2147483447 at 0x97550ac, refcnt -2147483523 at 0x97550a0, 2, 3, 4], [refcnt -2147483447 at 0x97550ac, r efcnt -2147483523 at 0x97550a0, 2, 3, 5], [refcnt -2147483447 at 0x97550ac, refcnt -2147483523 at 0x97550a0, 2, 4, 5], [refcnt -2147483447 at 0x97550ac, refcnt -2147483523 at 0x97550a0, 3, 4, 5], [refcnt -2147483447 at 0x97550ac, 2, 3, 4 , 5], [refcnt -2147483523 at 0x97550a0, 2, 3, 4, 5], [refcnt -2147483447 at 0x97550ac, refcnt -2147483523 at 0x97550a0 , 2, 3, 6], [refcnt -2147483447 at 0x97550ac, refcnt -2147483523 at 0x97550a0, 2, 4, 6], [refcnt -2147483447 at 0x97550 ac, refcnt -2147483523 at 0x97550a0, 3, 4, 6], [refcnt -2147483447 at 0x97550ac, 2, 3, 4, 6], [refcnt -2147483523 at 0 x97550a0, 2, 3, 4, 6], [refcnt -2147483447 at 0x97550ac, refcnt -2147483523 at 0x97550a0, 2, 5, 6], [refcnt -214748344 7 at 0x97550ac, refcnt -2147483523 at 0x97550a0, 3, 5, 6], [refcnt -2147483447 at 0x97550ac, 2, 3, 5, 6], [refcnt -214 7483523 at 0x97550a0, 2, 3, 5, 6], [refcnt -2147483447 at 0x97550ac, refcnt -2147483523 at 0x97550a0, 4, 5, 6], [refcn t -2147483447 at 0x97550ac, 2, 4, 5, 6], [refcnt -2147483523 at 0x97550a0, 2, 4, 5, 6], [refcnt -2147483447 at 0x97550ac , 3, 4, 5, 6], [refcnt -2147483523 at 0x97550a0, 3, 4, 5, 6], [2, 3, 4, 5, 6]] The crash happens when the refcount for [0] goes up to zero. I now tend to blame Cython for this, so can somebody take a closer look at the code Cython generates for _choose. I would also conjecture that these kinds of refcounting issues cause a lot of the still reachable memory in a valgrind run. Carl Witty suggested to turn the refcount macros into functions that jump to a predefined function in case the refcount exceeds a certain threshold like 1,000 or even 1,000,000. That way we can search for those issues and hopefully eliminate them by setting a breakpoint on that predefined function. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: SAGE on Leopard
On Oct 30, 1:24 am, Justin Walker [EMAIL PROTECTED] wrote: Hi Justin, I figured I'd give this a try. The first to go is 'flint', with this error: g++ -single_module -fPIC -dynamiclib -o libflint.dylib mpn_extras.o Z.o memory-\ manager.o Z_mpn.o ZmodF.o ZmodF_mul.o ZmodF_mul-tuning.o fmpz.o fmpz_poly.o mpz\ _poly-tuning.o mpz_poly.o ZmodF_poly.o -lgmp ld: duplicate symbol ___gmpz_abs in Z.o and mpn_extras.o Any thoughts? That is a linker problem with external inline. See #1005 for the workarounds you need to get it working. I'm doing the old 'touch and go' builds to see what falls apart where. Justin Cheers, Michael -- Justin C. Walker, Curmudgeon-At-Large Institute for the Enhancement of the Director's Income Experience is what you get when you don't get what you want. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: SAGE on Leopard
On Oct 30, 3:34 am, Jason Martin [EMAIL PROTECTED] wrote: Has anyone tried a 64-bit build on Leopard? I just picked up Leopard today, so I'll hopefully have a running Leopard machine tomorrow on which to start playing. Just wondering if, for example, python can build in 64-bit mode on Leopard. --jason That is #1006, and as far as I know nobody has tried yet. We plan to get 32 bit working on 10.5 out of the box by Friday and then tackle the 64 bit build afterwards. If you start playing around please report your finding at ticket #1006. For some pointers on how to get python to build in 64 bit mode see http://mail.python.org/pipermail/pythonmac-sig/2007-June/019045.html To quote (which is actually about 64 bit on *Tiger*): quote The build is universal, but for me only one of the two archictures actually worked: I did my build on an Intel system and the 64-bit build worked on that machine, but didn't work on a G5 mac. That's probably something shallow, but as that machine doesn't have the Xcode installed and is on the other side of a slow network connection I haven't tried to debug this yet. 1) Edit the configure script, look for -arch i386 and -arch ppc and change that those to -arch ppc64 and -arch x86_64. You'll have to make multiple changes to the configure file. 2) Build using: $ mkdir build $ cd build $ CFLAGS=-arch ppc64 -arch x86_64 ../configure \ --enable-universalsdk \ --disable-toolbox-glue --prefix=/opt/python25-64bit $ make $ make install 3) Optionally: run make testall to run the unittests and check pyconfig.h to check the various SIZEOF definitions. You now have a 64-bit build of python in /opt/python25-64bit. /quote Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Integrating SymPy with SAGE
On Oct 30, 3:07 am, Ondrej Certik [EMAIL PROTECTED] wrote: We made a new release of SymPy with those _sage_() methods so that it can be integrated in SAGE more systematically. If some suggestions arise now, we'll simply change it and release again. Ondrej Hello Ondrej, just link the new spkg from ticket #971, I will start on the 2.8.11 release cycle late on Wednesday. Hopefully we can sort it all out by the release planned for this Friday. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Unhandled SIGSEGV: Ticket #973
On Oct 29, 10:03 pm, Jaap Spies [EMAIL PROTECTED] wrote: Hi Machael, Hi Jaap, You wrote: On Oct 29, 9:18 pm, Jaap Spies [EMAIL PROTECTED] wrote: Michael, Hello Jaap, Remembering that dance(10) has a segmentation fault long before there was a function _choose, is it possible that some other part of the code is going wild? Sure, but so far no lead. Which specific version did exhibit that behavior? I can build older releases locally and see if I can come up with anything. On 23 Oct I wrote: To day I got with sage-2.8.8.1: Well, I just looked at the patch where you introduced _choose and the lst you create is indentical. sage: time dance(10) Unhandled SIGSEGV: A segmentation fault occured in SAGE. This probably occured because a *compiled* component of SAGE has a bug in it (typically accessing invalid memory) or is not properly wrapped with _sig_on, _sig_off. You might want to run SAGE under gdb with 'sage -gdb' to debug this. SAGE will now terminate (sorry). Now that 2.8.10 with all your speed improvements is out I will do some more testing with that release on sage.math with a 32 bit binary to see if I can flush anything out with that. Warning: see the reopened trac #217, I stupid changed some Py_ssize_t in ints, but knowing the nrows and ncols are small, there will be no problem, I hope! Nope, I understand the argument to change it back, but the change shouldn't case any trouble. As I wrote above: The issues with the refcount going insane is a nice result from the debugging and that will hopefully lead to some improvements in our fight against memleaks. Thanks and good luck, Carl had some interesting input: [02:03] cwitty I was looking at those refcounts some more. [02:03] mabshoff ok [02:03] cwitty It turns out that Python caches and shares small int objects: [02:04] cwitty sage: a = int(0) [02:04] cwitty sage: sys.getrefcount(a) [02:04] cwitty 6288 [02:04] cwitty sage: b = int(0) [02:04] cwitty sage: sys.getrefcount(a) [02:04] cwitty 6289 [02:04] cwitty sage: a is b [02:04] cwitty True [02:04] mabshoff ok [02:04] cwitty So the reference-counting problem could be anywhere that deals with small Python ints. [02:05] mabshoff mmmh. [02:05] mabshoff So it is not the list [0], but the smallint 0 that has the reference counter overflow? [02:06] cwitty Let me go look at your printouts again. I thought so, but I didn't look closely. [02:06] cwitty Yeah, that's what it looks like to me. (Just judging from your next-to-latest e-mail.) [02:07] mabshoff Because the numbers jump, while I would expect them to increase by 1 each time. [02:11] cwitty So it looks like between your first and second printouts, the refcount for 0 jumped by 135, and the refcount for 1 jumped by at least 125 (to make it wrap). [02:11] mabshoff Yep, otherwise it would take *forever* to even wrap on a 32 bit box. So now comes the question: Why doesn't the refcount get decremented? How do we fix this? Jaap Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Py_ssize_t question
On Oct 31, 3:11 am, Carl Witty [EMAIL PROTECTED] wrote: On Oct 29, 10:11 am, Robert Bradshaw [EMAIL PROTECTED] wrote: Hello, There is another way that Py_ssize_t differs from int, namely that Cython casting happens via the __index__ rather than __int__ function. __int__ is potentially bad because it tries to hard to cast to an int (e.g. truncating, as happens with the python native types). Actually, this isn't true anymore. (It was true in Cython 0.9.6.7, but not in Cython 0.9.6.8.) The old code had: class CPySSizeTType(CIntType): ... from_py_function = __pyx_PyIndex_AsSsize_t And the new is: class CPySSizeTType(CIntType): ... from_py_function = PyInt_AsSsize_t which will cast using __int__ or __long__. If you decide to change it back, you should also fix the definition: #define __pyx_PyIndex_AsSsize_t(b) PyInt_AsSsize_t(PyNumber_Index(b)) to decref the return value of PyNumber_Index. it should also be noted that the bug Carl mention above seems to be the root cause for #973. I am currently updating to 2.8.10 on my local box (which shows the segfault for dance(10)) to see if the problem is really fixed. I added some additional info to #973 about this. Carl Witty Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Unhandled SIGSEGV: Ticket #973
Robert Bradshaw wrote: Hi Robert, I had an error like this and it turned out to be caused by a GC error. Specifically, an object A was allocated, then erroneously deallocated (but there was still stuff pointing to it). Object B was then allocated, with memory overlapping that of object A. Object A was then modified, and that modified the refcount field of object B. That might be a variant of what's going on here. I tracked it down by using gdb's watch command on the object with the weird ref count... - Robert As it turned out it was a bug in 2.8.9's Cython [and probably at least some of the earlier versions] which Carl tracked down after I isolated the cause: [02:30] mabshoff Ok, every time c=0 the refcount for int(0) goes up by one. [02:42] cwitty It's a Cython bug. [02:42] mabshoff Yep, for c in cols: [02:42] mabshoff increments the refcount on int(?) [02:42] cwitty I've been having a hard time debugging it because the bug doesn't occur any more in the current Cython (so it's gone in 2.8.10). [02:43] mabshoff Ok, let me upgrade and see if the problem goes away. [02:44] mabshoff Got any more technical details? [02:45] cwitty In 2.8.9's version of Cython, converting a Python object (like the int objects we're dealing with) to a Py_Ssize_t goes via this line of code: [02:45] cwitty #define __pyx_PyIndex_AsSsize_t(b) PyInt_AsSsize_t(PyNumber_Index(b)) [02:46] cwitty PyNumber_Index(b) returns a new object (although in this case it's actually the exact same int object), with its refcount incremented. [02:46] mabshoff Ok, that makes sense. [02:46] cwitty So the caller of PyNumber_Index() is supposed to decref the return value at some point. With 2.8.10 the refcount of int(0) doesn't increase by invoking dance(m) any more: sage: a=int(0) sage: sys.getrefcount(a) 5304 sage: dance(5) h^5 - 5*h^4 + 25*h^3 - 55*h^2 + 80*h - 46 sage: sys.getrefcount(a) 5304 sage: dance(6) h^6 - 9*h^5 + 60*h^4 - 225*h^3 + 555*h^2 - 774*h + 484 sage: sys.getrefcount(a) 5304 It used to be that sys.getrefcount(a) would end up around 48,000 after dance(5), so now I consider this issues closed. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] optional spkgs that should be pushed into the repo
Hello, there are two optional spkg in trac against 2.8.11. I cannot up them myself, so I would like William to get those into the optional spkg repo. Those two are: #705[with spkg] Make vtk an easy-to-install optional sage package #1033 [with optional spkg] biopython 1.44 optional package Both ticket have links to the new optional spkgs, so if you care please build them against a current release and report back success and failures. Mike Hansen also has optional R and rpy spkgs, so maybe Mike can post links to those two via a comment to #839write pexpect interface to R William: Any objections against either one of those and also Mike's spkgs once they are ready? Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: policy on new trac tickets
On Oct 31, 1:50 pm, Ondrej Certik [EMAIL PROTECTED] wrote: Hi, Hello Ondrej, when I have one particular feature to discuss, should I discuss it here, or open a new trac ticket for that? Something this controversial should be discussed here first. Either way you should get a trac account via William, it can't hurt to have one :) I am going to discuss it here for now: summary: infer the name of the spkg package from config file (instead of the name of the dir) Currently, when creating a package using ./sage -pkg some_dir will create a package some_dir which is inconvenient, because the some_dir is held in a hg repository, whose dir doesn't change. Also, all information about creating the package should be included in the hg repository. I suggest creating a file, changelog, that will hold the latest version. And also it will contain the info from SPKG.txt (this fill will could be removed then). Why not to do it the same as in Debian? Example of a Debian changelog: libmesh (0.6.1.dfsg-1~oc3) UNRELEASED; urgency=low [Ondrej Certik] * New upstream version * Ondrej Certik added to Uploaders. TODO before the package can be uploaded to Debian: * check lintian/linda * check that libmesh-pure works as expected * remove the -j4 flags in make in debian/rules -- Ondrej Certik [EMAIL PROTECTED] Sun, 28 Oct 2007 17:45:28 +0100 libmesh (0.6.0~rc2.dfsg-3) unstable; urgency=low [Ondrej Certik] * Built against libpetsc2.3.3, which is now in Debian (Closes: #435532) [ Christophe Prud'homme ] * debian/control: modified maintainer and uploader fields -- Christophe Prud'homme [EMAIL PROTECTED] Mon, 03 Sep 2007 22:11:32 +0200 The building scripts in Debian parse the first line, and get the version information from that (in Debian it's a little more complicated, since there are source and binary packages, the names of which are read from the debian/control file). In SAGE, most of the things are not needed, so I suggest this syntax: sympy (0.5.6-2) [Ondrej Certik] * get-orig-sources added sympy (0.5.6-1) [Ondrej Certik] * New upstream version * file .hgignore added sympy (0.5.5-1) * New upstream version ... and spkg -pkg will parse the first line (and only the first line), and get the name of the package and version from that. The -1, -2 are SAGE revisions of the package - when you change something in the building of the package, but the upstream version doesn't change, so that it's reflected in the version. We use .p1, .p2 and so on for that so far, but your suggestion works just as fine. Ondrej I would recommend you wait for some reactions until the east west coast crowd gets up; Then you should write a Sage Enhancement Proposal and even better implement a prototype of your idea so people can play around with it. If it breaks backward compability it would be a harder sell, but it might be something to target for Sage 3.0 which should happen in the not so distant future, i.e. roughly the start of 2008. That said I like you ideas and suggestions. It should be possible to add hash values for consistency which is something Pablo has been working on (see #329), so you might want to talk to him about how this can be combined. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Py_ssize_t question
On Oct 31, 9:55 pm, Jaap Spies [EMAIL PROTECTED] wrote: Hi Michael, it should also be noted that the bug Carl mention above seems to be the root cause for #973. I am currently updating to 2.8.10 on my local box (which shows the segfault for dance(10)) to see if the problem is really fixed. I added some additional info to #973 about this. Hello Jaap, Seems to be fixed in sage-2.8.10! It is, but I forgot to mention it in the other thread. The ticket has been closed, but it would be great if you could submit the cleanup patch for #217 in the next 36 hours. But it taught me about a new class of refcounting bugs, so I don't consider the colossal amount of time I spend tracking this issue down wasted :) William had also suggested that you can merge dance() into the official Sage distribution. Carl and I also talked about writing a doctest for Cython to catch this kind of error should it ever pop up again. sage: time dance(10) h^10 - 35*h^9 + 675*h^8 - 8610*h^7 + 78435*h^6 - 523467*h^5 + 2562525*h^4 - 9008160*h^3 + 21623220*h^2 - 31840760*h + 21750840 CPU times: user 13256.06 s, sys: 56.28 s, total: 13312.34 s Wall time: 13606.78 Jaap Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] 2.8.11.alpha0 released
I have released 2.8.11.alpha0 at http://sage.math.washington.edu/home/mabshoff/sage-2.8.11.alpha0.tar It passes testall on sage.math, but I would like to get some build feedback on OSX 10.4, both PPC and Intel flavors, as well as 32 bit Linux. I plan to release 2.8.11 final by late Friday night (PST). Overall it is a rather conservative release because that build will be the basis for Sage Bug Day 5. The following tickets have been closed: #217: optimize matrix permanents (Jaap Spies) #762: Elliptic curve L-series bug (William Stein) #830: SAGE does not install 'gphelp' for extended PARI/GP help (Carl Witty) #948: very slow factorization over a numberfield in a 2-variable ring (Martin Albrecht, Hannes Schönemann) #959: errors building sage because singular gets confused by system- wide boost (Martin Albrecht) #969: cvxopt miscompiled on OSX ppc (Josh Kantor, fixes by Michael Abshoff) #971: update Sympy.spkg to 0.5.6, add some minimal doctests (Carl Witty, Ondrej Certik) #973: Unhandled SIGSEGV: A segmentation fault occured running dance(10) (Michael Abshoff, Carl Witty) #993: Pari's gp interpreter has built-in library search path (Carl Witty) #1011: MagmaElement.__nonzero__ (Martin Albrecht) #1026: memleak in linbox's gmp++_int_io.C (Michael Abshoff) #1030: MPolynomial_libsingular mutates with call to factor (Joel Mohler) #1033: updated optional spkg: biopython 1.44 (Mike Hansen, fixes by William Stein, Michael Abshoff) #1034: clean up 'revlex' term ordering mess (Martin Albrecht) #1037: arithmetic with Schubert polynomials (Mike Hansen) #1039: Dokchitser L-series of number field (Jennifer S. Balakrishnan, referred by William Stein) #1044: segfault apply morphism to field element (Carl Witty) #1045: add eulerian testing and circuit-finding (Jason Grout, referred by Robert Miller) #1049: graphs: transitive reduction function (Jason Grout, referred by Robert Miller) Will very likely get merged: #845: needs magma guru to look at Needs more feedback/discussion: #705: William wrote an EMail to Josh with suggestions after we had a look at it. Since this is an optional spkg its upload is not tied to the release of 2.8.11 #787: This ought be be resolved soon, but might be Bug Day 5 material #980: needs more discussion, unlikely to get merged in 2.8.11 #1032: needs more discussion, unlikely to get merged in 2.8.11 If you have any more patches please make sure they apply cleanly against this alpha release. As far as I know I have looked at all patches available in trac, if I overlooked one please let me know. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] 2.8.11.rc1 released
I have released 2.8.11.rc1 (sorry, I skipped rc0, by the time I realized the problem I had already called it rc1 in trac) at http://sage.math.washington.edu/home/mabshoff/sage-2.8.11.rc1.tar It passes testall on sage.math, but I would like to get some build feedback on OSX 10.4, both PPC and Intel flavors, as well as 32 bit Linux. I plan to release 2.8.11 final by late Friday night (PST). Overall it is a rather conservative release because that build will be the basis for Sage Bug Day 5. William and I are working on full 32 bit OSX 10.5 support which will be rc2 hopefully. This release will still fail to build on OpenSuSE 10.2 with their gcc. We have one doctest failure due to #750, so somebody with expertise please tell us what to do: ./sage -t devel/sage-main/sage/groups/perm_gps/permgroup_element.py sage -t devel/sage-main/sage/groups/perm_gps/permgroup_element.py ** File permgroup_element.py, line 323: sage: g([0,1,2,3,4]) Expected: [1, 2, 3, 0, 5, 4] Got: [1, 2, 0, 4, 3] ** 1 items had failures: 1 of 7 in __main__.example_7 ***Test Failed*** 1 failures. For whitespace errors, see the file .doctest_permgroup_element.py [3.0 s] exit code: 256 -- The following tests failed: sage -t devel/sage-main/sage/groups/perm_gps/ permgroup_element.py Total time for all tests: 3.0 seconds The following tickets have been closed (alpha0 and rc1 combined): #217: optimize matrix permanents (Jaap Spies) #431: dsage jobs get lost by server (Yi Qiang, fixed by an earlier patch) #750: permutation group element (dict method, acting on lists) (Tom Boothby) #762: Elliptic curve L-series bug (William Stein) #830: SAGE does not install 'gphelp' for extended PARI/GP help (Carl Witty) #845: can't pass boolean as parameter to Magma (Martin Albrecht) #948: very slow factorization over a numberfield in a 2-variable ring (Martin Albrecht, Hannes Schönemann) #959: errors building sage because singular gets confused by system- wide boost (Martin Albrecht) #969: cvxopt miscompiled on OSX ppc (Josh Kantor, fixes by Michael Abshoff) #971: update Sympy.spkg to 0.5.6, add some minimal doctests (Carl Witty, Ondrej Certik) #973: Unhandled SIGSEGV: A segmentation fault occured running dance(10) (Michael Abshoff, Carl Witty) #993: Pari's gp interpreter has built-in library search path (Carl Witty) #1011: MagmaElement.__nonzero__ (Martin Albrecht) #1026: memleak in linbox's gmp++_int_io.C (Michael Abshoff) #1030: MPolynomial_libsingular mutates with call to factor (Joel Mohler) #1033: updated optional spkg: biopython 1.44 (Mike Hansen, fixes by William Stein, Michael Abshoff) #1034: clean up 'revlex' term ordering mess (Martin Albrecht) #1037: arithmetic with Schubert polynomials (Mike Hansen) #1039: Dokchitser L-series of number field (Jennifer S. Balakrishnan, referred by William Stein) #1044: segfault apply morphism to field element (Carl Witty) #1045: add eulerian testing and circuit-finding (Jason Grout, referred by Robert Miller) #1049: graphs: transitive reduction function (Jason Grout, referred by Robert Miller) #1053: updated Cython to the 0.9.6.8b release (Robert Bradshaw) #1056: Fix Givaro 3.2.6 build problem on MacOS X 10.5 (Ralf-Philipp Weinmann, integrated by Michael Abshoff) #1059: fix lcalc installation on OSX 10.5 (William Stein, integrated by Michael Abshoff) #1051: pari/gp extended help stops working when sage tree is moved (Carl Witty) #1060: fix flintqs compile on OSX 10.5 (William Stein, integrated by Michael Abshoff) #1061: updated python spkg on 10.5 (William Stein) #1063: sage -sh should run $SHELL with Sage environment variables set (Carl Witty) Needs more feedback/discussion: #705: William wrote an EMail to Josh with suggestions after we had a look at it. Since this is an optional spkg its upload is not tied to the release of 2.8.11 #787: This ought be be resolved soon, but might be Bug Day 5 material #980: needs more discussion, unlikely to get merged in 2.8.11 #1032: Latex'ing variable names is more robust and consistent (Joel Mohler) - this one was actually backed out again - see the ticket for comment If you have any more patches please make sure they apply cleanly against this rc release. As far as I know I have looked at all patches available in trac, if I overlooked one please let me know. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Announcement for Sage Bug Day 5: November 3rd, 10am PST
On Oct 29, 6:13 am, mabshoff [EMAIL PROTECTED] dortmund.de wrote: Hello folks, BugDay5 is now planned for Saturday, November 3rd, 2007. Official start will be 10am PST, but as usual people from European time zones or the east coast might start earlier and finish a little sooner. I you would like to participate add your name to the list athttp://wiki.sagemath.org/bug5- which also contains all the usual info. The plan is to do a 2.8.11 release thedaybefore to be used as a basis for theBugDay. Cheers, Michael Hello, this is just a reminder that BD5 will happen in about 36 hours. If plan to participate and you haven't added yourself to the Wiki page linked above please do so. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: 2.8.11.rc1 released
On Nov 2, 5:29 am, [EMAIL PROTECTED] wrote: Hello boothby, The expected output is incorrect; the actual output is correct. Okay, I am fixing the doctest then. We are planning an rc2 in a couple hours if William and I get it to compile on 10.5 without the need for manual interaction. We are getting very close; If you like to help out drop by in #sage-devel. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: 2.8.11.rc1 released
On Nov 2, 12:45 pm, Joel B. Mohler [EMAIL PROTECTED] wrote:
On Friday 02 November 2007 00:17, mabshoff wrote:
#1032: Latex'ing variable names is more robust and consistent (Joel
Mohler) - this one was actually backed out again - see the ticket for
comment
It's possible that I'm totally screwing up my branches on my personal machine,
but I don't think so. In actual fact the comment on the ticket refers to one
of the behaviors I was trying to fix!
Exhibit A (vanilla 2.8.10):
--
| SAGE Version 2.8.10, Release Date: 2007-10-28 |
| Type notebook() for the GUI, and license() for information.|
--
sage: P.alpha12=ZZ[]
sage: latex(P)
\mathbf{Z}[\text{alpha12}]
Exhibit B (my patched version):
--
| SAGE Version 2.8.10, Release Date: 2007-10-28 |
| Type notebook() for the GUI, and license() for information.|
--
Loading SAGE library. Current Mercurial branch is: latex
sage: P.alpha12=ZZ[]
sage: latex(P)
\mathbf{Z}[\alpha_{12}]
Hi Joel,
mabshoff: Are you sure you ran doc-tests with the *patched* version of sage?
Because that doc-test wasn't even in the vanilla version.
Everything is possible, but I am fairly sure that the behavior of the
doctests only changes if the patch made it in. Can you check that your
patch applied against rc1 passes doctests? I will apply it provided
the patch doesn't get shot by William.
Cheers,
Michael
--
Joel
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: libPng.dylib
On Nov 2, 6:33 pm, William Stein [EMAIL PROTECTED] wrote: On Fri, 02 Nov 2007 10:26:13 -0700, Justin C. Walker [EMAIL PROTECTED] wrote: Well, it also hits us on Linux, so I still think it should happen. malb's problem with firefox is just one example where that happened and he just fixed it in that special case, but not as clean and general as I would like. This may be a hack, but it is an ingrained piece of behavior in Unix- like systems. The issue is part and parcel of the sage-env command's existence: you want to set up the proper environment in which SAGE can function, and you do this by modifying the default environment that the shell user normally sees. Therefore, if you support the ! functionality (back to the default shell, in essence), it seems to me that it behooves you to re-establish that environment. Perhaps the right way to do this is to invoke a login shell; I'm not sure though. An alternative would be to save/restore those shell variables that SAGE sets (keeping in mind that if SAGE sets one that isn't set, it ought to be unset). You are of course right. However, doing what we're discussing will also break some things too. E.g., sage: !gap # or anything else included in sage boom since now the environments aren't right to run anything included in sage. sage: !lie boom sage: !mwrank boom So there are pros and cons to this suggested fix, which have to be carefully considered. I think you misread one point I made: In case of !app we check if app is in $SAGE_LOCAL/bin. In that case we don't do anything about [DY]LD_LIBRARY_PATH and since it is the Sage version of app it should work as always. Otherwise, i.e. app is not in $SAGE_LOCAL/bin, we are calling something not shipped with Sage we use the old version of [DY]LD_LIBRARY_PATH and avoid that the linker picks the wrong version of certain libraries shipped with Sage. In the above case, if we also unset the changes we made to the PATH, then as long as the user do install_scripts(...), they will still be able to run gap (since that will call sage -gap). Cheers, Michael William -- William Stein Associate Professor of Mathematics University of Washingtonhttp://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: 2.8.11.rc1 released
A short outlook: People on OpenSuSE 10.2 should know the following: [09:33] Syzygy- Hmph. I cannot get yast to tell me what the g77- package is named. *grmbl* [09:33] mabshoff Which SuSE release? [09:34] mabshoff You should probably install gfortran [09:34] mabshoff 10.3 no longer ships g77 or g95, but gfortran. [09:34] Syzygy- OpenSuSE 10.2 [09:34] Syzygy- Right. [09:35] mabshoff Really? There is a bug in that gcc that crashes when compiling gen.c [09:35] mabshoff Does Sage start and compute 2+2? [09:35] Syzygy- Yes. [09:35] mabshoff ok, but then you probably update via yast. [09:35] Syzygy- gcc version 4.1.2 20061115 (prerelease) (SUSE Linux) [09:36] mabshoff Thanks [09:36] mabshoff Excellent, you just closed ticket #908. [09:37] Syzygy- Hehe [09:37] Syzygy- Happy to help. :) You need to run yast to update to the latest gcc for 10.2 to make the compilation issue go away. That closes #908 for me, but William might still try to fix it, nonetheless. For the OSX 10.5 people: rc1 + the spkgs from http://sage.math.washington.edu/tmp/leopard/ + SAGE_FORTRAN=`which gfortran` + an installed gfotran yields a working build from source. In that case there are two doctest failures: sage -t devel/sage-main/sage/libs/pari/gen.pyx python(22824) malloc: *** mmap(size=409600) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug sage -t devel/sage-main/sage/combinat/sfa.py sh: line 1: 99646 Segmentation fault /Users/mabshoff/ sage-2.8.11.rc1/local/bin/python .doctest_sfa.py .doctest/out 2 .doctest/err A mysterious error (perphaps a memory error?) occurred, which may have crashed doctest. This one works with -verbose and -gdb We have leads on both of them, but if you have a patch let us know. The plan for rc2, due in about 12 hours are: - #1057 apply and back out #1044? - #389 by cwitty - Leopard compatible spkgs - to investigate: patches by robert from the #557 thread. - fix doctest failure introduced by #750 once people agree what is the right result ;) I am asleep for now, so cu you guys in IRC in about 8 hours. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: numpy vs. in-place optimizations
On Nov 2, 8:25 pm, William Stein [EMAIL PROTECTED] wrote: On 11/2/07, Carl Witty [EMAIL PROTECTED] wrote: On Nov 2, 11:25 am, Robert Bradshaw [EMAIL PROTECTED] wrote: :-(, but I have to concede to your logic. The line to change is 148 of coerce.pxi. Setting this value to 0 will turn them completely off. Other than numpy, (and the builtin libraries), do we use any other extension types? If there is a finite list of things for which it won't work, it would be possible to disable it just for those. Another possibility is to figure out where in Sage it's safe to use and particularly helpful, and explicitly enable it for those sections of code. And another possibility, which restores the in-place optimization to (some) Cython code but not Python code, is to change Cython so that if it knows the things it's adding/multiplying/etc. are of subtypes of sage.structure.element.Element, then it bypasses PyNumber_Add and calls a method on the objects directly. This method could use the in- place optimization. (Plus, we might gain a tiny bit of speed by skipping PyNumber_Add anyway.) +1 to both of these ideas. -- William For now I have applied the following patch: # HG changeset patch # User Robert Bradshaw # Date 1194031602 25200 # Node ID d235183a07ac596bb10db446be4a0e64a3a66a4c # Parent 71f280c221ca1677e4452b685d584eba49f822a1 turn off in-place optimizations, see #1038 diff -r 71f280c221ca -r d235183a07ac sage/structure/coerce.pxi --- a/sage/structure/coerce.pxi Thu Nov 01 21:03:52 2007 -0700 +++ b/sage/structure/coerce.pxi Fri Nov 02 12:26:42 2007 -0700 @@ -145,7 +145,7 @@ cdef inline RingElement _idiv_c(RingElem cdef enum: # 3 references: handle, scope container, and arithmatic call stack -inplace_threshold = 3 +inplace_threshold = 0 Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: 2.8.11.rc1 released
On Nov 2, 7:39 pm, Joel B. Mohler [EMAIL PROTECTED] wrote: On Friday 02 November 2007 10:45, mabshoff wrote: On Nov 2, 12:45 pm, Joel B. Mohler [EMAIL PROTECTED] wrote: Everything is possible, but I am fairly sure that the behavior of the doctests only changes if the patch made it in. Can you check that your patch applied against rc1 passes doctests? I will apply it provided the patch doesn't get shot by William. Hello Joel, The patch applied against rc1 passes with flying colors. You need to use the second bundle on the ticket since the first bundle is already in (but backed out). Maybe there is a correct way to back out the back out, but I don't know it. I applied the second version of the patch and everything seems to work as expected now. I believe that I might have merged against the wrong parent, so sorry for my screwup. -- Joel Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: 2.8.11.rc1 released
On Nov 3, 12:46 am, Joel B. Mohler [EMAIL PROTECTED] wrote: On Friday 02 November 2007 15:38, mabshoff wrote: The patch applied against rc1 passes with flying colors. You need to use the second bundle on the ticket since the first bundle is already in (but backed out). Maybe there is a correct way to back out the back out, but I don't know it. I applied the second version of the patch and everything seems to work as expected now. I believe that I might have merged against the wrong parent, so sorry for my screwup. Thanks a bunch for squeezing it in at the last minute. I'm glad we got it figured out! Well, since it seems to have been my fault: thanks ;) Anyway, my planned short absence turned into a 3 hours nap, but rc has been released at http://sage.math.washington.edu/home/mabshoff/sage-2.8.11.rc2.tar Since I was literally asleep William has taken over and the 2.8.11 release will be rc2 plus tachyon and matplotplib from http://sage.math.washington.edu/tmp/leopard/ There are no functional changes in those two spkgs, just bumped version numbers to force a rebuild due to an updated libpng. -- Joel Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Sage 2.8.11 Release Announcement
[One last minute note: If you are on OSX 10.4 please read the OSX 10.4 build instructions] Sage 2.8.11: Release team: Michael Abshoff (chair), William Stein, Carl Witty While there were many bug fixes, performance improvements and features added the main goal of this release was to get Sage building out of the box in 32 bit mode on OSX 10.5. We didn't make it 100% to the finish line, but more about that below. The main participants in the port were William Stein, Ralf-Philipp Weinmann and Michael Abshoff. If you plan to participate in Sage Bug Day 5 you should build this release since it will be the base we build upon. This release contains patches and updated spkgs from (in ascending order of ticket number): * Jaap Spies * Carl Witty * Tom Boothby * William Stein * Martin Albrecht * Josh Kantor * Ondrej Certik * Michael Abshoff * Joel Mohler * Mike Hansen * Jennifer S. Balakrishnan * Jason Grout * Robert Bradshaw * Ralf-Philipp Weinmann The following 33 tickets have been closed during the 2.8.11 release cycle: #217: optimize matrix permanents (Jaap Spies) #389: bug in mpfi C library (Carl Witty) #431: dsage jobs get lost by server (Yi Qiang, fixed by an earlier patch) #750: permutation group element (dict method, acting on lists) (Tom Boothby) #762: Elliptic curve L-series bug (William Stein) #830: SAGE does not install 'gphelp' for extended PARI/GP help (Carl Witty) #845: can't pass boolean as parameter to Magma (Martin Albrecht) #948: very slow factorization over a numberfield in a 2-variable ring (Martin Albrecht, Hannes Schönemann) #959: errors building sage because singular gets confused by system- wide boost (Martin Albrecht) #969: cvxopt miscompiled on OSX ppc (Josh Kantor, fixes by Michael Abshoff) #971: update Sympy.spkg to 0.5.6, add some minimal doctests (Carl Witty, Ondrej Certik) #973: Unhandled SIGSEGV: A segmentation fault occured running dance(10 (Michael Abshoff, Carl Witty) #993: Pari's gp interpreter has built-in library search path (Carl Witty) #1011: MagmaElement.__nonzero__ (Martin Albrecht) #1026: memleak in linbox's gmp++_int_io.C (Michael Abshoff) #1030: MPolynomial_libsingular mutates with call to factor (Joel Mohler) #1032: Latex'ing variable names is more robust and consistent (Joel Mohler) #1033: updated optional spkg: biopython 1.44 (Mike Hansen, fixes by William Stein, Michael Abshoff) #1034: clean up 'revlex' term ordering mess (Martin Albrecht) #1037: arithmetic with Schubert polynomials (Mike Hansen) #1038: bad interaction between numpy and in-place operations (Robert Bradshaw) #1039: Dokchitser L-series of number field (Jennifer S. Balakrishnan, referred by William Stein) #1044: segfault apply morphism to field element (Carl Witty) #1045: add eulerian testing and circuit-finding (Jason Grout, referred by Robert Miller) #1049: graphs: transitive reduction function (Jason Grout, referred by Robert Miller) #1053: updated Cython to the 0.9.6.8b release (Robert Bradshaw) #1056: Fix Givaro 3.2.6 build problem on MacOS X 10.5 (Ralf-Philipp Weinmann, integrated by Michael Abshoff) #1059: fix lcalc installation on OSX 10.5 (William Stein, integrated by Michael Abshoff) #1051: pari/gp extended help stops working when sage tree is moved (Carl Witty) #1057: Order elements do not have Z as a (proper) basering (Robert Bradshaw) #1060: fix flintqs compile on OSX 10.5 (William Stein, integrated by Michael Abshoff) #1061: updated python spkg on 10.5 (William Stein) #1063: sage -sh should run $SHELL with Sage environment variables set (Carl Witty) Build instruction for OSX 10.4 It seems that a workaround introduced for OSX 10.5 causes a compile failure in LinBox. So if you are on OSX please try installing the following Givaro.spkg: http://sage.math.washington.edu/home/mabshoff/givaro-3.2.6.p2.spkg William is off for now, so I assume that we will take care of this officially tomorrow during BD5. If that Givaro.spkg doesn't fix the problem please let me know. I am only releasing now because this is the Bug Day 5 base build. Build instruction for OSX 10.5 Install gfortran (from source now, there are no known binaries we are aware of) and export SAGE_FORTRAN=`which gfortran`. Then the build will work. There is one more doctest to fix and I am certain that this will be done quickly. If you do not install gfortran Sage will use the prebuilt g95 which will fail to compile scipy on 10.5. Please report any issues you encounter. Apologies to anybody I might have forgotten. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: 10.5 issue?
On Nov 4, 5:05 am, William Stein [EMAIL PROTECTED] wrote: Hello, not at all for me. - William rpw tried building Sage on 10.5 with MACOSX_DEPLOYMENT_TARGET set to 10.4 so that we can build one binary that runs on both 10.4 and 10.5, but he got some error message that indicates that maybe the line below was at fault (something about configure and python disagreeing about the MACOSX_DEPLOYMENT_TARGET). So I would suggest that we leave MACOSX_DEPLOYMENT_TARGET alone if it is actually set. Cheers, Michael (Sent from my iPhone.) On Nov 3, 2007, at 8:26 PM, Robert Bradshaw [EMAIL PROTECTED] wrote: Did this cause an issue with building SAGE on 10.5? Begin forwarded message: From: Jim McCoy [EMAIL PROTECTED] Date: November 3, 2007 5:15:48 PM PDT To: Robert Bradshaw [EMAIL PROTECTED] Subject: Re: [Pyrex] Cython 0.9.6.8 released In Cython/Mac/DarwinSystem.py the line: os.environ[MACOSX_DEPLOYMENT_TARGET] = 10.3 causes the OS-supplied version of Python on Leopard to choke. It wants 10.5 in this position. Jim --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Sage 2.8.12.alpha1 and release plan
Hello folks, you can find 2.8.12.alpha1 at http://sage.math.washington.edu/home/mabshoff/sage-2.8.12.alpha1.tar alpha1 is the result of the bug fixes merged by William during Bug Day 5 as well as two minor spkg updates. There is currently onc doctest failure in schemes/elliptic_curves/ lseries_ell.py see #1103 for details. My plan now is to put an rc1 together in the next 24 hours, I am currently looking through open trac tickets against 2.8.12 to see what I would like to merge. I will post a list with candidates here later on tonight to get some feedback. The release should happen either Tuesday or Wednesday, because I will be leaving for Sage Day 6 very early on Friday morning. Hence there are few chances of experimental/ untested code slipping in at this point, but I am sure we will start another release cycle during the coding sprint part of Sage Days 6. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: dense F_p matrix multiplication
On Nov 5, 2:10 pm, William Stein [EMAIL PROTECTED] wrote: On 11/5/07, Martin Albrecht [EMAIL PROTECTED] wrote: Hello, I've got a naive question: Why isn't linbox the default choice for matrix multiplication over F_p? (1) It was probably broken when we first wrapped matrix multiply with linbox. :) (2) Timings of linbox vary drastically depending on available BLAS. Maybe your timings are better below on your machine, but they could be much worse on another machine. Whereas the builtin sage implementation doesn't depend as much. malb, are you using the gslblas or ATLAS? (3) Memory leaks in linbox could make doing the multiply there undesirable. ffpack is free of memory leaks last time I checked. If not I will fix them :) In other words, it could be time to switch to linbox if (1) the answers are right and it doesn't crash, (2) the timings are fairly uniformly better, and (3) memory leaks aren't a problem. I think this is something we should look into next week during the coding sprint. My plan is to work on ATLAS integration, so this should come up. sage: A = random_matrix(GF(127),2000,2000) sage: B = random_matrix(GF(127),2000,2000) sage: %time C = A._multiply_linbox(B) CPU times: user 4.15 s, sys: 0.00 s, total: 4.15 s Wall time: 4.19 sage: %time D = A*B CPU times: user 11.65 s, sys: 0.01 s, total: 11.67 s Wall time: 11.75 sage: C == D True Btw. MAGMA is still faster: sage: AM = A._magma_(); BM = B._magma_() sage: time magma.eval(C:=%s*%s%(AM.name(),BM.name())) CPU times: user 0.00 s, sys: 0.00 s, total: 0.00 s Wall time: 1.68 '' I guess there is a certain overhead for LinBox, i.e. getting the matrix from Sage into LinBox and reconverting the result. We should measure that just to eliminate this benchmarketing-wise. Martin Cheers, Michael -- name: Martin Albrecht _pgp:http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _www:http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] -- William Stein Associate Professor of Mathematics University of Washingtonhttp://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: dense F_p matrix multiplication
On Nov 5, 3:01 pm, William Stein [EMAIL PROTECTED] wrote: On 11/5/07, Martin Albrecht [EMAIL PROTECTED] wrote: Hi, this is probably due to the faster BLAS implementation on my notebook (and the standard GSL on your's). So we could remember which BLAS we use and default to LinBox if we have a fast BLAS (OSX, ATLAS, Goto). The current plan with Sage is to switch to including ATLAS standard with Sage. Then the Sage will always have a fast BLAS. A year ago that would be crazy talk, but building ATLAS has very *massively* improved during the last year, so this is now quite reasonable. And ATLAS also offers multi threaded BLAS Level 3 operations which could be used by ffpack for matrix-matrix multiplies depending on the algorithm used. The optional ATLAS.spkg is single threaded, but I am working on add optional support to build ATLAS multi threaded. Problem is that it takes roughly number of cores times to build since it tunes itself for 1 to number of cores each. I am trying on sage.math later on today to see if there is any benefit/how large matrices have to become before we see an improvement. I did some benchmarking with LinBox's rationalSolver and multi threaded BLAS (ATLAS, Goto as well as Intel) did run slower than single threaded, mostly due to the fact that the rational solver uses BLAS Level 2 mostly, which is usually slower when multi threaded (due to the higher overhead of setup of operations) Cheers, Michael -- william --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: dense F_p matrix multiplication
On Nov 5, 3:12 pm, John Cremona [EMAIL PROTECTED] wrote: It would be nice if it were documented somewhere how big the optional packages are (e.g. file sizes displayed athttp://www.sagemath.org/packages/optional/) ...waiting for atlas to download... and now seeing the error message sage: An error occurred while installing atlas-3.7.38 Please email sage-develhttp://groups.google.com/group/sage-devel explaining the problem and send the relevant part of of /home/jec/sage-2.8.10/install.log. Describe your computer, operating system, etc. If you want to try to fix the problem, yourself *don't* just cd to /home/jec/sage-2.8.10/spkg/build/atlas-3.7.38 and type 'make'. Instead (using bash) type source local/bin/sage-env from the directory /home/jec/sage-2.8.10 in order to set all environment variables correctly, then cd to /home/jec/sage-2.8.10/spkg/build/atlas-3.7.38 The problem seems to be no fortran compiler, so I'm now installing gfortran. Yep, that should fix it. ATLAS builds an f77 wrapper, that can be turned off. Last time I tried (3.7.38 or so) that was broken and resulted in an aborted compilation, so for now you need some fortran compiler in $PATH. The plan is to use sage_fortran in the future to compile that f77 wrapper, I haven't found time to teach ATLAS's build system to do so. As mentioned earlier ATLAS integration will be my project during the coding sprint at SD6, so hopefully we will have ATLAS as default in the 2.9 release. Hence: optioanl packages should also tell of any new dependencies! John SNIP Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: dense F_p matrix multiplication
Hi John, On Nov 5, 3:45 pm, John Cremona [EMAIL PROTECTED] wrote: After installing Atlas (took 20 minutes) it runs more slowly! sage: sage: %time C = A._multiply_linbox(B) CPU times: user 72.32 s, sys: 1.02 s, total: 73.34 s Wall time: 80.09 On sage.math time drops from 11.86s to 10.83, but the 2000x2000 case isn't really the interesting one yet in my opinion. I am benchmarking some larger cases right now. For those small fields ATLAS can use float precision instead of double internally, so that should speed up the computation roughly by a factor of 2, but that is BLAS dependent. (was 72 s wall time). John Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: dense F_p matrix multiplication
On Nov 5, 3:57 pm, William Stein [EMAIL PROTECTED] wrote: On 11/5/07, John Cremona [EMAIL PROTECTED] wrote: After installing Atlas (took 20 minutes) it runs more slowly! No, it will run at exactly the same speed. You also have to rebuild linbox in such a way that it actually takes advantage of ATLAS. Right now, your linbox install is probalby built to use frickin' slow GSL. Oh, Michael will have just written the same thing but better as I write this... Ignore my last email, I forgot to rebuild LinBox. I am surprised how much timings vary I get from running matrix matrix multiplies, especially since sage.math is not loaded. Do the following to get it to work: $ source local/bin/sage-env $ export SAGE_BLAS=$SAGE_LOCAL $ ./sage -f spkg/standard/linbox-20070915.p1.spkg Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: dense F_p matrix multiplication
On Nov 5, 5:24 pm, William Stein [EMAIL PROTECTED] wrote: On 11/5/07, mabshoff [EMAIL PROTECTED] wrote: Ignore my last email, I forgot to rebuild LinBox. I am surprised how much timings vary I get from running matrix matrix multiplies, especially since sage.math is not loaded. Do the following to get it to work: $ source local/bin/sage-env $ export SAGE_BLAS=$SAGE_LOCAL $ ./sage -f spkg/standard/linbox-20070915.p1.spkg Arrrg, I am an idiot! Please do export LINBOX_BLAS=$SAGE_LOCAL/lib and it should work. Maybe somebody like me ought to document this somewhere in the wiki :) That's why optional packages should be completely trivial to install. This should *not* be documented in the wiki. What should happen is that the atlas package installs easily, or gives a clear reason why the install fails and what somebody must do to remedy the problem. Of course, in this case the best thing will be to have atlas become a standard package. Actually, it is export SAGE_BLAS=$SAGE_LOCAL/lib Third time's the charm ;) I agree that ATLAS should be standard, but LinBox by itself should be smart enough to figure out that ATLAS is there in the first place. Anyway: After running benchmarks for a couple hours and recompiling linbox a couple times I am now convinced that the way we use LinBox now we do not even utilize the specialized BLAS interface: Here are two examples from the LinBox's test suite linked against ATLAS: [EMAIL PROTECTED] tests]$ nm test-ffpack | grep ATL | wc -l 454 [EMAIL PROTECTED] tests]$ nm test-zero-one | grep ATL | wc -l 0 The ATL are the ATLAS symbols, in case of ffpack we end up actually using BLAS, in zero-one we do not. Now we look at liblinboxwrap.so.0.0.0 linked against a LinBox build with ATLAS: [EMAIL PROTECTED]:/tmp/Work-mabshoff/sage-2.8.11$ ldd local/lib/ liblinboxwrap.so.0.0.0 libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x2aef1f669000) libm.so.6 = /lib/libm.so.6 (0x2aef1f868000) libc.so.6 = /lib/libc.so.6 (0x2aef1f9ea000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x2aef1fc27000) /lib64/ld-linux-x86-64.so.2 (0x4000) There is no dynamic BLAS linked against liblinboxwrap.so.0.0.0, but also: [EMAIL PROTECTED]:/tmp/Work-mabshoff/sage-2.8.11$ nm local/lib/ liblinboxwrap.so.0.0.0 | grep ATL | wc -l 0 [Even if we linked dynamically against ATLAS there would be ATL symbols referenced in liblinboxwrap] So, I am convinved that it doesn't matter which BLAS we linked in case of the current liblinboxwrap because we do not seem to wrap the specialized types in LinBox that take advantage of ffpack and then in turn of BLAS. The advantage of LinBox over the generic matrix matrix multiply seems to be algorithmic only at the moment. I would actually suggest of wrapping the interesting bits of ffpack directly without the LinBox overhead. ffpack comes with LinBox, so it is there anyway. But I have to get some work done and also want to put rc1 together tonight, so I do not have time to investigate this now. If anybody with deeper knowledge of liblinboxwrap wants to dig into this feel free to do so, there are plenty of other issues for me to play with. william Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: dense F_p matrix multiplication
On Nov 5, 6:04 pm, John Cremona [EMAIL PROTECTED] wrote: Maybe I'll give up on this for a bit since after setting all those environment variables and redoing I get (stuff) gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING using frickin' slow GSL C-blas WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING (stuff) which suggest that it will not speed up at all! Either way the BLAS used doesn't matter. We just need it to satisfy the linker, no actual static or dynamic library actually ends up getting used. Just compared the size and linked libraries of William's plain LinBox with cblas vs. my optimized with ATLAS: [EMAIL PROTECTED]:/tmp/Work-mabshoff/sage-2.8.11$ ls -al /home/was/s/local/ lib/liblinboxwrap.so.0.0.0 -rwxr-xr-x 1 was was 10584961 2007-11-02 20:39 /home/was/s/local/lib/ liblinboxwrap.so.0.0.0 [EMAIL PROTECTED]:/tmp/Work-mabshoff/sage-2.8.11$ ls -al local/lib/ liblinboxwrap.so.0.0.0 -rwxr-xr-x 1 mabshoff 1090 10585769 2007-11-05 08:33 local/lib/ liblinboxwrap.so.0.0.0 [EMAIL PROTECTED]:/tmp/Work-mabshoff/sage-2.8.11$ ldd /home/was/s/local/ lib/liblinboxwrap.so.0.0.0 libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x2b6959fc3000) libm.so.6 = /lib/libm.so.6 (0x2b695a1c2000) libc.so.6 = /lib/libc.so.6 (0x2b695a344000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x2b695a581000) /lib64/ld-linux-x86-64.so.2 (0x4000) [EMAIL PROTECTED]:/tmp/Work-mabshoff/sage-2.8.11$ ldd local/lib/ liblinboxwrap.so.0.0.0 libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x2b09457eb000) libm.so.6 = /lib/libm.so.6 (0x2b09459ea000) libc.so.6 = /lib/libc.so.6 (0x2b0945b6c000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x2b0945da9000) /lib64/ld-linux-x86-64.so.2 (0x4000) John SNIP We should ask Clement during SD6 on which classes to wrap to get the speedup with BLAS. John: Thanks for the grep -c tip. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: MACOSX_DEPLOYMENT_TARGET (binaries working on both OSX 10.4 and 10.5)
On Nov 5, 10:51 pm, Ralf-Philipp Weinmann [EMAIL PROTECTED] darmstadt.de wrote: Hello list, Hello Ralf, I've finished building and testing SAGE 2.8.11 (on ppc) MACOSX_DEPLOYMENT_TARGET=10.3 This causes a build produced on OSX 10.5 to _almost_ work on 10.4. The culprit that forces me to use the almost in the above sentence is maxima, which has been linked against the system libiconv of 10.5 and wants *at least this version* libiconv of which only an older version is present on 10.4). I've temporarily worked around this issue by installing libiconv through MacPorts and setting DYLD_LIBRARY_PATH accordingly (to /opt/local/lib in my case. DYLD_LIBRARY_PATH is the equivalent to LD_LIBRARY_PATH on other Unices). A make check then causes the test cases (bar one, see below) to successfully finish. The 10.4 SDK (usually) installed in /Developer/SDKs/MacOSX10.4u.sdk on 10.5 systems with XCode 3 contains the appropriate (older) library, but I haven't had enough time to figure out whether we can have maxima link against the old library or whether we need to ship libiconv with SAGE to get a build that works flawlessly on both platforms. I tend to prefer the latter option at the moment. * All my tests so far have shown that devel/sage-main/sage/combinat/ sfa.py fails with a SIGSEGV (both on ppc and Intel, both on 10.5 and 10.4). Is this a known problem? I haven't been able to find any ticket about this in the TRAC. We knew about it, but it didn't have its own ticket. It is #1108 now. Cheers, Ralf Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 2.8.12.alpha1 and release plan
Since William just asked me here an update: real work kept me busy all day, now I am merging patches. The plan is: If you have any objects please let me know now! Will go in #683, #989: Stripping $ from documentation #995: Generalize polynomial .roots() method by adding optional ring= parameter for result ring #1055: Don't factor discriminant for quadratic number fields #1079: DSage improper get_worker_count #1081: update the deps file #1084: invalid use of ring notation gives bizarre post-preparser syntax error (needs #1040 first) #1087: add combinatorics documentation to the reference manual (needs some touching of files) #1095: silly annoyance in sage -coverage (applies to local/bin) #1196: real_roots may give wrong answers on non-squarefree polynomials #1098: make rpy work with SAGE data types #1100: polynomial roots() method can return rational roots for polynomials over ZZ (needs #995 first) #1105: static memory leak in libSingular interface #1109: gp interface raises stack overflow exception if gp stack exceeds available memory #1112: Integer.__pow__ Needs reviews: #1071: IntegerVectors_nk: which patch should I apply? #1075: sync'ing hashes for fraction fields and rings: jbmoehler has raised some doubt himself, so I will err on the side of caution and wait for some review. Won't merge: #787: quotient spaces of vector spaces - to quote wstein: This has lingered too long -- I need to deal with it. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: [sage-support] sage-2.8.12 build report
On Nov 7, 8:08 pm, William Stein [EMAIL PROTECTED] wrote: This should really be sent to sage-devel, so I'm forwarding it there. -- Forwarded message -- From: William Stein [EMAIL PROTECTED] Date: Nov 7, 2007 11:07 AM Subject: Re: [sage-support] sage-2.8.12 build report To: [EMAIL PROTECTED] On Nov 7, 2007 11:02 AM, Kate Minola [EMAIL PROTECTED] wrote: I go away for a while, and now SAGE does not build on any of my machines of interest: Compiling from source using gcc-4.2.2, I get *** x86-Linux, ia64-Linux *** While compiling cvxopt-0.8.2.p4, I get gcc -pthread -shared build/temp.linux-i686-2.5/C/base.o build/temp.linux-i686-2.5/C/dense.o build/temp.linux-i686-2.5/C/sparse.o -L/home/kate/sage/sage-2.8.12-x86-Linux/local/lib -L/home/kate/sage/sage-2.8.12-x86-Linux/local/lib/gcc-lib/i686-pc-linux-gnu/4.0.3 -lm -llapack -lblas -lf95 -o build/lib.linux-i686-2.5/cvxopt/base.so /usr/local/binutils-2.17/x86-Linux-gcc-4.1.1/bin/ld: cannot find -lf95 That's because you're using gfortran. Evidently Josh's fix for cvxopt not fully working fails for people using gfortran. I'll open a trac ticket: http://trac.sagemath.org/sage_trac/ticket/1125 *** x86_64-Linux *** While compiling libfplll-2.1-20071024, I get g++ -shared -nostdlib /usr/lib/../lib64/crti.o /usr/local/gcc-4.2.2/x86_64-Linux/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/crtbeginS.o .libs/fplll.o -Wl,--rpath -Wl,/usr/local/gcc-4.2.2/x86_64-Linux/lib/../lib64 -Wl,--rpath -Wl,/usr/local/gcc-4.2.2/x86_64-Linux/lib/../lib64 -lmpfr -lgmp -L/usr/local/gcc-4.2.2/x86_64-Linux/lib/gcc/x86_64-unknown-linux-gnu/4.2.2 -L/usr/local/gcc-4.2.2/x86_64-Linux/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/home/kate/sage/sage-2.8.12-x86_64-Linux/local/lib -L/usr/local/gcc-4.2.2/x86_64-Linux/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/../../.. /usr/local/gcc-4.2.2/x86_64-Linux/lib/../lib64/libstdc++.so -lm -lc -lgcc_s /usr/local/gcc-4.2.2/x86_64-Linux/lib/gcc/x86_64-unknown-linux-gnu/4.2.2/crtendS.o /usr/lib/../lib64/crtn.o -Wl,-soname -Wl,libfplll.so.0 -o .libs/libfplll.so.0.0.0 /usr/bin/ld: /usr/lib/../lib64/libmpfr.a(exceptions.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib/../lib64/libmpfr.a: could not read symbols: Bad value Why is Sage trying to use libmpfr.a out of /usr/lib? Should it not be using the version in [sage]/local/lib? I agree. Note that libfpll is a brand new package in Sage (it does very fast LLL reduction, so is quite important), but it hasn't been as widely tested as other components of Sage. This is now trac #1126: Kate, could you try http://sage.math.washington.edu/home/mabshoff/libfplll-2.1-20071024.p0.spkg and report back it that solves the issue? Cheers, Michael http://trac.sagemath.org/sage_trac/ticket/1126 I've made both trac tickets blockers. We'll fix them at Sage Days next week. William -- William Stein Associate Professor of Mathematics University of Washingtonhttp://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: [sage-support] sage-2.8.12 build report
On Nov 8, 3:59 pm, Kate [EMAIL PROTECTED] wrote: Michael, Hello Kate, I have tried http://sage.math.washington.edu/home/mabshoff/libfplll-2.1-20071024.p... and can report that it builds on my x86_64-Linux box. Great. I will make sure the updated spkg goes into 2.9 or whatever the next release will be. The build is now stuck at the cvxopt-0.8.2.p4 spot (same error) that I reported for x86-Linux and ia64-Linux. Josh did update the cvxopt.spkg (see above in the thread). The latest is at http://sage.math.washington.edu/home/jkantor/spkgs/cvxopt-0.8.2.p5.spkg It should now handle gfortran and g95 without problems. Please report back if that solves your problem. Kate SNIP Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: [sage-support] sage-2.8.12 build report
On Nov 8, 9:50 pm, Kate [EMAIL PROTECTED] wrote: Michael, SNIP sage -t devel/sage-main/sage/numerical/test.py ** File test.py, line 4: : from cvxopt.base import * Exception raised: Traceback (most recent call last): File /home/kate/sage/sage-2.8.12-ia64-Linux/local/lib/python2.5/ doctest.py, line 1212, in __run compileflags, 1) in test.globs File doctest __main__.example_0[0], line 1, in module from cvxopt.base import *###line 4: : from cvxopt.base import * ImportError: /usr/lib/libblas.so.3: undefined symbol: e_wsfe ** Sorry to reply to myself so quickly: here we are pulling in the local blas and not the one we compiled with Sage. So that should be easily fixable. Note to self: Need more sleep. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: [sage-support] sage-2.8.12 build report
On Nov 8, 9:50 pm, Kate [EMAIL PROTECTED] wrote: Michael, Kate, Much thanks for the link to Josh's update of cvxopt.spkg. No problem. With that fix, I now can compile on all the architectures I am currently interested in: x86-Linux, x86_64-Linux, and ia64-Linux. The next step is to run 'make check', which I have done. Sadly, only x86-Linux passes all the tests. *** x86_64-Linux *** sage -t devel/sage-main/sage/rings/real_rqdf.pyx ** File real_rqdf.pyx, line 12: sage: RQDF( 123.2) + RR (1.0) Expected: 124.2000 Got: NaN ** File real_rqdf.pyx, line 14: sage: RQDF( 12.2) + RDF (0.56) Expected: 12.76 Got: nan ** File real_rqdf.pyx, line 16: sage: RQDF( 12.2) + (9) Expected: 21.19928945726423989981412887573242187500 Got: NaN ** and then others with a similar message: Got NaN or Got nan mmmh, any chance some other package pulls in the libmpfr that caused trouble with libfplll? Could you gzip the build log and post it somewhere and send us a link? *** ia64-Linux *** The following tests failed: sage -t devel/sage-main/sage/lfunctions/lcalc.py sage -t devel/sage-main/sage/numerical/test.py sage -t devel/sage-main/sage/rings/polynomial/ polynomial_element.pyx sage -t devel/sage-main/sage/lfunctions/lcalc.py ** File lcalc.py, line 188: sage: E.Lseries().values_along_line(0.5, 3, 5) Expected: lcalc: 1.5 0 WARNING- we don't have enough Dirichlet coefficients. lcalc: Will use the maximum possible, though the output will not necessarily be accurate. lcalc: nan nan [(0, 0.209951303), (0.5, -2...e-16), (1., 0.133768433), (2., 0.552975867)] Got: lcalc: 1.5 0 WARNING- we don't have enough Dirichlet coefficients. lcalc: Will use the maximum possible, though the output will not necessarily be accurate. lcalc: nan nan [(0, 0.209951303), (0.5, -3.16949699e-16), (1., 0.133768433), (2., 0.552975867)] ** Mhh, not sure about this one yet. sage -t devel/sage-main/sage/numerical/test.py ** File test.py, line 4: : from cvxopt.base import * Exception raised: Traceback (most recent call last): File /home/kate/sage/sage-2.8.12-ia64-Linux/local/lib/python2.5/ doctest.py, line 1212, in __run compileflags, 1) in test.globs File doctest __main__.example_0[0], line 1, in module from cvxopt.base import *###line 4: : from cvxopt.base import * ImportError: /usr/lib/libblas.so.3: undefined symbol: e_wsfe ** Josh - any idea about this one? sage -t devel/sage-main/sage/rings/polynomial/ polynomial_element.pyx** File polynomial_element.pyx, line 2314: sage: f.roots(ring=CC) Expected: [(1.00, 1), (-0.500 + 0.866025403784438*I, 1), (-0.500 - 0.866025403784438*I, 1)] Got: [(1.00, 1), (-0.500 + 0.866025403784439*I, 1), (-0.500 - 0.866025403784439*I, 1)] ** File polynomial_element.pyx, line 2749: sage: (x^3 - 1).complex_roots() Expected: [1.00, -0.500 + 0.866025403784438*I, -0.500 - 0.866025403784438*I] Got: [1.00, -0.500 + 0.866025403784439*I, -0.500 - 0.866025403784439*I] ** Ok, these are only minor precision issues, that we can easily fix in the next release. Kate Any volunteers to open trac tickets for these? I have to leave for the airport in 5 hours and would like to catch some sleep. I am also working on another release candidate for ApCoCoA - G, work sucks. SNIP Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: number_field_element coercion
On Nov 8, 10:46 pm, John Voight [EMAIL PROTECTED] wrote:
Hello all,
Hi John,
Check this out:
sage: def stupid_function(n):
: Z_F = NumberField(x^2-x-1, 't').maximal_order()
: for i in range(n):
: Z_F([5,1])
:
sage: prun stupid_function(10^4)
Ordered by: internal time
ncalls tottime percall cumtime percall
filename:lineno(function)
31.5270.0002.2990.000
polynomial_element_generic.py:520(__init__)
81.0110.0001.1890.000 rational_field.py:
120(__call__)
10.9930.0007.0560.001 number_field.py:
1086(_coerce_non_number_field_element_in)
40.9740.0001.4620.000 free_module.py:
494(__call__)
480.9590.0000.9590.000 {isinstance}
4/30.8590.0003.7470.000 polynomial_ring.py:
167(__call__)
10.5140.0002.4770.000 free_module.py:
3078(echelon_coordinates)
20.5110.0001.7670.000 {method
'linear_combination_of_rows' of 'sage.matrix.matrix0.Matrix' objects}
40.4430.0001.9800.000 free_module.py:
2804(__call__)
10.4280.0001.1980.000 maps.py:52(__call__)
10.3340.0000.7700.000
polynomial_element_generic.py:873(list)
40.3260.0000.5230.000
polynomial_element_generic.py:783(degree)
10.3170.000 12.5640.001 order.py:703(__call__)
10.2140.0003.3120.000 free_module.py:
3393(echelon_coordinate_vector)
10.2040.0003.7770.000 free_module.py:
579(__contains__)
20.1920.0000.5800.000
polynomial_element_generic.py:586(__getitem__)
100.1820.0000.1820.000 {method 'parent' of
'sage.structure.element.Element' objects}
10.1670.0000.1960.000 {method '_coefficients'
of
'sage.rings.number_field.number_field_element_quadratic.NumberFieldElement_quadratic'
objects}
20.1630.0007.2960.000 number_field.py:
1004(__call__)
30.1460.0000.1460.000 {method 'list' of
'sage.modules.free_module_element.FreeModuleElement' objects}
10.1440.0000.7420.000
polynomial_element_generic.py:726(_mul_)
40.1380.0000.1380.000 {method 'Polrev' of
'sage.libs.pari.gen.gen' objects}
50.1310.0000.1310.000 free_module.py:
820(degree)
40.1150.0000.1150.000 {method 'poldegree' of
'sage.libs.pari.gen.gen' objects}
30.1140.0000.1750.000 singular.py:
1131(is_SingularElement)
60.1030.0000.1030.000
{sage.structure.element.is_Element}
30.0930.0000.0930.000 {hasattr}
10.0870.0000.1730.000 free_module.py:
154(FreeModule)
40.0830.0000.0830.000 {max}
50.0830.0000.0830.000 {method 'base_ring' of
'sage.structure.parent_base.ParentWithBase' objects}
Woah! Can someone explain to me the various calls above? I'd think
this should take epsilon time to coerce the elements of the sequence.
Or perhaps is there another better way to coerce into Z_F (or,
equivalently for me, F)?
There is without a doubt something fishy going on with coercion. See
also malb's report with polynomial rings at
http://www.sagetrac.org/sage_trac/ticket/1046
Thanks!
Yours,
John Voight
Cheers,
Michael
Assistant Professor of Mathematics
University of Vermont
[EMAIL PROTECTED]
[EMAIL PROTECTED]://www.cems.uvm.edu/~voight/
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: [sage-support] sage-2.8.12 build report
On Nov 9, 3:14 am, Joshua Kantor [EMAIL PROTECTED] wrote: Hi Josh, Yeah. the missing symbol is because its linking against libblas in / usr/lib, which was compiled with some other probably older fortran (why oh why can't all the fortrans get along). I'm curious about what people think is a good solution here. If they have a libblas in /usr/lib thats broken like this (it requires special additional libraries but we can't deduce that at compile time) We are guaranteed a BLAS in $SAGE_LOCAL/lib because we compile it ourselves. So just add -L $SAGE_LOCAL/lib to the flags at the right point and the problem is gone. then as far as I know, the only way to avoid linking against their blas is to change the name of our blas library i.e. libsage_blas and link against that. Or do something like set LD_LIBRARY_PATH=$SAGE_LOCAL (but thats not a good way to solve the problem). Nope, I agree that this is not a solution. And we do add $SAGE_LOCAL/ lib to LD_LIBRARY_PATH which causes the problem in the first place. Thoughts? :) Off to the airport Josh Michael On Nov 8, 1:11 pm, mabshoff [EMAIL PROTECTED] dortmund.de wrote: On Nov 8, 9:50 pm, Kate [EMAIL PROTECTED] wrote: Michael, SNIP sage -t devel/sage-main/sage/numerical/test.py ** File test.py, line 4: : from cvxopt.base import * Exception raised: Traceback (most recent call last): File /home/kate/sage/sage-2.8.12-ia64-Linux/local/lib/python2.5/ doctest.py, line 1212, in __run compileflags, 1) in test.globs File doctest __main__.example_0[0], line 1, in module from cvxopt.base import *###line 4: : from cvxopt.base import * ImportError: /usr/lib/libblas.so.3: undefined symbol: e_wsfe ** Sorry to reply to myself so quickly: here we are pulling in the local blas and not the one we compiled with Sage. So that should be easily fixable. Note to self: Need more sleep. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] 2.8.13 and 2.9 release plans
Greeting from Sage Days 6 in Bristol, after a short discussion we would like to make the following release plans: - 2.8.13 on Nov. 18th, 2007 which should be another small bugfix and feature release. - 2.9 on Nov. 25th, 2007 with hopefully ATLAS support and potential 64 bit OSX support as well as Solaris 9 in 32 bit mode. Also on the table is an upgrade to LinBox 1.1.4, but that depends on the result from the coding sprint during Sage Days 6. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: gdb, doctests, strange behavior...
On Nov 12, 9:20 am, William Stein [EMAIL PROTECTED] wrote: On Mon, 12 Nov 2007 06:47:06 -, Robert Miller [EMAIL PROTECTED] wrote: (1) Do you or do you not actually have the same problem when you build the same code under Linux? You don't say above. Hello, I hadn't had the chance to try yet, but I have now. I can't get it to give any error in linux at all. All the tests pass, in and out of gdb mode. I tried several times. If you want to send me a patch/bundle against 2.8.12 or so and instructions on how to reproduce this and I will take a look. Turns out I was testing the wrong branch. I can reproduce the problem in linux, and here I actually get a useful-ish backtrace, since gdb ^^ I just want to make the general observation that developing Sage only on OSX is not a very sensible thing to do, just as you just noted. E.g., the valgrind tool exists only in Linux, That should change in the near future. and is potentially very useful. So OS X users (like I am this month :-) ), really should at least install Linux too and use it for subtle debuging issues. So you're definitely doing the right thing. Mastering more than one OS is a must in my book ;) has enough information. The relevant line in my .pyx file is a simple sage_free call. It looks like an array overflow problem or something. I guess this is all good news, since it seems as if gdb in os x 10.5 could get me this information too if the build had finished. I have seen the issue with gdb printing loads of output at startup of sage, but I didn't know that it also happened on 10.4 also. I might have a look on either how to get around this or actually solve the problem. Cheers, Michael SNIP -- William Stein Associate Professor of Mathematics University of Washingtonhttp://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: plotQt.c with Qt 4.3.2 + GUI for pari/gp
On Nov 13, 12:41 pm, David Joyner [EMAIL PROTECTED] wrote: On 11/13/07, Fabio Tonti [EMAIL PROTECTED] wrote: The original Webpage says [mathGUIde] ist Freeware und wird mit allen Quellen verbreitet which means that it's freeware and is distributed with all the sources. So it doesn't state any licensing details e.g. whether you may modify the source etc. Maybe I should download it and look into the sourcefiles? There could be some hidden licensing information. Please do. I did and didn't find anything. But everything is in German, so my search wasn't very useful if there is some information in with other things. Might be worth emailing Ring. If it is opensource then perhaps it could be adapted to be used as a windows SAGE gui interface? Hello, I have to agree with Martin on this. I see little advantage in shipping a Qt application with Sage, especially since Qt4 static or dynamic adds easily 10 mb compressed. I have also written similar code (also qt 4.2.3 based) that has the added capability to wrap just about any open source math system text interface and run an arbitrary number of sessions in parallel. That code base is actively maintained (fact is I get paid to do so) and will be release to the public under the GPL in December or so. But: There isn't a reason to optionally have this interface, but the default supported mode of Sage on Windows is the browser interface. There are plenty of open tickets to improve that interface, and a single 1.0.0 release 1.5 years ago doesn't exactly give a lot of confidence. I would be glad if Ring would add a Sage mode and start to improve the software, but that has to happen on his end unless somebody here will step up and help out. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: plotQt.c with Qt 4.3.2 + GUI for pari/gp
On Nov 13, 6:08 pm, mhampton [EMAIL PROTECTED] wrote: To really compete with programs like mathematica or matlab, I think sage needs to be able to have interactive applet-like interfaces (e.g. like mathematica's Manipulate). It seems possible and probably most desirable to do this with the notebook and javascript, but to me at least javascript seems clunky and difficult. A cross-platform GUI toolkit like Qt seems like an interesting alternative but I can't see how it would work over the notebook - i.e. it seems like the interfaces would have to be written server-side and compiled and run client-side. If it worked well, it would be worth a larger download in my opinion. Yep, I have discussed this with William in the past and something like what you envision would certainly start its live as an optional download first. Re the interface: You would have to redirect stin, stdout stderr (and maybe have the sage text application emit some sort of signal like done with my computation), and in case you plot something you need to write that to a file locally and read it from the client. There is certainly demand for this kind of application and we could share the load by developing this with CoCoA, Singular, Pari, GAP and so on. Cheers, Michael Marshall On Nov 13, 9:46 am, Ondrej Certik [EMAIL PROTECTED] wrote: Hello, I have to agree with Martin on this. I see little advantage in shipping a Qt application with Sage, especially since Qt4 static or dynamic adds easily 10 mb compressed. I have also written similar code (also qt 4.2.3 based) that has the added capability to wrap just about any open source math system text interface and run an arbitrary number of sessions in parallel. That code base is actively maintained (fact is I get paid to do so) and will be release to the public under the GPL in December or so. But: There isn't a reason to optionally have this interface, but the default supported mode of Sage on Windows is the browser interface. There are plenty of open tickets to improve that interface, and a single 1.0.0 release 1.5 years ago doesn't exactly give a lot of confidence. I would be glad if Ring would add a Sage mode and start to improve the software, but that has to happen on his end unless somebody here will step up and help out. I also think only the notebook interface should be the default. Just one way of doing things and doing it well. Everything else optional. Ondrej --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: 2.8.13 and 2.9 release plans
On Nov 10, 11:47 pm, mabshoff [EMAIL PROTECTED] dortmund.de wrote: Greeting from Sage Days 6 in Bristol, after a short discussion we would like to make the following release plans: -2.8.13on Nov. 18th, 2007 which should be another small bugfix and feature release. - 2.9 on Nov. 25th, 2007 with hopefully ATLAS support and potential 64 bit OSX support as well as Solaris 9 in 32 bit mode. Also on the table is an upgrade to LinBox 1.1.4, but that depends on the result from the coding sprint during Sage Days 6. Cheers, Michael Hello, I did forget to mention that I will be playing release manager the next two releases (and maybe more to come). Here at Sage Day 6 we did discuss some more procedure on what is needed for a patch/spkg to make it into a release: - somebody besides the patch/spkg author/authors needs to review the patch and comment on it in trac. - Only unanimously positive commented on patches will be merged, if there is a dissenting opinion the issue should be raised in sage- devel. - if we cannot agree on the resolution of a patch it is put up for a vote via the JSage panel. The exact procedure for that was discussed during Sage Days 5 and somebody ought to write down the rules - If you post a spkg you should describe the changes and only attach one spkg per ticket (because we may only merge one ticket [Josh did open a ticket with three new spkgs and in the future that shouldn't happen - but leave this as is for now since it looks like all three spkgs will be merged] - trivial fixes (think all the spelling fixes Paul posted the last week alone, thank you for that again) will be merged without the need to comment. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Error building sage in Solaris 10 with gcc 4.0.2
On Nov 14, 3:59 pm, David Joyner [EMAIL PROTECTED] wrote: Klas: Thanks for your report but it was sent to the wrong list. (The sf list is closed. I'm forwarding this to the correct list.) :) - David Joyner On Nov 14, 2007 8:19 AM, Klas Heggemann [EMAIL PROTECTED] wrote: This fails in the building of one of the libraries: SunOS sgray.nada.kth.se 5.10 Generic_127111-02 sun4u sparc SUNW,Sun-Fire-280R GCC Version gcc -v Using built-in specs. Target: sparc-sun-solaris2.10 Configured with: ../gcc-4.0.2/configure --prefix=/pkg/gcc/4.0.2/os Thread model: posix gcc version 4.0.2 make[2]: Entering directory `/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/spkg/build/flint-0.2.p4/src' gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/ -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include -fexpensive-optimizations -fPIC -funroll-loops -O3 -c mpn_extras.c -o mpn_extras.o gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/ -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include -fexpensive-optimizations -fPIC -funroll-loops -O3 -c Z.c -o Z.o gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/ -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include -fexpensive-optimizations -fPIC -funroll-loops -O3 -c memory-manager.c -o memory-manager.o gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/ -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include -fexpensive-optimizations -fPIC -funroll-loops -O3 -c Z_mpn.c -o Z_mpn.o gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/ -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include -fexpensive-optimizations -fPIC -funroll-loops -O3 -c ZmodF.c -o ZmodF.o gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/ -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include -fexpensive-optimizations -fPIC -funroll-loops -O3 -c ZmodF_mul.c -o ZmodF_mul.o gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/ -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include -fexpensive-optimizations -fPIC -funroll-loops -O3 -c ZmodF_mul-tuning.c -o ZmodF_mul-tuning.o gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/ -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include -fexpensive-optimizations -fPIC -funroll-loops -O3 -c fmpz.c -o fmpz.o gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/ -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include -fexpensive-optimizations -fPIC -funroll-loops -O3 -c fmpz_poly.c -o fmpz_poly.o gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/ -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include -fexpensive-optimizations -fPIC -funroll-loops -O3 -c mpz_poly-tuning.c -o mpz_poly-tuning.o gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/ -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include -fexpensive-optimizations -fPIC -funroll-loops -O3 -c mpz_poly.c -o mpz_poly.o gcc -std=c99 -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include/ -I/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/local/include -fexpensive-optimizations -fPIC -funroll-loops -O3 -c ZmodF_poly.c -o ZmodF_poly.o ZmodF_poly.c: In function 'ZmodF_poly_bit_pack_mpn': ZmodF_poly.c:217: error: 'u_int16_t' undeclared (first use in this function) ZmodF_poly.c:217: error: (Each undeclared identifier is reported only once ZmodF_poly.c:217: error: for each function it appears in.) ZmodF_poly.c:217: error: syntax error before 'lower' ZmodF_poly.c:269: error: 'lower' undeclared (first use in this function) ZmodF_poly.c:269: error: syntax error before 'temp' make[2]: *** [ZmodF_poly.o] Error 1 make[2]: Leaving directory `/afs/.nada.kth.se/pkg/sage/src/sage-2.8.12/spkg/build/flint-0.2.p4/src' This is due to the fact that there is no typedef for u_int_t in include files. mmh, I remember fixing that. Maybe it snuck back in or Bill has fixed it upstream only. Either way I will check this out on my Sun 10 box. Last time I checked I got everything to build except cvxopt (due to missing complex.h, but that might be fixed now, too), but some of the doctests failed upon startup. Klas, if you have the time: Could you run ./sage -testall and report back please? Apologies if I got the wrong Klas Heggemann :) Cheers, Michael Adding this definition in some file makes sage build OK. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log
[sage-devel] Re: another sage talk...
On Nov 14, 2:59 pm, William Stein [EMAIL PROTECTED] wrote: http://sagemath.org/talks/20071114-sage_bristol/ -- William Stein Associate Professor of Mathematics University of Washingtonhttp://wstein.org And a direct link to the inquirer story: http://www.theinquirer.net/articles/flameAuthor/gb/inquirer/news/2007/10/24/mathematics-rediscovers-scientific Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] More potential GPL issues with Singular
Searching some debian mailing lists I came across: Re: Advice on packaging SAGE - see http://lists.debian.org/debian-mentors/2007/06/threads.html Specifically from http://lists.debian.org/debian-mentors/2007/06/msg00020.html *** IIRC Singular has licensing restrictions (requires citing the authors) so I don't think it can go in main. I don't think that is part of the license. After the license there is first a request to send in comments and bugs to a specific address, then a request to register yourself as user, then this request: If you use Singular or parts thereof in a project and/or publish results that were partly obtained using SINGULAR, we ask you to cite SINGULAR and inform us thereof - see `http://www.singular.uni-kl.de/how_to_cite.html', for information on how to cite Singular. I'm no native english speaker, and I think those who have written this are neither. But this looks much like it is a request and no condition on use (or copying/modifying). There are licencse problems with the omalloc library included, but it looks like its author already relicenced it, so it will most likely be fixed in the next version. Hochachtungsvoll, Bernhard R. Link *** This might actually explain why Singular isn't in Debian. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] klogd touble on sage.math
Hello, the disc subsystem seems slow on sage.math and behold: 28099 messageb 25 0 2640 400 312 R 100 0.0 7656:04 klogd i.e. klogd is going nuts using 100% CPU on one core. Can somebody with appropriate rights investigate this? klogd has been started -P which I do not know and isn't documented in its man page. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Coercion trouble
On Nov 16, 3:05 am, David Roe [EMAIL PROTECTED] wrote: The code for residue field is currently not correct. In converting a number field element, it expresses it in terms of a power basis for the number field and then casts the coefficients to Z/pZ. But the coefficients can have denominators divisible by p in general. That's probably what's causing your problem. William and I have been talking about rewriting it so that residue field computes a p-maximal order and then does things appropriately, but it hasn't gotten done yet. David David, could you please open a ticket then. I was also wondering if you ever opened a ticket about the --rpath issue that caused compilation failure on OSX when moving the install. I can't find it, so if you don't want to open that one let me know and I will do. Cheers, Michael On Nov 15, 2007 8:57 PM, mabshoff [EMAIL PROTECTED] wrote: On Nov 16, 1:30 am, Iftikhar Burhanuddin [EMAIL PROTECTED] wrote: Hi folks, Hello Ifti, I run into some coercion trouble when I reduce a fourier coefficient of a cusp form modulo a prime ideal. (See below.) Any idea how I can avoid this? No clue for now, but that looks like a bug to me. Please file a bug report. Cheers, Michael Regards, Ifti === sage: M = ModularSymbols(77, 2) sage: s = M.cuspidal_subspace().new_subspace() sage: N = s.decomposition() sage: f = N[3].q_eigenform() sage: R = f.base_ring() sage: K = R.number_field() sage: O = K.ring_of_integers() sage: I = O.ideal(7) sage: F = O.residue_field(I) sage: F(f[2]) --- type 'exceptions.TypeError' Traceback (most recent call last) /home/burhanud/tau_nov14_07/ipython console in module() /home/burhanud/tau_nov14_07/residue_field.pyx in sage.rings.residue_field.ResidueFiniteField_givaro.__call__() /home/burhanud/tau_nov14_07/finite_field_givaro.pyx in sage.rings.finite_field_givaro.FiniteField_givaro.__call__() type 'exceptions.TypeError': unable to coerce --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Bug Day 6 proposal: Sat. Nov. 24th. 2007
Hello, I would like to propose that the next Bug Day is held on Sat. Nov. 24th. 2007. That is the day before the planned 2.9 release. Since we want to have a point release as a basis for the Bug Day we might have to shift the releases around a little or alternatively this time work of a 2.9pre snapshot. Procedure, timing and so on as always. Thoughts? Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Coercion trouble
On Nov 16, 1:30 am, Iftikhar Burhanuddin [EMAIL PROTECTED] wrote: Hi folks, Hello Ifti, I run into some coercion trouble when I reduce a fourier coefficient of a cusp form modulo a prime ideal. (See below.) Any idea how I can avoid this? No clue for now, but that looks like a bug to me. Please file a bug report. Cheers, Michael Regards, Ifti === sage: M = ModularSymbols(77, 2) sage: s = M.cuspidal_subspace().new_subspace() sage: N = s.decomposition() sage: f = N[3].q_eigenform() sage: R = f.base_ring() sage: K = R.number_field() sage: O = K.ring_of_integers() sage: I = O.ideal(7) sage: F = O.residue_field(I) sage: F(f[2]) --- type 'exceptions.TypeError' Traceback (most recent call last) /home/burhanud/tau_nov14_07/ipython console in module() /home/burhanud/tau_nov14_07/residue_field.pyx in sage.rings.residue_field.ResidueFiniteField_givaro.__call__() /home/burhanud/tau_nov14_07/finite_field_givaro.pyx in sage.rings.finite_field_givaro.FiniteField_givaro.__call__() type 'exceptions.TypeError': unable to coerce --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Coercion trouble
On Nov 16, 3:43 am, David Roe [EMAIL PROTECTED] wrote: Hi David, I lost internet connection and then lost the traceback when my machine restarted, so if you could open a ticket on the __rpath issue, I would apprectiate it. The residue field problem is ticket 1183. David Yep, no problem. The --rpath issue for libcsage is now #1184. But there are 23 or so other spkgs that potentially suffer from the same issue because autoconf/automake uses --rpath Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: SAGE marketing
On Nov 15, 9:18 pm, Ted Kosan [EMAIL PROTECTED] wrote: Who are the main people who are responsible for SAGE marketing? I will have some free time in December and I would like to devote some of it to helping with SAGE's marketing effort. Ted Hi Ted, I don't think there is a formal structure in place to do any marketing, but everybody who is giving talks certainly drives awareness. cwitty just told me in IRC that the 2.8.12 release announcement made it into this weeks Linux Weekly News development section - see http://lwn.net/Articles/257830/ (subscription required). I consider lwn very influential, so that is a good thing. If anybody actively submitted or tried to drive them to add SAGE to their development page I would like to hear about it. But back to your question: We should have somebody or a group of people who are working on Marketing, at least the non-hyperbole driven kind. One thing I can think are consistent a correctly spelled release announcements, so if you could come up with some suggestions and/or a couple standard sentences I would be very happy. In light of the lwn announcement I would like to add some boilerplate to the bottom: Sage is developed by volunteers and combines xx open source packages. It is available for download from sagemath.org and its mirros in source or binary form. If you have any questions and/or problems please report them to the google groups sage-devel, sage-support, sage- forum or sage-newbie This should be the standard on the bottom of each release announcement, so that somebody who runs across Sage via something like lwn would have all the basic information in one place instead of having to crawl over sagemath.org to find them all. Fixing up sagemath.org, especially pages that are not the main index.html, and updating information on the wiki is also something I would consider to be part of marketing. We can certainly use people who are willing to spend some time on that. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Bug Day 6 proposal: Sat. Nov. 24th. 2007
On Nov 16, 7:49 am, Nick Alexander [EMAIL PROTECTED] wrote: On 15-Nov-07, at 6:32 PM, mabshoff wrote: Hello, I would like to propose that the next Bug Day is held on Sat. Nov. 24th. 2007. That is the day before the planned 2.9 release. Since we want to have a point release as a basis for the Bug Day we might have to shift the releases around a little or alternatively this time work of a 2.9pre snapshot. Hello, This is the Thanksgiving weekend, and as such is probably significantly better or significantly worse for people living in America. For me, I will be traveling and not able to participate. Yep, Thanksgiving is certainly a problem. So should we postpone a week? We can certainly [and will] meet informally this Saturday and/or Sunday to get 2.8.13 out the door, but it seems too late now to make this a formal Bug Day. The people who went to SD6 are probably somewhat burned out to make this a formal Bug Day, at least I am. Nick Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Coercion trouble
On Nov 16, 11:56 am, Iftikhar Burhanuddin [EMAIL PROTECTED] wrote:
On Thu, 15 Nov 2007, mabshoff wrote:
On Nov 16, 1:30 am, Iftikhar Burhanuddin [EMAIL PROTECTED] wrote:
I run into some coercion trouble when I reduce a fourier coefficient
of a cusp form modulo a prime ideal. (See below.)
No clue for now, but that looks like a bug to me. Please file a bug
report.
Hello Ifti,
Hi Michael et al,
This is ticket #1185.
David Roe did open #1183 on this, so I commented on both tickets with
references to the other. I am not sure if it is possible to resolve
your specific problem without doing the fixes suggested by David.
I wonder why the base ring of the form is
{{{
sage: R
Univariate Quotient Polynomial Ring in alpha over Rational Field with
modulus x^2 - 5
}}}
and not
{{{
sage: O
Maximal Order in Number Field in alpha with defining polynomial x^2 - 5
}}}
or perhaps
{{{
sage: K
Number Field in alpha with defining polynomial x^2 - 5
}}}
Was it a design decision?
I guess Robert or William could comment on that.
One way to not run into the coercion trouble would be for the base ring of
the form to return the corresponding the number field.
Regards,
Ifti
Cheers,
Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
