[sage-devel] Re: xmaxima is built if you have tcl/tk!
On Mon, Jun 23, 2008 at 10:27 PM, Francois [EMAIL PROTECTED] wrote: I just found out that I have xmaxima in my $SAGE_LOCAL/bin folder. I am pretty sure no one ordered that. It seems that it will build by default if the configure script finds tk. Actually I had a look at the ebuild in Gentoo and to disable it we pass --with-wish=none and do surgery on the makefile.in in the interface folder. Since tcl/tk is not in sage I guess we don't want that extra stuff and the (small) build time associated with it. If no one protest I will open a ticket with a patch in the next few hours. I protest. I think that if the user building Sage has the requisite dependencies to build xmaxima, then it should get built when Sage gets built. -- 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: xmaxima is built if you have tcl/tk!
On Tue, 24 Jun 2008, William Stein wrote: On Mon, Jun 23, 2008 at 10:27 PM, Francois [EMAIL PROTECTED] wrote: I just found out that I have xmaxima in my $SAGE_LOCAL/bin folder. I am pretty sure no one ordered that. It seems that it will build by default if the configure script finds tk. Actually I had a look at the ebuild in Gentoo and to disable it we pass --with-wish=none and do surgery on the makefile.in in the interface folder. Since tcl/tk is not in sage I guess we don't want that extra stuff and the (small) build time associated with it. If no one protest I will open a ticket with a patch in the next few hours. I protest. I think that if the user building Sage has the requisite dependencies to build xmaxima, then it should get built when Sage gets built. I don't care either way personally, but how will the user know that they may actually have xmaxima as well? If they don't know it's there and it was never really intended to be there, they are not losing anything. I'll leave it alone. Francois --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Serverprobleme
Hello, Since http://axiom-wiki.newsynthesis.org physically is on sage.math.washington.edu and http://www.newsynthesis.org/ actually seems not to be down. Could somebody with enough rights and knowledge please check what the problem could be. Thank you. Ralf --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.0.4.alpha0 released
All passed here: Linux version 2.6.18.8-0.3-default ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)) #1 SMP Tue Apr 17 08:42:35 UTC 2007 John 2008/6/24 mhampton [EMAIL PROTECTED]: All tests passed on my intel mac running os x 10.4.11. -M. Hampton On Jun 23, 3:17 pm, mabshoff [EMAIL PROTECTED] wrote: On Jun 23, 12:20 pm, William Stein [EMAIL PROTECTED] wrote: Hi, sage-3.0.4 works on most things I built on. On our arch linux box building lapack failed: I have seen that happen when we install the g95 Fortran spkg, but I have no clue why it blows up sometimes and other times it works. I would actually suggest that in case g95 or gfortran is installed we used that compiler instead of the ones we ship. Thoughts? Cheers, Michael lapack-20071123.p0/src/manpages/blas/man/manl/ztrsv.l lapack-20071123.p0/src/manpages/blas/man/manl/zher2.l lapack-20071123.p0/src/manpages/blas/man/manl/cswap.l lapack-20071123.p0/src/make.inc lapack-20071123.p0/spkg-install~ lapack-20071123.p0/spkg-install Finished extraction Host system uname -a: Linux arch 2.6.24-ARCH #1 SMP PREEMPT Sun Mar 30 10:50:22 CEST 2008 x86_64 Intel(R) Xeon(R) CPU 5150 @ 2.66GHz GenuineIntel GNU/Linux GCC Version gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/usr --enable-shared --enable-languages=c,c++,fortran,objc,obj-c++,treelang --enable-threads=posix --mandir=/usr/share/man --enable-__cxa_atexit --disable-multilib --libdir=/usr/lib --libexecdir=/usr/lib --enable-clocale=gnu --disable-libstdcxx-pch --with-tune=generic Thread model: posix gcc version 4.3.0 (GCC) make[2]: Entering directory `/home/was/build/sage-3.0.4.alpha0/spkg/build/lapack-20071123.p0/src' ( cd INSTALL; make; ./testlsame; ./testslamch; \ ./testdlamch; ./testsecond; ./testdsecnd; ./testversion ) make[3]: Entering directory `/home/was/build/sage-3.0.4.alpha0/spkg/build/lapack-20071123.p0/src/INSTALL' sage_fortran -fPIC -c lsame.f -o lsame.o sage_fortran -fPIC -c lsametst.f -o lsametst.o sage_fortran -o testlsame lsame.o lsametst.o ld: crt1.o: No such file: No such file or directory make[3]: *** [testlsame] Error 1 make[3]: Leaving directory `/home/was/build/sage-3.0.4.alpha0/spkg/build/lapack-20071123.p0/src/INSTALL' /bin/sh: ./testlsame: No such file or directory /bin/sh: ./testslamch: No such file or directory /bin/sh: line 1: ./testdlamch: No such file or directory /bin/sh: line 1: ./testsecond: No such file or directory /bin/sh: line 1: ./testdsecnd: No such file or directory /bin/sh: line 1: ./testversion: No such file or directory make[2]: *** [lapack_install] Error 127 make[2]: Leaving directory `/home/was/build/sage-3.0.4.alpha0/spkg/build/lapack-20071123.p0/src' Error compiling lapack. real0m0.221s user0m0.137s sys 0m0.047s sage: An error occurred while installing lapack-20071123.p0 On Mon, Jun 23, 2008 at 12:16 PM, David Joyner [EMAIL PROTECTED] wrote: Installed fine and all tests passed on hardy heron amd 64, phenom chip. On Mon, Jun 23, 2008 at 9:33 AM, mabshoff [EMAIL PROTECTED] wrote: Hello folks, here goes Sage 3.0.4.alpha0. This is supposed to be a quick release, so let's try to keep this simple. We do have quite a number of blockers that are open, so let's watch out for rc0 soon. As usual please report build issues and doctest failures. Note that the GMP build issue reported a lot in the last week or so has not been fixed yet. Binaries and sources are in the usual location at http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0.4 Reminder: jsmath has been updated, so make sure to test the notebook Below I also list a number of problem tickets that have positive reviews. Cheers, Michael Merged in Sage 3.0.4.alpha0 #2962: Mike Hansen: modify .name() method for ExpectElements to allow renaming [reviewed by Gary Furnish] #3044: Marshall Hampton, Alex Jokela: phcpack improvements: path tracking [Reviewed by Carl Witty] #3132: Gabriel Ebner: Add computation of multinomial coefficients [Reviewed by Carl Witty] #3145: John Palmieri: documentation and defaults for the 'view' function [Reviewed by William Stein] #3149: Carl Witty: off-by-one error in real_roots on AA coefficients [Reviewed by Craig Citro] #3205: Jason Grout: when the notebook scrolls to a new cell that is created, the jsmath box obscures the bottom cell [Reviewed by Mike Hansen] #3206: William Stein: sage -ihttp://url.of.an.spkgdoesn'twork [Reviewed by Gary Furnish] #3207: Jason Grout: upgrade jsmath to version 3.5 [Reviewed by
[sage-devel] Re: Sage 3.0.4.alpha0 released
mabshoff wrote: Hello folks, here goes Sage 3.0.4.alpha0. This is supposed to be a quick release, so let's try to keep this simple. We do have quite a number of blockers that are open, so let's watch out for rc0 soon. As usual please report build issues and doctest failures. Note that the GMP build issue reported a lot in the last week or so has not been fixed yet. Binaries and sources are in the usual location at http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0.4 Reminder: jsmath has been updated, so make sure to test the notebook All tests passed on Fedora 9, 32 bits. The notebook works with Firefox-3.0, but jmol fails in the notebook. Jmol works now from the commandline! Jaap --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.0.4.alpha0 released
On 23 Jun, 14:33, mabshoff [EMAIL PROTECTED] wrote: Hello folks, here goes Sage 3.0.4.alpha0. This is supposed to be a quick release, so let's try to keep this simple. We do have quite a number of blockers that are open, so let's watch out for rc0 soon. As usual please report build issues and doctest failures. Note that the GMP build issue reported a lot in the last week or so has not been fixed yet. Binaries and sources are in the usual location at http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0.4 Reminder: jsmath has been updated, so make sure to test the notebook Below I also list a number of problem tickets that have positive reviews. Cheers, Michael On my Solaris x86 laptop (Solars 11 community edition build 91), it still fails on gmp. x gmp-4.2.2/src/tune/tuneup.c, 49461 bytes, 97 tape blocks x gmp-4.2.2/src/tune/x86_64.asm, 1392 bytes, 3 tape blocks x gmp-4.2.2/src/version.c, 904 bytes, 2 tape blocks Finished extraction Host system uname -a: SunOS kingfisher 5.11 snv_91 i86pc i386 i86pc GCC Version gcc -v Reading specs from /opt/csw/gcc4/lib/gcc/i386-pc-solaris2.8/4.0.2/ specs Target: i386-pc-solaris2.8 Configured with: ../sources/gcc-4.0.2/configure --prefix=/opt/csw/gcc4 --with-local-prefix=/opt/csw --with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix -- enable-shared --enable-multilib --enable-nls --with-included-gettext -- with-libiconv-prefix=/opt/csw --with-x --enable-java-awt=xlib --with- system-zlib --enable-languages=c,c++,f95,java,objc,ada Thread model: posix gcc version 4.0.2 ./spkg-install: gcc}: not found Patching gmp-h.in (fixes OSX 10.5 issues and gcc 4.3 problems) Fast gcd patch: Moving files that are to be replaced to *.orig ... Copying new files across... Done. checking build system type... core2-pc-solaris2.11 checking host system type... core2-pc-solaris2.11 checking for a BSD-compatible install... /usr/bin/ginstall -c checking whether build environment is sane... yes checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no configure: error: ABI=32 is not among the following valid choices: standard Failed to configure. real0m2.309s user0m0.381s sys 0m0.884s sage: An error occurred while installing gmp-4.2.2 --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: xmaxima is built if you have tcl/tk!
On Mon, Jun 23, 2008 at 10:27 PM, Francois [EMAIL PROTECTED] wrote: Hi Francois, I just found out that I have xmaxima in my $SAGE_LOCAL/bin folder. I am pretty sure no one ordered that. It seems that it will build by default if the configure script finds tk. Actually I had a look at the ebuild in Gentoo and to disable it we pass --with-wish=none and do surgery on the makefile.in in the interface folder. Since tcl/tk is not in sage I guess we don't want that extra stuff and the (small) build time associated with it. If no one protest I will open a ticket with a patch in the next few hours. I am not sure if there is any harm if Maxima builds it. When woulds building xmaxima cause a problem? Francois 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: xmaxima is built if you have tcl/tk!
On Wed, 25 Jun 2008, Michael Abshoff wrote: I am not sure if there is any harm if Maxima builds it. When woulds building xmaxima cause a problem? No harm, I cannot imagine how I could be harmful in fact. More like a small waste of ressources and an unintended side-effect. Just my reaction to it being there I guess, I prefer to use wxmaxima myself. Cheers, Francois --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Compilation error on Mac OS 10.5.3
On Jun 23, 10:24 pm, Rob [EMAIL PROTECTED] wrote: On Jun 23, 5:08 pm, mabshoff [EMAIL PROTECTED] wrote: any chance you have Fink or MacPorts installed? I had fink installed years ago, but it's not in my path any longer. Did it leave something around that's causing this problem? I'll try deleting anything that you can suggest. Ok, I am not so sure what exactly could be wrong here. A couple questions: - Which version did compile for you last? - This seems to be a new compile from scratch. Or did you upgrade? - Can you post a link to install.log since maybe I can find something in there? Thanks.--Rob 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.0.4.alpha0 released
mabshoff wrote: Hello folks, here goes Sage 3.0.4.alpha0. This is supposed to be a quick release, so let's try to keep this simple. We do have quite a number of blockers that are open, so let's watch out for rc0 soon. As usual please report build issues and doctest failures. Note that the GMP build issue reported a lot in the last week or so has not been fixed yet. Binaries and sources are in the usual location at http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0.4 Reminder: jsmath has been updated, so make sure to test the notebook jmol fails in the notebook with: 2008-06-24 17:46:40+0200 [HTTPChannel,69,127.0.0.1] Exception rendering: 2008-06-24 17:46:40+0200 [HTTPChannel,69,127.0.0.1] Unhandled Error Traceback (most recent call last): File /home/jaap/downloads/sage-3.0.4.alpha0/local/lib/python2.5/site-packages/twisted/internet/defer.py, line 185, in addCallbacks self._runCallbacks() File /home/jaap/downloads/sage-3.0.4.alpha0/local/lib/python2.5/site-packages/twisted/internet/defer.py, line 323, in _runCallbacks self.result = callback(self.result, *args, **kw) File /home/jaap/downloads/sage-3.0.4.alpha0/local/lib/python2.5/site-packages/twisted/internet/defer.py, line 284, in _continue self.unpause() File /home/jaap/downloads/sage-3.0.4.alpha0/local/lib/python2.5/site-packages/twisted/internet/defer.py, line 280, in unpause self._runCallbacks() --- exception caught here --- File /home/jaap/downloads/sage-3.0.4.alpha0/local/lib/python2.5/site-packages/twisted/internet/defer.py, line 323, in _runCallbacks self.result = callback(self.result, *args, **kw) File /home/jaap/downloads/sage-3.0.4.alpha0/local/lib/python2.5/site-packages/twisted/web2/server.py, line 296, in lambda d.addCallback(lambda res, req: res.renderHTTP(req), self) File /home/jaap/downloads/sage-3.0.4.alpha0/local/lib/python2.5/site-packages/twisted/web2/resource.py, line 85, in renderHTTP return method(request) File /home/jaap/downloads/sage-3.0.4.alpha0/local/lib/python2.5/site-packages/twisted/web2/resource.py, line 202, in http_GET return super(Resource, self).http_GET(request) File /home/jaap/downloads/sage-3.0.4.alpha0/local/lib/python2.5/site-packages/twisted/web2/resource.py, line 128, in http_GET return self.render(request) File /home/jaap/downloads/sage-3.0.4.alpha0/local/lib/python2.5/site-packages/sage/server/notebook/twist.py, line 1133, in render id = self.id(ctx) File /home/jaap/downloads/sage-3.0.4.alpha0/local/lib/python2.5/site-packages/sage/server/notebook/twist.py, line 376, in id return int(ctx.args['id'][0]) exceptions.KeyError: 'id' Jaap --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: pyprocessing
On Sun, Jun 22, 2008 at 10:30 AM, Harald Schilly [EMAIL PROTECTED] wrote: On Jun 22, 10:00 am, William Stein [EMAIL PROTECTED] wrote: So please vote for or against this proposal, or raise questions, etc. +1 from me, too. Just one question, there is a section in the documentation about client/server communications. could this be used to simplify some code in dsage? at least somebody should look into this. Yes. :-) Anyway, since every single person voted +1 and nobody voted -1 or had issues, I declare this package officially accepted. -- 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: pyprocessing
Anyway, since every single person voted +1 and nobody voted -1 or had issues, I declare this package officially accepted. -1! That was fast. What happened to the inclusion procedures? In particular, I am interested to know what other options were investigated and why pyprocessing is considered the best possible solution right now. Nick --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: pyprocessing
On Tue, Jun 24, 2008 at 10:21 AM, Nick Alexander [EMAIL PROTECTED] wrote: Anyway, since every single person voted +1 and nobody voted -1 or had issues, I declare this package officially accepted. -1! That was fast. It was a full 3 days. What happened to the inclusion procedures? In particular, I am interested to know what other options were investigated and why pyprocessing is considered the best possible solution right now. This is discussed at great length in the pages that I linked to, since pyprocessing passed the inclusion procedure for inclusion in standard Python already. Please read thinks at the top of this thread. I'll reopen the voting for two more days. -- 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: pyprocessing
On Tue, Jun 24, 2008 at 10:09 AM, William Stein [EMAIL PROTECTED] wrote: Anyway, since every single person voted +1 and nobody voted -1 or had issues, I declare this package officially accepted. My only suggestion would be to use the version that will be used for inclusion into python itself: http://www.python.org/dev/peps/pep-0371/ (it will be called multiprocessing, for one). That way everyone will use the future-proof API and you'll be able to simply drop it from Sage once it's included in the underlying Python. I'm not sure how much the API has changed for the merge, but I know they were discussing a few small name fixes. Cheers, f --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: pyprocessing
On Tue, Jun 24, 2008 at 10:30 AM, Fernando Perez [EMAIL PROTECTED] wrote: On Tue, Jun 24, 2008 at 10:09 AM, William Stein [EMAIL PROTECTED] wrote: Anyway, since every single person voted +1 and nobody voted -1 or had issues, I declare this package officially accepted. My only suggestion would be to use the version that will be used for inclusion into python itself: http://www.python.org/dev/peps/pep-0371/ (it will be called multiprocessing, for one). That way everyone will use the future-proof API and you'll be able to simply drop it from Sage once it's included in the underlying Python. I'm not sure how much the API has changed for the merge, but I know they were discussing a few small name fixes. I don't understand your email, since as far as I can tell the version that will be included in Python itself doesn't exist yet. The PEP just describes the version for Python in the abstract. I couldn't find a link to any actual finished code that completely implements that version. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: pyprocessing
I already gave this a verbal +1, but does anyone know what happens if you fork a sage process with open pexpect interface? On Tue, Jun 24, 2008 at 10:26 AM, William Stein [EMAIL PROTECTED] wrote: On Tue, Jun 24, 2008 at 10:21 AM, Nick Alexander [EMAIL PROTECTED] wrote: Anyway, since every single person voted +1 and nobody voted -1 or had issues, I declare this package officially accepted. -1! That was fast. It was a full 3 days. What happened to the inclusion procedures? In particular, I am interested to know what other options were investigated and why pyprocessing is considered the best possible solution right now. This is discussed at great length in the pages that I linked to, since pyprocessing passed the inclusion procedure for inclusion in standard Python already. Please read thinks at the top of this thread. I'll reopen the voting for two more days. -- William I' --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: xmaxima is built if you have tcl/tk!
On Tue, Jun 24, 2008 at 8:32 AM, Michael Abshoff [EMAIL PROTECTED] wrote: I am not sure if there is any harm if Maxima builds it. When woulds building xmaxima cause a problem? I'm sure it doesn't; the issue is that sage builds something behind your back, so you won't find it if you're not looking for it. Also, the behavior is not consistent since this seems to depend the user's machine (ie tk vs non-tk). didier --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: pyprocessing
On Tue, Jun 24, 2008 at 10:36 AM, Gary Furnish [EMAIL PROTECTED] wrote: I already gave this a verbal +1, but does anyone know what happens if you fork a sage process with open pexpect interface? I'm sure it's a problem that we'll have to address, and there are ways to do so (e.g. in the forked process run a command that quits all started pexpect interfaces). For everything I do for my research it isn't an issue since I don't actually use any of the pexpect stuff (all my code is native). 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: pyprocessing
On Tue, Jun 24, 2008 at 10:35 AM, William Stein [EMAIL PROTECTED] wrote: On Tue, Jun 24, 2008 at 10:30 AM, Fernando Perez [EMAIL PROTECTED] wrote: On Tue, Jun 24, 2008 at 10:09 AM, William Stein [EMAIL PROTECTED] wrote: Anyway, since every single person voted +1 and nobody voted -1 or had issues, I declare this package officially accepted. My only suggestion would be to use the version that will be used for inclusion into python itself: http://www.python.org/dev/peps/pep-0371/ (it will be called multiprocessing, for one). That way everyone will use the future-proof API and you'll be able to simply drop it from Sage once it's included in the underlying Python. I'm not sure how much the API has changed for the merge, but I know they were discussing a few small name fixes. I don't understand your email, since as far as I can tell the version that will be included in Python itself doesn't exist yet. The PEP just describes the version for Python in the abstract. I couldn't find a link to any actual finished code that completely implements that version. This is a start: http://archives.free.net.ph/message/20080610.191155.321829bc.fi.html ( the relevant links are there) Cheers, f --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: pyprocessing
On Tue, Jun 24, 2008 at 10:46 AM, Fernando Perez [EMAIL PROTECTED] wrote: On Tue, Jun 24, 2008 at 10:35 AM, William Stein [EMAIL PROTECTED] wrote: On Tue, Jun 24, 2008 at 10:30 AM, Fernando Perez [EMAIL PROTECTED] wrote: On Tue, Jun 24, 2008 at 10:09 AM, William Stein [EMAIL PROTECTED] wrote: Anyway, since every single person voted +1 and nobody voted -1 or had issues, I declare this package officially accepted. My only suggestion would be to use the version that will be used for inclusion into python itself: http://www.python.org/dev/peps/pep-0371/ (it will be called multiprocessing, for one). That way everyone will use the future-proof API and you'll be able to simply drop it from Sage once it's included in the underlying Python. I'm not sure how much the API has changed for the merge, but I know they were discussing a few small name fixes. I don't understand your email, since as far as I can tell the version that will be included in Python itself doesn't exist yet. The PEP just describes the version for Python in the abstract. I couldn't find a link to any actual finished code that completely implements that version. This is a start: http://archives.free.net.ph/message/20080610.191155.321829bc.fi.html ( the relevant links are there) I see -- that puts it right into Python and introduces bugs. I'm very much *not* proposing doing that. I'm proposing including pyprocessing until multiprocessing is in Python, then removing pyprocessing from sage. -- 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: pyprocessing
This is discussed at great length in the pages that I linked to I don't see any discussion of alternatives at http:// pyprocessing.berlios.de/ and I certainly don't see any argument supporting pyprocessing over any alternative with direct reference to Sage. Where is that? And where is the discussion of building on supported operating systems... and the trial spkg... and all the other things that I expected with a potential inclusion. Did I miss a thread? Just for the record, I'm +1 -- but if we're going to have a process for spkg inclusion, I'd like to see it followed. Nick --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: pyprocessing
On Tue, Jun 24, 2008 at 11:43 AM, Nick Alexander [EMAIL PROTECTED] wrote: This is discussed at great length in the pages that I linked to I don't see any discussion of alternatives at http:// pyprocessing.berlios.de/ and I certainly don't see any argument supporting pyprocessing over any alternative with direct reference to Sage. Where is that? And where is the discussion of building on supported operating systems... and the trial spkg... and all the other things that I expected with a potential inclusion. Did I miss a thread? Yes, evidently. I'll track these discussions down when I have time later today. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: xmaxima is built if you have tcl/tk!
2008/6/24 didier deshommes [EMAIL PROTECTED]: On Tue, Jun 24, 2008 at 8:32 AM, Michael Abshoff [EMAIL PROTECTED] wrote: I am not sure if there is any harm if Maxima builds it. When woulds building xmaxima cause a problem? I'm sure it doesn't; the issue is that sage builds something behind your back, so you won't find it if you're not looking for it. Also, the behavior is not consistent since this seems to depend the user's machine (ie tk vs non-tk). didier There is harm when building a binary package. If the user making the binary has tk on his computer then xmaxima will be part of the binary package and will fail miserably on the computers of others that don't have tk. Arnaud --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: xmaxima is built if you have tcl/tk!
On Jun 24, 12:00 pm, Arnaud Bergeron [EMAIL PROTECTED] wrote: 2008/6/24 didier deshommes [EMAIL PROTECTED]: Hi, On Tue, Jun 24, 2008 at 8:32 AM, Michael Abshoff [EMAIL PROTECTED] wrote: I am not sure if there is any harm if Maxima builds it. When woulds building xmaxima cause a problem? I'm sure it doesn't; the issue is that sage builds something behind your back, so you won't find it if you're not looking for it. Also, the behavior is not consistent since this seems to depend the user's machine (ie tk vs non-tk). didier There is harm when building a binary package. If the user making the binary has tk on his computer then xmaxima will be part of the binary package and will fail miserably on the computers of others that don't have tk. Sure, but xmaxima is not used by Sage directly. If there is a config option to disable its build I am more than happy to disable building it, but going into Makefile.in seems a little too invasive for my taste. If it cannot be disabled we should file a bug report upstream. Arnaud 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: pyprocessing
Did I miss a thread? Yes, evidently. I'll track these discussions down when I have time later today. If everyone else is satisfied, then I'm satisfied. +1 Nick --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: xmaxima is built if you have tcl/tk!
On Tue, Jun 24, 2008 at 12:15 PM, mabshoff [EMAIL PROTECTED] wrote: On Jun 24, 12:00 pm, Arnaud Bergeron [EMAIL PROTECTED] wrote: 2008/6/24 didier deshommes [EMAIL PROTECTED]: Hi, On Tue, Jun 24, 2008 at 8:32 AM, Michael Abshoff [EMAIL PROTECTED] wrote: I am not sure if there is any harm if Maxima builds it. When woulds building xmaxima cause a problem? I'm sure it doesn't; the issue is that sage builds something behind your back, so you won't find it if you're not looking for it. Also, the behavior is not consistent since this seems to depend the user's machine (ie tk vs non-tk). didier There is harm when building a binary package. If the user making the binary has tk on his computer then xmaxima will be part of the binary package and will fail miserably on the computers of others that don't have tk. Sure, but xmaxima is not used by Sage directly. If there is a config option to disable its build I am more than happy to disable building it, but going into Makefile.in seems a little too invasive for my taste. If it cannot be disabled we should file a bug report upstream. -1 I'm very much against disabling building xmaxima. I really don't get at all how you can argue against building xmaxima. You might as well argue against building Python bindings for tcl/tk, and all other gui bindings for Sage components. -- 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: xmaxima is built if you have tcl/tk!
I'm with William. I was pretty happy when Francois reported (or more precisely reminded me, since I think I knew and forgot) that xmaxima was available. This means that openmath plotter (like jmol, but using tcl.tk instead of java) is available too, whenever tcl/tk is installed. On Tue, Jun 24, 2008 at 3:20 PM, William Stein [EMAIL PROTECTED] wrote: On Tue, Jun 24, 2008 at 12:15 PM, mabshoff [EMAIL PROTECTED] wrote: On Jun 24, 12:00 pm, Arnaud Bergeron [EMAIL PROTECTED] wrote: 2008/6/24 didier deshommes [EMAIL PROTECTED]: Hi, On Tue, Jun 24, 2008 at 8:32 AM, Michael Abshoff [EMAIL PROTECTED] wrote: I am not sure if there is any harm if Maxima builds it. When woulds building xmaxima cause a problem? I'm sure it doesn't; the issue is that sage builds something behind your back, so you won't find it if you're not looking for it. Also, the behavior is not consistent since this seems to depend the user's machine (ie tk vs non-tk). didier There is harm when building a binary package. If the user making the binary has tk on his computer then xmaxima will be part of the binary package and will fail miserably on the computers of others that don't have tk. Sure, but xmaxima is not used by Sage directly. If there is a config option to disable its build I am more than happy to disable building it, but going into Makefile.in seems a little too invasive for my taste. If it cannot be disabled we should file a bug report upstream. -1 I'm very much against disabling building xmaxima. I really don't get at all how you can argue against building xmaxima. You might as well argue against building Python bindings for tcl/tk, and all other gui bindings for Sage components. -- 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: pyprocessing
Nick Alexander wrote: Did I miss a thread? Yes, evidently. I'll track these discussions down when I have time later today. If everyone else is satisfied, then I'm satisfied. +1 Maybe it would be good to have a wiki page that tracks a potential package's discussion maintained by the person that is pushing the package through. If we had a standard boilerplate page that followed the package inclusion checklist, it'd help make sure that the procedure was followed. The page wouldn't have to be much; just links to the appropriate discussions on sage-devel. Something like a Potential Package Proposal page (this page, of course, properly propounds the propriety of the package participating in our popular product!) Thanks, Jason --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: hg clone revisited...
On Jun 17, 2008, at 4:13 PM, Glenn H Tarbox, PhD wrote: So, my conclusion is that we should be using branch instead of clone as the general development strategy with clone limited to those who are working specific types of problems and need to deal with it. All this leads to one of my original points: We might want to consider using Hg as designed... Heretic!!! I use clones a lot because I often work on (low level) .pyx files, but I agree that many people would be better served by branching, which one can do now, and this should be discussed in the user manual. Mercurial queues seem to be very nice too (I'm going to be using them more) and mesh well with the referee process. OK, what Glenn means to say is: I suggest there's a better way to manage the sage development process using the features of Hg. Realizing that Sage's current process works and there's undoubtedly a significant amount of debate ahead of us, the Bolsheviks of the finance / dsageng activities are going to use an alternative (Hg's intended) approach of branching and merging as the sole mechanism for distributed development and version control Accordingly, there will be an hg server with various branches associated with the development activities. Synchronization with Sage distributions will occur with patch sets or using an out-of-band coordination with the Central Committee. How to view / use / contribute to the finance / dsageng activities will be explained on the wiki and announced in a few days once the infrastructure has been instantiated. Do you have a link to the aforementioned wiki? - Robert --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Compilation error on Mac OS 10.5.3
On Jun 23, 5:01 pm, I wrote: Hi, I'm getting a compilation error for R when trying to compile 3.0.3. What I hope is the relevant piece of the installation log is below. Any help is greatly appreciated. Thanks.--Rob Configuring R for OSX checking build system type... i386-apple-darwin9.3.0 checking host system type... i386-apple-darwin9.3.0 Note: forcing SHELL=/bin/bash, because /bin/sh is incompatible loading site script './config.site' loading build specific script './config.site' . config.status: creating tools/Makefile config.status: creating src/include/config.h ./config.status: line 1202: 1: cannot overwrite existing file ./config.status: line 1260: 1: cannot overwrite existing file ./config.status: line 1316: 1: cannot overwrite existing file ./config.status: line 1318: 1: cannot overwrite existing file ./config.status: line 1374: 1: cannot overwrite existing file ./config.status: line 1376: 1: cannot overwrite existing file ./config.status: line 1432: 1: cannot overwrite existing file ./config.status: line 1434: 1: cannot overwrite existing file ./config.status: line 1464: 1: cannot overwrite existing file config.status: executing po-directories commands . R is now configured for i386-apple-darwin9.3.0 At my wit's end, I tried sudo make rather than make, and that solved the problem. Does anyone have any ideas what I might have been doing wrong? I'm sure that whatever I did wrong will crop up again if I don't solve the problem now. Thanks.--Rob --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: hg clone revisited...
On Tue, 2008-06-24 at 21:08 -0700, Robert Bradshaw wrote: On Jun 17, 2008, at 4:13 PM, Glenn H Tarbox, PhD wrote: So, my conclusion is that we should be using branch instead of clone as the general development strategy with clone limited to those who are working specific types of problems and need to deal with it. All this leads to one of my original points: We might want to consider using Hg as designed... Heretic!!! I use clones a lot because I often work on (low level) .pyx files, but I agree that many people would be better served by branching, which one can do now, and this should be discussed in the user manual. Mercurial queues seem to be very nice too (I'm going to be using them more) and mesh well with the referee process. Unfortunately, upon further review and lots of checking on the lists, turns out that Hg named branches are not good and are being reconsidered by the mercurial folks. They are very much not the same thing as bzr or git branches... and it took a while to understand what was really going on. Anyway, I have lots of thoughts on the subject but I'm going to let them bake for a while. Our smaller crew will experiment with a few approaches and report back. Basically, we'll have a repo for each developer where repo will mean 'set of clones' each with branches. Under the hood I'll use a little dark magic to make goodness happen and maintain a useful view of the state of development as a single Hg repo with well named branches. The state will likely appear more linear than will actually be happening, but the various tips and heads of the branches of the central Hg repo will be correct... just a little history adjustment along the way All of the repos will be published to central sites on a consistent basis. Some branches will be named as working meaning anything goes... We will all push on a regular basis regardless of the state of the code... and use naming conventions to indicate stability. In my case, my published repo is the mechanism I use for internal code distribution... so the granularity is very fine indeed... full of bugs and silliness... OK, what Glenn means to say is: I suggest there's a better way to manage the sage development process using the features of Hg. Realizing that Sage's current process works and there's undoubtedly a significant amount of debate ahead of us, the Bolsheviks of the finance / dsageng activities are going to use an alternative (Hg's intended) approach of branching and merging as the sole mechanism for distributed development and version control Accordingly, there will be an hg server with various branches associated with the development activities. Synchronization with Sage distributions will occur with patch sets or using an out-of-band coordination with the Central Committee. How to view / use / contribute to the finance / dsageng activities will be explained on the wiki and announced in a few days once the infrastructure has been instantiated. Do you have a link to the aforementioned wiki? http://wiki.sagemath.org/GlennTarbox/HgDevelopment - Robert -- Glenn H. Tarbox, PhD || 206-494-0819 || [EMAIL PROTECTED] Don't worry about people stealing your ideas. If your ideas are any good you'll have to ram them down peoples throats -- Howard Aiken --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] orders in number fields are not unique parents?
Could someone who knows orders in number fields verify that they are
not at the moment unique parents and, if that is the desired
behaviour, explain why? I have a coercion error in ell_number_field
based on this.
{{{
sage: K.a = NumberField(x^2 + 1, 'a')
sage: O1 = K.order([a, 1])
sage: O2 = K.order([a, 1, 1])
sage: O1 == O2
True
sage: O1 is O2
False
sage: O1.gens()
(1, a)
sage: O2.gens()
(1, a)
}}}
Nick
--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---
