[sage-devel] Re: does zn_poly normally take a long time to build?
On Jul 16, 8:39 pm, tkeller [EMAIL PROTECTED] wrote: Hi, The last build I built from source (3.0.3) took ~ 3 hours total on my average dell laptop (running kubuntu 8.0.4.1). Building 3.0.5 is ongoing, but has spent the last 5+ hours on zn_poly tuning program. Is this normal? It hasn't stalled, but has effectively tripled the compilation time (at least). This sounds like a build issue to me. zn_poly's build time should be more or less instant. Even with the check target active (which is disabled right now) it should only take 10 to 12 minutes on a decent CPU. Can you save the current tail of install.log and put it up on the web somewhere. Then hit CTRL-C and restart the build process with make. If it hangs again/takes very long we need to poke around. Is this normal for other platforms? No, this is not normal. Thomas 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] Sage 3.0.6.alpha0 released
Hello folks,
this is 3.0.6.alpha0. This release is a mix of bug fixes and new
features. Nothing crazy has been merged so far and it is unclear at
the moment how things will develop until ISSAC. I have a bunch of
Solaris build fixes sitting on my box that have not been merged due to
lack of time (I am leaving for ECM in about an hour), but expect
steady progress on that front in 3.0.6. As usual please review patches
and spkgs since we have a boatload of them sitting in trac.
Sources and a binary for sage.math are in the usual place:
http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0.6/sage-3.0.6.alpha0.tar
http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0.6/sage-3.0.6.alpha0-sage.math-only-x86_64-Linux.tar.gz
As usual please report problems and testing results.
Cheers,
Michael
#3232: Martin Albrecht: wrap NTL's BKZ [Reviewed by Ralph-Philipp
Weinmann]
#3531: Gary Furnish: create optional boehm_gc.spkg [Reviewed by
Michael Abshoff]
#3532: Gary Furnish: create optional gdbm.spkg [Reviewed by Michael
Abshoff]
#3554: Mike Hansen: improve M2 pexpect interface [Reviewed by Gary
Furnish]
#3564: William Stein: optimize sage startup: don't import sympy by
default [Reviewed by Michael Abshoff]
#3579: Emily Kirkman: bug in RandonGNP graph constructor [Reviewed by
Robert Miller]
#3592: Ondrej Certik: update sympy to the 0.6.0 release [Reviewed by
Michael Abshoff]
#3601: Anne Schilling: Reimplementation of tensor products [Reviewed
by Mike Hansen]
#3614: Gary Furnish: pbuild broken by finance [Reviewed by Michael
Abshoff]
#3626: Tom Boothby: Graph.set_boundary only takes lists [Reviewed by
Robert Miller]
#3629: Clement Pernet: givaro-3.2.11 installs its own libgmpxx.{so,a}
[Reviewed by Michael Abshoff]
#3650: Gary Furnish: Infinite recursion in pbuild by recursive pxd
imports [Reviewed by Michael Abshoff]
#3651: John Cremona: elliptic curves -- bug in L_ratio() [Reviewed by
Chris Wuthrich]
#3657: Carlo Hamalainen: Documentation for latin squares, DLXCPP;
minor fixes [Reviewed by Mike Hansen]
#3632: Chris Wuthrich, David Harvey: small bug in p-adic heights
[Reviewed by David Harvey, Chris Wuthrich]
#3647: Michael Abshoff: remove - static-libgcc from lcalc's CFLAGS)
[Reviewed by Mike Hansen]
#3648: Carl Witty, David Harvey: complex(pari(...)) fails [Reviewed by
David Harvey, Carl Witty]
#3660: Anne Schilling, Mike Hansen: add documentation to the reference
manual for crystals and root systems [Reviewed by Mike Hansen]
#3661: Nicolas Thiery, Mike Hansen: move sage/combinat/family.py into
the main tree [Reviewed by Mike Hansen]
#3667: William Stein: notebook -- if user history can't be loaded from
disk make it blank (much better than making entire notebook not work
at all) [Reviewed by Michael Abshoff]
--~--~-~--~~~---~--~~
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: does zn_poly normally take a long time to build?
On Jul 16, 8:54 pm, tkeller [EMAIL PROTECTED] wrote: Hi Thomas, I may have been imprecise. To clarify, zn_poly built, then displayed this message: Calibrating cycle counter... ok (3.84e+18) KS mul: ... KS sqr: ... Nussbaumer mul: ... Nussbaumer sqr: ... KS/FFT mul: ... KS/FFT sqr: ... midmul FFT: . This was ongoing for the 5ish hours I mentioned, before I accidentally aborted the build process. The actual build process itself for zn_poly went relatively quickly. I'll check the log after this attempt finishes. Yeah, this is pretty much as I expected. The tuning phase should only take a couple minutes, so you either hit a bug in zn_poly or something is wrong with your RAM, compiler, etc. I expect David Harvey (the author of zn_poly) to pop up in the morning (east coast time) and ask you more detailed questions. Regards, Thomas What was the last version of Sage that did build for you? IIRC we did not touch zn_poly since Sage 3.0.2 or so, so unless something changed on your end it seems odd to start failing now. 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.5/3.0.6.alpha0: doctest failure in ssmod.py
Ok, here is what I found out last night: * 3.0.3 runs the test 200 times without failing it once * 3.0.4 with the new FLINT 1.0.13 fails 8 ought of 500 tests. So we are given a couple possibilities: * There is an algorithmic issue in ssmod somewhere or some algorithmic issue got exposed somehow in 3.0.4+ * There is an undiscovered bug in LinBox * There is an undiscovered bug in FLINT * none of the above * all of the above 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.5/3.0.6.alpha0: doctest failure in ssmod.py
On Jul 17, 10:34 pm, mabshoff [EMAIL PROTECTED] wrote: Ok, here is what I found out last night: * 3.0.3 runs the test 200 times without failing it once * 3.0.4 with the new FLINT 1.0.13 fails 8 ought of 500 tests. So we are given a couple possibilities: * There is an algorithmic issue in ssmod somewhere or some algorithmic issue got exposed somehow in 3.0.4+ * There is an undiscovered bug in LinBox * There is an undiscovered bug in FLINT * none of the above * all of the above After looking at the code William has conjectured that it is very likely charpoly mod p that fails here. We update Linbox in 3.0.3- 3.0.4, so that fits the bill. This issue is now #3671. To debug this we can compute the charpoly with LinBox and the generic code for a large number of random inputs and compare. According to William the speed difference between generic code and LinBox for the example in ssmod (32 by 32 matrices) won't be too large. If you have any (alternate) theories what goes wrong here please let us know. Cheers, Michael Cheers, Michae --~--~-~--~~~---~--~~ 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.6.alpha0 released
On Jul 18, 1:01 am, John Cremona [EMAIL PROTECTED] wrote: Hi John, Following Ansrzej's report I tried the same thing. For me the test always takes 2.0-2.1s but the 5th or 6th time I got the failure: sage -t devel/sage/sage/modular/ssmod/ssmod.py ** SNIP /home/jec/sage-3.0.6.alpha0/tmp/.doctest_ssmod.py [2.1 s] exit code: 1024 -- The following tests failed: sage -t devel/sage/sage/modular/ssmod/ssmod.py Total time for all tests: 2.1 seconds -- after that another 10 tests of that file went ok (and only took 2s). John William and I poked around and it seems to be LinBox related, more specifically computing the charpoly mod p with LinBox 1.1.6.rc0 or later, which was updated from 3.0.3 to 3.0.4. We are tracking the issue at #3671. Clement has been notified and we are hoping to put this to bed today by switching to the generic charpoly implementation which in this case should not be much slower. Once [If?] we nail the bug in LinBox we can then switch back. 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] Sagemath.org mirrors
Hello folks, we finally have working mirrors again, but since we moved a lot of files around most mirrors not sage.math are still catching up since they all have to mirror 28GB. Be patient and everything should be back to normal in a day or two. Apologies for breaking the mirrors, I hope it won't happen again :) 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] [Fwd: [atlas-devel] ATLAS 3.9.0 LAPACK]
Hi, the following might be interesting for some people around here. As time permits I will offer an optional spkg. Cheers, Michael Original Message Subject: [atlas-devel] ATLAS 3.9.0 LAPACK Date: Fri, 18 Jul 2008 06:19:10 -0500 From: Clint Whaley [EMAIL PROTECTED] Reply-To: List for developer discussion, NOT SUPPORT. math-atlas- [EMAIL PROTECTED] To: [EMAIL PROTECTED] Guys, Its been a long time coming, but I have finally heaved out 3.9.0. The main reason for the this long delay is that I did a major rewrite of ATLAS for additional rank-K performance, which timings showed was a big win **until I fixed the performance bug that mandated 3.8.2**. After that, I found I had written thousands of lines of code for nothing, so I had to yank the code back out :( However, 3.9.0 is finally out, and it has several key features that I hope will make it worth the wait. There are much improved DGEMM kernels for Core2Duo64 and K10h64 architectures. These kernels (particulary K10h) can still be improved, and I haven't yet ported them to single precision or 32 bits. However, this should provide some relief on the Core2Duo, where ATLAS was taking a savage beat-down from Goto and MKL blas. ATLAS still trails Goto, but it is not quite the same excoriating humiliation now (at least for for double). The key to the Core2Duo64 was doing 2D blocking, which I had tested but apparently messed up before. Thanks to Yevgen Voronenko of CMU/ SPIRAL, who gave me a code fragment to work from (see ATLAS/doc/AtlasCredits.txt for details). The main focus of 3.9.0 has been in improving ATLAS's LAPACK support. The first of these is that you no longer have to install LAPACK separately from ATLAS. If you have LAPACK 3.1.1 untarred somewhere, you can use the flag '-Ss lasrc /path/to/lapack3.1.1/SRC', and ATLAS will automatically build it during the ATLAS build, with no need for the flag/make.inc headaches that we have in the 3.8 series. You can also provide '--with-netlib-lapack-tarfile=/path/to/tarfile' and ATLAS will extract the tarfile for you in the ATLAS directory, and build it from there. If you have more than one install, you can save space by using the -Ss flag, so that all ATLAS installs share one copy of the LAPACK source, so I recommend the first method. The second big lapack push for this release is that I've started to support a new C API for lapack, which I hope to eventually expand to all of LAPACK. For most of the routines, it calls the F77LAPACK, but for ATLAS native routines (like LU/Cholesky) it calls ATLAS's faster routines instead. The name is the f77 name, in lower case, with a C_ prepended. Thus DGETRF is C_dgetrf. Character arguments (Uplo, Trans, etc) are replaced by CBLAS enum types, and all (non-complex) scalars are passed by value. This API supports only column major arrays (it mostly calls the F77/netlib lapack, which are column-major only). Routines that take workspace in F77 don't in the C_ equivalents, as the wrapper auto- queries LAPACK and allocates. However, if you want to allocate the work yourself, the routine taking workspace usually exists with the name C_rout_wrk and you can test if it exists by doing (it may not exist if ATLAS supports the routine natively): #ifdef ATL_C2Frout_wrk__ (eg., ATL_C2Fdgels_wrk__) This API is currently supported for the following LAPACK routines: ATLAS native routines: xPOSV xGESV xPOTRF xGETRF xPOTRS xPOTRI xLAUMM C2F wrappers: xGELS xGELQF xGERQF xGEQLF xGEQRF Obviously, you need to build the full lapack library (and thus need a functional F77 compiler) to use these routines. You can find more info in the following files found in ATLAS/include: C_lapack.h# main header file you must include to use the C_lapack API clapack.h # header for ATLAS's native lapack atlas_C2Flapack.h # header for C to F77 wrapper functions. I would like to get some feedback on this new API. I use macros to select between native C2F files to save some calling overhead. Is this real bad news for people? Will it make your life easier to have a full C API supported out-of-the-box for ATLAS? If there is a demand for this API, I can fill it out fairly rapidly (with some help from you guys for testing); if there's not, I will populate it only as needed for internal ATLAS stuff. So, speak up if you are interested! Finally, the last lapack deal is that ATLAS can now tune some of the lapack routines that it doesn't natively support by empirically tuning LAPACK's blocking factor to both the platform and problem size. Right now, ATLAS autotunes only the QR factorization routines mentioned above. Initial timings show improvements ranging from 5-25% (as much as 75% for small problems on Itanium!). Core2Duo64SSE3 has arch defaults with QR pretuned. Be default, ATLAS does not tune LAPACK. To enable it, you pass '-Si latune 1' to configure. You will only want to do this if QR (or one of the many LAPACK routines that
[sage-devel] Re: Sage 3.0.5/3.0.6.alpha0: doctest failure in ssmod.py
On Jul 18, 12:24 pm, Clement Pernet [EMAIL PROTECTED] wrote: Hi Clement, I am looking into it. Thanks. We are still not 100% certain that the probabilistic charpoly mod p is at fault here, but it can't hurt to take a look. Applying the patch athttp://sage.math.washington.edu/home/pernet/Patches/charpoly_LUK.patch will disable the current probablistic charpoly algorithm. This could help diagnose the origin of the bug. I have applied the patch and rebuild LinBox and started running the test 500 times to see. Can you guess if/how much this patch does affect performance for charpoly mod p? Some data points: I could never get valgrind to detect any problem with ssmod.py, but since it took about 2200 seconds in sage.math for one round that is not so surprising since the sample set was so small. Cheers Clement Cheers, Michael mabshoff a écrit : On Jul 17, 10:34 pm, mabshoff [EMAIL PROTECTED] wrote: Ok, here is what I found out last night: * 3.0.3 runs the test 200 times without failing it once * 3.0.4 with the new FLINT 1.0.13 fails 8 ought of 500 tests. So we are given a couple possibilities: * There is an algorithmic issue in ssmod somewhere or some algorithmic issue got exposed somehow in 3.0.4+ * There is an undiscovered bug in LinBox * There is an undiscovered bug in FLINT * none of the above * all of the above After looking at the code William has conjectured that it is very likely charpoly mod p that fails here. We update Linbox in 3.0.3- 3.0.4, so that fits the bill. This issue is now #3671. To debug this we can compute the charpoly with LinBox and the generic code for a large number of random inputs and compare. According to William the speed difference between generic code and LinBox for the example in ssmod (32 by 32 matrices) won't be too large. If you have any (alternate) theories what goes wrong here please let us know. Cheers, Michael Cheers, Michae --~--~-~--~~~---~--~~ 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: sagemath.org website info #2
On Jul 18, 12:33 pm, Harald Schilly [EMAIL PROTECTED] wrote: Hi Harald, Hello Sage folks, as promised in my last website posting [1], here a bit more how things evolved. nice work and thanks for your continued efforts. First, since there is some tracking going on, and I have a bit more than two weeks to compare, I can make some trends and analysis. The first thing is, that the visitors come and go very stable. During work-days 850-1050 visits. On weekends around 600. (Here, visits are unique computers, old ones and new ones together) Then, just counting unique new visitors (they were never before on the page) there are about 750-800 on weekdays and nearly 500 on weekends. Conclusion, a lot of new visitors, and those who visit regularly have a nice weekend ;) Comparing both weeks, ~3% more visits, a bit less page views and 8% less new visitors. The pages itself, the front-page is the same, but now download is up to rank 2, and tour down to rank 3. (38%, 13%, 11%) Then help (4.5%) and tour-quickstart (4%). Now the more interesting things, sources: 34% from other websites and 31% search engines other websites: macupdate.com + 270% (!!) = 179 visits Yes, that one does surprise me each week, but I guess that is a good thing :) en.wikipedia.org + 5% = 153 v. linuxappfinder.com +231% = 106 v. macresearch.org -42% (- would be interesting to know why, maybe no longer a new link) stumbleupon.com -50% aur.archlinux.org + 117% (also interesting) fr.wikipedia.org + 425% (but that's already very low ... 4 visits up to 21 visits) +100% equals 2x the number of referring pages Since this may not work very accurate at all, relative trends are ok. This just tells me, that there are still no really big sites linking to sage. We will see ... search engines: google - constant - 1800 visits from there :) yahoo 35 the others are 10 so, google is really really important! Yeah, but that number is still surprising to say the least. something funny: type in open source mathematica in google.com and hit i'm feeling lucky... open source maths software works, too. but not without the s ;) what has changed? * I made a call for success stories [2] - still open! - see [3] * the mirror system is redone. now, there is one central pagewww.sagemath.organd helpful servers mirroring files. They are currently very big, but this will reduce down to the important files. There is now a page to check the mirror status, too. [4] Keep in mind that this is not the final list, there will be changes and they should be sorted by continent. All but the Vancouver mirror are currently syncing or have finished syncing already, so in a little while we should be back to a fully functioning mirror system. * more text on the tour.html page * many many small edits ... Harald Cheers, Michael [1]http://groups.google.com/group/sage-devel/msg/c610d318f86d5ddf [2]http://groups.google.com/group/sage-devel/browse_frm/thread/efb05c839... [3]http://www.sagemath.org/library/stories.html [4]http://www.sagemath.org/mirrors.html --~--~-~--~~~---~--~~ 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.5/3.0.6.alpha0: doctest failure in ssmod.py
On Jul 18, 3:59 pm, Clement Pernet [EMAIL PROTECTED] wrote: snip I have applied the patch and rebuild LinBox and started running the test 500 times to see. Can you guess if/how much this patch does affect performance for charpoly mod p? For the dimensions you are considering (and up to a thousand) I don't expect any performance loss. But the probabilistic alg improves on larger matrices and gets asymptotically better (the best algorithm indeed!) I'll let you know when I've made progress on this one. Cool. ssmod.py passes 500 doctests in a row with the patch applied. Clement Re performance: The old code, i.e. non mod-p algorithm: sage: A = random_matrix(GF(997),500) sage: time p=A.charpoly() CPU times: user 1.42 s, sys: 0.06 s, total: 1.48 s Wall time: 1.51 s sage: A = random_matrix(GF(997),1000) sage: time p=A.charpoly() CPU times: user 9.24 s, sys: 0.08 s, total: 9.32 s Wall time: 9.33 s sage: A = random_matrix(GF(997),1500) sage: time p=A.charpoly() CPU times: user 30.74 s, sys: 0.24 s, total: 30.98 s Wall time: 30.98 s sage: A = random_matrix(GF(997),2000) sage: time p=A.charpoly() CPU times: user 64.48 s, sys: 0.36 s, total: 64.83 s Wall time: 64.83 s sage: A = random_matrix(GF(997),3000) sage: time p=A.charpoly() CPU times: user 208.93 s, sys: 0.78 s, total: 209.71 s Wall time: 209.78 s sage: A = random_matrix(GF(997),4000) sage: time p=A.charpoly() CPU times: user 512.62 s, sys: 1.29 s, total: 513.91 s Wall time: 513.99 s sage: With the old modp code: sage: A = random_matrix(GF(997),500) sage: time p=A.charpoly() CPU times: user 2.12 s, sys: 0.04 s, total: 2.16 s Wall time: 2.26 s sage: A = random_matrix(GF(997),1000) sage: time p=A.charpoly() CPU times: user 9.21 s, sys: 0.12 s, total: 9.34 s Wall time: 9.34 s sage: A = random_matrix(GF(997),1500) sage: time p=A.charpoly() CPU times: user 30.39 s, sys: 0.23 s, total: 30.62 s Wall time: 30.71 s sage: A = random_matrix(GF(997),2000) sage: time p=A.charpoly() CPU times: user 74.39 s, sys: 0.40 s, total: 74.79 s Wall time: 74.79 s sage: A = random_matrix(GF(997),3000) sage: time p=A.charpoly() CPU times: user 178.98 s, sys: 0.96 s, total: 179.94 s Wall time: 180.05 s sage: A = random_matrix(GF(997),4000) sage: time p=A.charpoly() CPU times: user 518.67 s, sys: 1.46 s, total: 520.13 s Wall time: 520.16 s So I guess we can live with the slow code for a point release or two. 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: Coercion merge, 3.0.6, 3.1 and 3.1.1
On Jul 19, 8:16 am, Jason Grout [EMAIL PROTECTED] wrote: mabshoff wrote: Hello folks, due to the ssmod and the gfe2 bug in Sage we really want to have a stable release out by Wednesday when William gives his talk at ISSAC. Since we don't want to cut it too short that means that I just moved all but the above two tickets to 3.1.1. Any new ticket should be a real blocker, i.e. segfault fix, horrendous memory leak or some major generic embarrassment. So the plan in detail: 3.0.6: Sunday/Monday with binaries done by Tuesday 3.1: Should open right after 3.0.6 and the first patch in should be Robert's new parent.pyx. To quote Robert from http://groups.google.com/group/sage-devel/msg/6162d308061333ef [quote] In terms of status, I got the new parent under the old parent (and all doctests passing) and swapped out the coercion models (in the process of writing a compatibility layer for old parents). When this goes in, we can start writing against the new model. QQ, RR, CC, etc. will probably be the best examples. [end quote] Then we might or might not merge some other tickets depending on Robert's wishes/stability. 3.1.1: Merge as usual Thoughts? What do you see as the timeline for releasing 3.1.1 (which I assume is the next normal release for merging new things in). Before 8 Aug, hopefully? I am pretty clueless. Depending on how deep the parent.pyx merge is and if Robert insists/recommends a coercion patch only release we will take it from here. Thanks, Jason Having thought about it on the train trip to Linz I now believe that 3.1 should be more or less a regular release, but I will likely do an alpha0 with just parent.pyx patched to valgrind it and catch any potential regressions that way. But I will wait on Robert to speak up on this point since it is all his baby and I am sure we can all agree that his call will be the right one, so I am bowing to the master of coercion (and his merry band of minions :)) 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: Coercion merge, 3.0.6, 3.1 and 3.1.1
On Jul 19, 7:24 am, John Cremona [EMAIL PROTECTED] wrote: When you say Any new ticket should be a real blocker I presume you only actually mean tickets asking for resolution before 3.1.1? I recently created a new ticket which can certainly wait until 3.1.1 (it's not even a bug, but a new feature). John Hi John, the idea is to get an rc0 out before the end of Sunday GMT. I have a list of blockers we are considering, but one can always suggest things to be included. From past experience even innocent looking patches have required a complete new release cycle which we want to avoid this time since William is speaking at ISSAC on Wednesday, so we want the binaries done and mirrored out on Tuesday night. Re 3.1 vs 3.1.1 see my comment below I made to Jason's post. The dates were pulled out of thin air and the hope is to start doing releases somewhat faster and more regular again. Due to Dev1 and the L functions workshop and various other things I feel I have dropped the ball a little in the last couple weeks. 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: Suggestion components to add onto SAGE
On Jul 19, 3:39 pm, David Joyner [EMAIL PROTECTED] wrote: On Sat, Jul 19, 2008 at 6:10 PM, q10 [EMAIL PROTECTED] wrote: Hello: It has come to my attention that SAGE does not have a units-conversion program component (maybe it has; if it does, please show me). I recommend adding the GPLed unit conversion program called ConvertAll (http://www.convertall.bellz.org/) I believe it is written with Python, so integration of it into SAGE should not be too difficult. From the above webpage: ConvertAll is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either Version 2 of the License, or (at your option) any later version. ... ConvertAll requires the following libraries: * Qt (Version 4.1 or higher - see Trolltech for more information) Qt itself is currently considered a deal breaker in the core of Sage * Python (Version 2.3 or higher) * PyQt (Version 4.0 or higher - see Riverbank for more information) Requiring Qt might be a problem. However, I don't see why a units-conversion package requires a graphics library like Qt. Indeed, the web site says Command line options are available to do conversions without the GUI. Yeah, it seems that the GUI should be the optional thing. Qt and PyQt introduce a massive amount of overhead for something that should be a nice and self contained little library. It seems that SAGE is also missing a geometry sketchpad component. It would be nice to add the GPLed 2D/3D geometry sketchpad program known as Geogebra (http://www.geogebra.org). This has been discussed before. I think it has serious licensing incompatibility issues and also uses java. Yeah, the license issue is the killer here. Finally, there is a very good graphing program known as K3DSurf (http://k3dsurf.sourceforge.net/) that makes very good 3D/4D/5D graph models. Please consider adding this program into SAGE as well. Were you able to download and compile the source code for this? The website (or my computer) was very slow for me, so I gae up looking. If you did so, what OS did you use? Do you know the license for k3dsurf? Thanks for hearing my suggestions, Please reply, -q10 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: Coercion merge, 3.0.6, 3.1 and 3.1.1
On Jul 20, 12:20 am, Robert Bradshaw [EMAIL PROTECTED] wrote: On Jul 19, 2008, at 7:09 AM, mabshoff wrote: Hello folks, Hi, due to the ssmod and the gfe2 bug in Sage we really want to have a stable release out by Wednesday when William gives his talk at ISSAC. Since we don't want to cut it too short that means that I just moved all but the above two tickets to 3.1.1. Any new ticket should be a real blocker, i.e. segfault fix, horrendous memory leak or some major generic embarrassment. So the plan in detail: 3.0.6: Sunday/Monday with binaries done by Tuesday 3.1: Should open right after 3.0.6 and the first patch in should be Robert's new parent.pyx. To quote Robert from http://groups.google.com/group/sage-devel/msg/6162d308061333ef [quote] In terms of status, I got the new parent under the old parent (and all doctests passing) and swapped out the coercion models (in the process of writing a compatibility layer for old parents). When this goes in, we can start writing against the new model. QQ, RR, CC, etc. will probably be the best examples. [end quote] Then we might or might not merge some other tickets depending on Robert's wishes/stability. The new parent under the old parent is a non-negligible performance regression due to def calls being made in the coercion system. This will be fixed when I finish inserting the new coercion model core (as it will be able to use cdef calls on Parent again). This looks like it should be pretty smooth--under a week if all goes well (in which case a merge for 3.1.1 would be a good idea) or more (in which case don't wait on it). So far this second step has gone surprisingly well, though I only worked on it a couple hours one night so I'm at most half way into it. The dates for all the upcoming milestones are just guesses and we will very likely do 3.0.x releases until something big comes up that justifies bumping the release number. Something big would be official Solaris, 64 bit OSX or Cygwin support for example, in which case new coercion would become 3.2 for example. The main goal here is to have a clear and easy to remember point in the release history where we know that 3.x has new coercion while if we merge it in 3.x.y to 3.x.y +1 this will not be as clear. - 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.0.6.alpha0 released
On Jul 19, 10:01 am, Andrzej Giniewicz [EMAIL PROTECTED] wrote: Hi, after some sniffing around, I noticed that for me (see bottom of mail for gcc version) techyon needs to be compiled with make linux (with disabled threads) or with -fno-crossjumping -fno-reorder-blocks added to Make-arch file at line 1134 (linux-thr target, after -O6) - Hi, can you dial that down to -O3 and if that fails to -O2? I do not believe that -O6 does anything beyond -O3, but I am too lazy to look it up now. Either way, -O6 is likely counterproductive. second is better solution I think... both solutions fixes segfault, I don't know where the problem is, it can be gcc bug so special case for it might need to be added, does anyone have same gcc to verify that's it's gccs fault or not? cheers, Andrzej. [EMAIL PROTECTED] ~]$ gcc -v Using built-in specs. Target: i686-pc-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.1 20080626 (prerelease) (GCC) You are also running a prerelease of gcc 4.3.1, so this might be a factor here. In the end it does not matter since we cannot just tell people to upgrade their broken compiler, but we should at least attempt to work around some problems like the above. 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 + py.test fails
On Jul 20, 8:20 am, Ondrej Certik [EMAIL PROTECTED] wrote: On Sun, Jul 20, 2008 at 4:48 PM, William Stein [EMAIL PROTECTED] wrote: Hi, SNIP BTW, here is another creepy thing, that maybe is a bug in Sage: $ gedit gedit: symbol lookup error: /usr/lib/libxml2.so.2: undefined symbol: gzopen64 $ I was just about to report this as a grave bug in Debian, but before I did: $ ldd /usr/lib/libxml2.so.2 linux-gate.so.1 = (0xb7f92000) libdl.so.2 = /lib/i686/cmov/libdl.so.2 (0xb7e4e000) libz.so.1 = /home/ondra/ext/sage/local/lib/libz.so.1 (0xb7e38000) libm.so.6 = /lib/i686/cmov/libm.so.6 (0xb7e11000) libc.so.6 = /lib/i686/cmov/libc.so.6 (0xb7cb6000) /lib/ld-linux.so.2 (0xb7f93000) so I just removed the line: export LD_LIBRARY_PATH=/home/ondra/ext/sage/local/lib from my bashrc and all works again. So this is not the way how to setup sage. It's actually quite annoying, that you can use either Sage or gedit, but not both in the same terminal. Ok, you may say forget about systemwide python, just use Sage as it is, take it or leave it. I am please to say: I told you so. Running Sage with the system python introduces all kinds of the above crap. And as William pointed out it is not a bug and we will not fix it since we cannot fix it. There are myriads of distros out there and no way to make Sage+system Python work since the libraries they ship are in the end mutually incompatible. This is one giant quagmire and there is no way out of it besides using the Debian packages that Tim has been working on. Ok, first, it's not the way I'd like to work, but ok, but it won't allow me to use gedit either... Try this: sage: os.system(xclock) 0 this works anc xclock comes up, but this doesn't: sage: os.system(gedit) ** (gedit:26452): WARNING **: Error initializing Python interpreter: could not import pygtk. ** (gedit:26452): WARNING **: Please check the installation of all the Python related packages required by gedit and try again. ** (gedit:26452): WARNING **: Cannot load Python plugin 'Python Console' since gedit was not able to initialize the Python interpreter. gedit: symbol lookup error: /usr/lib/libxml2.so.2: undefined symbol: gzopen64 32512 I don't know, but I think Sage should not be messing with my system. Sage is not messing with your system, you *choose* to do things with LD_LIBRARY_PATH and it blew up in your face. See another I told you so coming? :p When you launch an application from proper Sage that is not $SAGE_LOCAL/bin it will use the original LD_LIBRARY_PATH. In case python based applications we might also have to set PATH back to its original so that the system Python is picked up, but then all the Sage binaries in $SAGE?LOCAL/bin are not available, so I do not see any solution that will make everybody happy. So this makes me think that maybe exporting the variables so that they work in the whole terminal (thus allowing me to use systemwide python) is not a good thing, unless there is a robust way to fix the above problems. I think the problem is unfixable. Either way you chose to fix the issue I can break it. Believe me: I have thought about the issue for a while :) I'll try to investiage the other way round then, e.g. setting up paths in sage, so that it imports my systemwide library and the current revision of sympy, that I want to test. But I don't like this at all, because this makes Sage a full blown application, not a library, that can be reused in other projects. Sage is and never has been meant to be a library in the sense that Sympy is. In itself Sage is very complex and we want to run on operating systems besides Debian/Linux, so I see no reason to cater to any specific distribution of Linux and just use the system zlib will not work everywhere. Sage is self contained for a reason and if we relied on more components by the system Sage would not work very well. Just think of the rather large number of combinations when only taken ten of Sage's components and using the system's instead. I have no desire to debug such a mess. You can fix the above issue by skipping the build of zlib by fixing deps in $SAGE_ROOT/spkg/standard. But that will require rebuilding Sage from source unless you are willing to remove libz* and the headers and then rebuild all components of Sage that link against libz. So a rebuild from scratch in another directory will be quicker for you since it will take you longer to figure out what to do since you are not as familiar with Sage's components as I am :) But even then it will only be a question of time until something else blows up. That is why I strictly refuse to support Sage being used in that way in the first place. Ondrej 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
[sage-devel] Re: CUDA and Sage
On Jul 20, 9:21 am, Simon Beaumont [EMAIL PROTECTED] wrote: Hi Simon, I am just about to embark on integrating come CUDA libraries into sage. I was not sure of the best route to go - I am considering the pycuda libraries as a starting point - this a pure kernel approach - I but would also like to get the CUDA blas and fft libraries integrated. Various people have started looking into this, but so far no one has produced code. One big issue (at least for me) with pycuda is the requirement for boost, but I am not sure how that could be overcome. Since I am personally only interested in the CUDA BLAS the suggested way to hook it into Sage was directly via Cython, but recreating pycuda via Cython seems like a large waste of effort and should be avoided at all costs. The main issue with boost I see is that PolyBoRi ships with a subset of boost and installs it into $SAGE_LOCAL/include/boost. I assume that it will not be enough of boost, i.e. boost python is not part of it. Since PolyBoRi also has an interface to Python using boost Python we might be able to add the bits needed to the polybori.spkg, otherwise I see potentially huge trouble by colliding boost versions in the tree. And shipping boost itself is not really an option due to its rather large size. (I think cuda-python) can do this. I'm sure I'm not the first down this road and wondered which would be the most useful. I'd also appreciate some tips and pointers into integration of sage arrays and matrices to make this as native as possible. I think using numpy arrays here for now might be the way to go, but that limits you to numpy data types. Since we are talking about numerical computations it seems that we will not lose functionality here at all. Of course this work would be shared with the community. I have plans to make some CUDA hardware available over the web using sage and have also have some longer term plans for a modeling environment based on it. Cool. There are various people waiting to but the next generation of Tesla hardware, i.e. the one that actually provides IEEE doubles. I am basically waiting for it to become available since the things I am interested in do require IEEE precision and close to IEEE is not enough. Any advice and pointers most welcome. Please keep us up to date how things are going and let us know about any problems you have. This is an area we should definitely make some progress this year. Regards, Simon 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: sagemath.org website info #2
On Jul 20, 9:43 am, Dr. David Kirkby [EMAIL PROTECTED] wrote: On Jul 20, 10:03 am, mabshoff [EMAIL PROTECTED] wrote: Hi David, Ok, we had some discussions off list about Solaris support in general and back then the possibility of setting up a Sparc with Solaris 8 came up, so I could have my own box to do the port. I've very rarely to seen Solaris 8 mentioned on comp.unix.solaris, but I guess that people reading that are more likely to be keen on Solaris, and so run late editions. Ok, good to know. I don't know the rules over there, so thanks for clearing that up. That was the last I knew. I was going to contribute something, and have an account, but this messing around to generate Solaris 8 x86 packages put me off. I can imagine. Solaris 9 on x86[-64] was never officially available IIRC and Solaris 8 on x86[-64] ought to be a rarity these days since Sun treated I've run Solaris 7 on x86, but not any more. Not sure what other CDs I might have in folders somewhere. Sure, pre Solaris 9 existed for x86, but I think it was never widely used in production settings. My main goal is to have binaries for Sage on Solaris installs so that we cover the widest possible number of installs while minimizing the pain of porting and that means Sparc Solaris 9 and later and x86[-64] Solaris 10 and later. Hehe, old hardware is fun, but I do not do any work on them. I've not a GPIB board (for controlling test equipment) which is on sbus. I should hang on to an old SPARC for that, as they make cheap and small instrument controllers. But realistically, they are not much use for much else now. Yes, that is true. Some little birdy told me a while back that a large university in Canada is still running their Sparc boxen with Solaris 8 I was going to say universities might suffer this problem. Where I worked at a uni we seem to have some really old stuff around. The system admin seemed to be stuck in the dark ages. Yeah, but if it ain't broken don't fix it :) Ok, so there is no annoying IMHO Debian policy like thing for Sunfreeware it seems which will make a monolithic tarball much easier. I don't think Steve at Sunfreeware would try to break it up. I think he would just put it up as a large package. But I've not tried asking him. Ok. Ultimately, it would be nice to get Sun to put it on the Solaris Express DVD, but I image that would not be quite so easy to do. Yes, one would imagine competition here is rather fierce. Especially since Sage is so large. I imagine its easier to get a 10 kb utility added than 100's of MB. But Sun must be aware there is a market for this sort of sortware on Solaris - they have worked quite closly with Wolfram Reseach. Of course, there is nothing to stop you creating your own OpenSolaris live DVD and distributing that. Or asking any of the groups that do produce one to add Sage. Yes, adding Sage to more repos/listing has been something that Harald has already mentioned in this thread. Sure, but conflict of interest is one thing, acting on it is another. I've got nothing to suggest he will. I may be wrong, but I get the feeling Sunfreeware is not updated as often as it used to be. Perhaps Steve has other more pressing commitments. Is he the only one who can update? Since we do a binary on average every two weeks having short turn around times would be a good thing. If we released once a year this would obviously much less of an issue. Do you mean addons specifically for Solaris or for MMA in general? Mathematica in general. I'm not aware of any Solaris-specific Mathematica add-ons. But there have been a few discussions on comp.soft- sys.math.mathematica about marketing of add-ons. I've also had private emails from a couple of people that do sell them. I got the feeling that it was hardly worth their while. Interesting. It seems that MATLAB with its toolboxen is a much more interesting market to be in. Sure, installing Sage was always meant to be easy and since there is only one true Solaris with a rather stable ABI I am confident that binaries will work on average much better than on some random Linux distribution. But I guess time will tell. Yes, I would expect them too to. There should not be all this you need to use kernel x.y on distribution z stuff you get on Linux. It is mostly about the glibc shipped and to a lesser extend to all the various compiler run times floating around, the kernel in our case has very little impact. Dave 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: sagemath.org website info #2
On Jul 19, 11:53 pm, Dr. David Kirkby [EMAIL PROTECTED] wrote: On Jul 19, 11:38 pm, mabshoff [EMAIL PROTECTED] wrote: Hi, On Jul 19, 2:45 am, Dr. David Kirkby [EMAIL PROTECTED] wrote: On 18 Jul, 20:33, Harald Schilly [EMAIL PROTECTED] wrote: SNIP 12) Once a Solaris port is done, try to get Blastwave and Sunfreeware to keep packages. I'm not sure if Blastware will, as I think they want Solaris 8 packages. But I guess if it does not run on Solaris 8, they might accept it. There is no way I personally will spend any time at all on Solaris 8, but I will certainly accept patches. I'm not sure of their exact policy, but I believe if the software runs under Solaris 8, the package they keep must run under Solaris 8. That is a pain if you produce a package for them, as it means either you need a Solaris 8 boxes (SPARC and x86), or you use their box, but that is quite complex, as you don't get root access. Ok, we had some discussions off list about Solaris support in general and back then the possibility of setting up a Sparc with Solaris 8 came up, so I could have my own box to do the port. I suspect if you say this software is specified to run under Solaris 10 or greater, then they would accept it and not insist it runs under 8. I think the issue is that if the software runs under 8, the package must be suitable for a Solaris 8 system. I'm guessing the same must be true for x86/SPARC - they can't insist you build both packages if the software only runs on one. But if it does run on both, they insist you to build it on both. Ok, good to know. I don't know the rules over there, so thanks for clearing that up. I am willing to do Solaris 9 on Sparc, but Solaris 9 on x86[-x64] is likely not going to happen either, while the same thing about patches applies. I don't blame you - I would do the same. Solaris 9 on x86[-64] was never officially available IIRC and Solaris 8 on x86[-64] ought to be a rarity these days since Sun treated x86[-64] as a red headed step child up until the Solaris 10 release IMHO. So there should be no significant in relation even to the Solaris install base for pre Solaris 10 on x86[-64]. The only downside is the SPARC versions would not run on the earlier 32-bit systems (SPARC 4, SPARC 5, SPARC 10, SPARC 20 etc.) But given an Ultra 5 is almost given away (I've seen $5 mentioned for them), there seems to be no real reason to stick with these very old machines (says he who has got 5 x SPARC 20 in his garage!!!). Hehe, old hardware is fun, but I do not do any work on them. Even compiling ATLAS on such a box is likely a huge pain in the ass and not worth it IMHO. We can always use the Sunperflib obviously. interested in the future Solaris 11/Express Edition. Various people have told me that many installs either stuck with Solaris 8 or went to Solaris 10, i.e. not many installs stuck with Solaris 9. In any case, I think people running software like Sage are not not going to be in a position of not upgrading a machine from 8 or 9 due to company policy, or the fact their vendors database is not specified etc. Yes, that is true. Some little birdy told me a while back that a large university in Canada is still running their Sparc boxen with Solaris 8 and they do have a lot of them according to my source. But there is only so much time I can spend on any given day and unless people speak up and let me know that there is significant interest in Sage on Solaris 8 [and to be mean I have to add it helps a lot to have some people with significant political pull here] it will not be high on the list of things to do. getting paid to support Solaris 10 and Express (and I guess 11 once it is out) that is where my energy will go. In the end I believe that our own repo will always be more current and I have no interest in breaking Sage up into packages. I am willing to help if other people want to attempt that for Solaris. I think it would be useful if a single package for Sage on Sunfreeware and another on Blastwave. Simply because a lot of people use them sites, and so are more likely to install Sage if found there. Ok, so there is no annoying IMHO Debian policy like thing for Sunfreeware it seems which will make a monolithic tarball much easier. Ultimately, it would be nice to get Sun to put it on the Solaris Express DVD, but I image that would not be quite so easy to do. Yes, one would imagine competition here is rather fierce. You might get some problems getting Sunfreewave to have a package, as the owner of that site (Steve Christensen) works for Wolfram Research, produces his own Mathematica addon and moderates comp.soft-sys.math.mathematica. I suspect, given he does not allow other software to be discussed on comp.soft-sys.math.mathematica, he might be reluctant to produce a package for Sage. But you can only ask. Well, let's hope for the best and assume that he will be a good guy
[sage-devel] Re: sage + py.test fails
On Jul 20, 11:20 am, Ondrej Certik [EMAIL PROTECTED] wrote: On Sun, Jul 20, 2008 at 6:38 PM, mabshoff [EMAIL PROTECTED] wrote: SNIP Hi Ondrej, But even then it will only be a question of time until something else blows up. That is why I strictly refuse to support Sage being used in that way in the first place. Sage should use its own versions of libraries for the reasons you stated. One exception could be Python, e.g. there could be an easy way to compile Sage with the systemwide python, because (imho) Python doesn't change that much, so it could work in most cases. It works even now. Nope, it does not work for example on OSX. With a python 2.5.2 on Linux x86 and x86 it should mostly work, but on Linux Itanium it does not work since in the official 2.5.2 readline is busted. On Solaris and OSX there is also the multilib issue, i.e. 32 vs. 64 bit are supported on the same machine. So I disagree that it mostly works and I consider it a bad, bad idea to even give the user some simple option to make Sage build with the system python. It is trivial to do if you know your way around the Sage build system, but that actually means that one can likely fix issues oneself like in your case. Everybody else just has to play by the rules. And I won't post the obvious one line diff to make Sage with system python at build time work. If you need to ask you shouldn't play with something that could cause endless trouble :p As chatted on IRC, the LD_LIBRARY_PATH problem *might* get fixed using: http://packages.debian.org/sid/chrpath Yes, this certainly offers possibilities. And the other PATH stuff are fixable too. Ondrej 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: Package management and versioning
On Jul 20, 3:27 pm, William Stein [EMAIL PROTECTED] wrote: On Sun, Jul 20, 2008 at 11:59 PM, mabshoff [EMAIL PROTECTED] wrote: On Jul 20, 2:39 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi folks, Hi Vincent, Looking at the way that sage builds and installs its packages, I didn't see an easy way to remove an optional package (say in case it breaks something, or you don't need it anymore) ; has it been considered to use something like GNU stow or my favorite, graft (http://www.gormand.com.au/peters/tools/graft/graft.html) ? The problem of removing optional packages has some up before, but there is no solution. The general idea is to have each package installed inside its own directory (say, $SAGE_ROOT/spkg/graft/package-1.0.0-p0), and to only put the directory structure with links to the files inside $SAGE_ROOT/ local. It has plenty of advantages : - trivial to see what is installed (that is just the list of subdirectories of graft/ to which there are symlinks). - easy to deactivate a package (just remove the links) without removing the actual files, so that one can re-activate it later. - easy to remove a package. - clean upgrades of packages : just remove the previous version, and be sure that no obsolete files remain in local/. Also one can quickly switch between two versions of a package for debugging purposes. - mixing packages installed as they are currently with grafted packages poses no difficulty, they can cohabit peacefully. Packages need to be configured with --prefix=$SAGE_ROOT/local, installed with DESTDIR=somewhere, and then somewhere/$SAGE_ROOT/local has to be renamed to $SAGE_ROOT/spkg/graft/packagename-v.er.si-on before graft (or whichever one) is called to put the links in place. I am more than sure that a lot of packages do not honor DESTDIR. Those can be likely fixed. There is also a lot of code that does not use configure make make install. How is that dealt with? What about python packages? Or do you only want to deal with optional packages? Yes, I think he definitely claims to *only* want to deal with optional packages. Sure, but biopython and trac are for example two optional packages that are python. We can achieve the same solution as graft by setting the prefix during the build process and then expanding PATH and LD_LIBRARY_PATH during the startup of Sage. That way can we can move over the optional spkgs that work. But there is the obvious problem that installs with existing optional spkgs that are upgraded will end up with loads of files in SAGE_LOCAL as well as SAGE_LOCAL/ FOO_OPTIONAL. I think it is worth playing with since the removal of optional spkgs is good. That way we could probably also easily deal with the doctest optional spkgs more fine grained problem since we will have to write some kind of infrastructure that deals with what optinal spkg is installed. For commercial code like MMA and Maple we could create some fake optional spkgs for testing purposes. There are two drawbacks to the system : - it creates LOTS of symlinks (one per regular file). Not sure of the gravity of that one. It is mostly ok, but I have had more than my fair share of experiences with NFS+symlinks on Linux, so I am not looking forward there. - (the big one) in principle, CFLAGS etc will look inside $SAGE_ROOT/ local and happily follow the symlinks. But some packages may be too eager and figure out the real path to the real file in graft/ packagename-..., and then look for them there instead of in $SAGE_ROOT/ local at runtime. Then if the library is upgraded and the old one removed, even though the links in $SAGE_LOCAL are of course upgraded in the process, things might break. This is quite rare I believe (I only saw it when running a version of gcc installed this way, which figures out the current location of the executable at runtime and puts it inside the built executables as an RPATH), and of course the fix is easy, simply unlink the previous version but keep the necessary old files ... So, is that worth looking into ? Yes, it is certainly something that sounds interesting enough to play with, but while it likely works on Unix/Linux and OSX I doubt it will work on native Windows. So that could be a major showstopper to its adaption. It could also mean that we just don't deploy it on windows, i.e., on windows one doesn't have an uninstall optional package option. Sure, but with the proposal outlined above we could have our cake and eat it, too. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Package management and versioning
On Jul 20, 2:39 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi folks, Hi Vincent, Looking at the way that sage builds and installs its packages, I didn't see an easy way to remove an optional package (say in case it breaks something, or you don't need it anymore) ; has it been considered to use something like GNU stow or my favorite, graft (http://www.gormand.com.au/peters/tools/graft/graft.html) ? The problem of removing optional packages has some up before, but there is no solution. The general idea is to have each package installed inside its own directory (say, $SAGE_ROOT/spkg/graft/package-1.0.0-p0), and to only put the directory structure with links to the files inside $SAGE_ROOT/ local. It has plenty of advantages : - trivial to see what is installed (that is just the list of subdirectories of graft/ to which there are symlinks). - easy to deactivate a package (just remove the links) without removing the actual files, so that one can re-activate it later. - easy to remove a package. - clean upgrades of packages : just remove the previous version, and be sure that no obsolete files remain in local/. Also one can quickly switch between two versions of a package for debugging purposes. - mixing packages installed as they are currently with grafted packages poses no difficulty, they can cohabit peacefully. Packages need to be configured with --prefix=$SAGE_ROOT/local, installed with DESTDIR=somewhere, and then somewhere/$SAGE_ROOT/local has to be renamed to $SAGE_ROOT/spkg/graft/packagename-v.er.si-on before graft (or whichever one) is called to put the links in place. I am more than sure that a lot of packages do not honor DESTDIR. Those can be likely fixed. There is also a lot of code that does not use configure make make install. How is that dealt with? What about python packages? Or do you only want to deal with optional packages? There are two drawbacks to the system : - it creates LOTS of symlinks (one per regular file). Not sure of the gravity of that one. - (the big one) in principle, CFLAGS etc will look inside $SAGE_ROOT/ local and happily follow the symlinks. But some packages may be too eager and figure out the real path to the real file in graft/ packagename-..., and then look for them there instead of in $SAGE_ROOT/ local at runtime. Then if the library is upgraded and the old one removed, even though the links in $SAGE_LOCAL are of course upgraded in the process, things might break. This is quite rare I believe (I only saw it when running a version of gcc installed this way, which figures out the current location of the executable at runtime and puts it inside the built executables as an RPATH), and of course the fix is easy, simply unlink the previous version but keep the necessary old files ... So, is that worth looking into ? Yes, it is certainly something that sounds interesting enough to play with, but while it likely works on Unix/Linux and OSX I doubt it will work on native Windows. So that could be a major showstopper to its adaption. /vincent 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: Trivial problems in the sage 3.0.5 distribution
On Jul 20, 9:13 pm, Timothy G Abbott [EMAIL PROTECTED] wrote: Hi Tim, Below I list a large number of trivial problems in the Sage 3.0.5 distribution tarball that the Debian automatic package checking tools detected. None of the problems below have any functional effect, they're just things that are likely mistakes and are probably worth correcting. If desired, I can make trac tickets for these issues, though I think they're trivial enough that it may be easiest for Michael to just go through and fix them all the next time he rolls a relevant spkg. I would suggest you just split up the issues by spkgs and make tickets. I can then take care of the actual changes. I've sorted them by spkg to make this easy to handle in one quick pass. :) -Tim Abbott Cheers, Michael # Scripts missing #!/bin/sh lines in extcode-3.0.5.spkg: mirror pari/dokchitser/testall spkg-dist # Files unnecessarily marked as executable in extcode-3.0.5.spkg javascript/jsmath/plugins/autoload.js javascript/jsmath/plugins/CHMmode.js notebook/javascript/jsmath/plugins/autoload.js notebook/javascript/jsmath/plugins/CHMmode.js notebook/javascript/farbtastic/marker.png # Empty directories in extcode-3.0.5.spkg # (These look like they might have a purpose, but I'm not sure) dist/ gap/user/ genus2reduction/ gnuplot/ macaulay2/user/ maple/user/ mathematica/user/ matlab/user/ octave/user/ sage/user/ singular/user/ sobj/ # Scripts missing #!/bin/sh lines in sage_scripts-3.0.5.spkg: sage-pull sage-push sage-mirror sage-mirror-darcs-scripts sage-osx-open # Scripts missing #!/usr/bin/python lines in sage_scripts-3.0.5.dpkg: sage-startuptime.py sage-gdb-pythonstartup dsage_setup.py # Files unnecessarily marked as executable in sage_scripts-3.0.5.spkg sage-banner sage-gdb-commands sage-maxima.lisp # Scripts that use #!sage or #!sage.bin as their interpreter in sage_scripts-3.0.5.spkg # You want to use #!/usr/bin/env sage sage-ipython sage-location sage-preparse sage-run sage-run2 # Weird files in sage_scripts-3.0.5.spkg marked executable sage-README-osx.txt (duplicate of file of the same name in the root of the sage distribution) sage-verify-pyc (this one is just weird) # Scripts missing #!/bin/sh lines in sage-3.0.5.spkg: pull install # Scripts missing #!/usr/bin/python lines in sage-3.0.5.dpkg: sage/dsage/misc/hostinfo.py sage/dsage/scripts/dsage_setup.py # Files unnecessarily marked as executable in sage-3.0.5.spkg sage/graphs/planarity/graphEmbed.c sage/graphs/planarity/graphIO.c sage/graphs/planarity/graphIsolator.c sage/graphs/planarity/graphNonplanar.c sage/graphs/planarity/graphPreprocess.c sage/graphs/planarity/graphStructure.c sage/graphs/planarity/graphTests.c sage/graphs/planarity/listcoll.c sage/graphs/planarity/planarity.c sage/graphs/planarity/stack.c # Other files unnecessarily marked as executable sage-README-osx.txt (in the root of the sage distribution) # Scripts missing #!/bin/sh lines in examples-3.0.5.spkg: programming/standalone_scripts/python/test # Empty directories in examples-3.0.5.spkg examples/misc/ # Scripts that use #!sage or #!sage.bin as their interpreter in examples-3.0.5.spkg # You want to use #!/usr/bin/env sage programming/standalone_scripts/python/binom programming/standalone_scripts/python/factor programming/standalone_scripts/sage/factor.sage programming/standalone_scripts/sage/simple.sage # Empty files in doc-3.0.5.spkg const/.doctest/err const/tut.toc doc/.doctest/err doc/.doctest/out html/const/images.idx html/inst/images.idx html/inst/index.dat html/prog/images.idx html/prog/index.dat html/ref/images.idx html/whatsnew/index.dat inst/inst.idx overviews/.doctest/err overviews/.doctest/out prog/.doctest/err prog/.doctest/out prog/prog.idx ref/ref.idx ref/ref10.syn ref/ref11.syn ref/ref12.syn ref/ref13.syn ref/ref14.syn ref/ref15.syn ref/ref16.syn ref/ref17.syn ref/ref18.syn ref/ref19.syn ref/ref2.syn ref/ref20.syn ref/ref21.syn ref/ref22.syn ref/ref23.syn ref/ref24.syn ref/ref25.syn ref/ref26.syn ref/ref27.syn ref/ref28.syn ref/ref29.syn ref/ref3.syn ref/ref30.syn ref/ref31.syn ref/ref32.syn ref/ref33.syn ref/ref34.syn ref/ref35.syn ref/ref36.syn ref/ref37.syn ref/ref38.syn ref/ref39.syn ref/ref4.syn ref/ref40.syn ref/ref41.syn ref/ref42.syn ref/ref43.syn ref/ref5.syn ref/ref6.syn ref/ref7.syn ref/ref8.syn ref/ref9.syn ref/rings.py texinputs/python. tut/.doctest/err tut/glossary.tex version # Empty directories in doc-3.0.5.spkg auto/ overviews/a_tour_of_sage/sage_notebook/worksheets/root/0/cells/0/ overviews/a_tour_of_sage/sage_notebook/worksheets/root/0/cells/1/ overviews/a_tour_of_sage/sage_notebook/worksheets/root/0/cells/2/ overviews/a_tour_of_sage/sage_notebook/worksheets/root/0/cells/3/ overviews/a_tour_of_sage/sage_notebook/worksheets/root/0/cells/4/
[sage-devel] Re: Package management and versioning
On Jul 20, 4:21 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, OK, so who knows a clever way to detect which files were added/changed in a directory structure? Quick and very dirty : 'find . -cmin -5' (files modified less than 5 minutes ago). Not even close :). There are packages that install in less than 10 seconds. Quick and dirty : ls -lR before ; make install ; ls -lR after ; diff -u before after | sed -e 'whatever_to_prettify_the_output' but it will look kind of ugly. Better. Better : make a decent snapshot of the tree state before installing, keeping track of filename, modification time, size, possibly some md5 checksum or something (say in an sqlite database file, easy to do in python), and compute the difference after running make install. I am not so sure this is worth it. You are basically writing apt/rpm for user space. And we like to reuse components if they exist and fit the bill :) But once you are there, you might as well keep the snapshot, add the package name as one of the file attributes, and bam you have a package management system ! But this is IMHO not KISS - a guiding principle of Sage :). Right now a fresh 3.0.6.alpha0 contains about 107235 files in $SAGE_LOCAL when following symbolic links. That is a lot of IO and disk seeks to do to upgrade for each package. One thing that endlessly annoys me about rpm for example is its sluggish performance, which is largely rooted in its db backend, i.e. berkeley db IIRC. On top of that sqlite's performance sucks even worst. And you also introduce another point of failure where up to now KISS had provided a nearly perfect solution, i.e. any sort of db corruption will break Sage's upgrade system. /v I *really* like the idea for optional packages, but for the core there are various problems you will have to deal with: * Updating one spkg often forces the update of another spkg. For example updating clisp forces a recompile of Maxima. So you cannot just switch between two clisp installs and expect things to work. And there are even more complicated dependencies in the default tree. * The Sage library is special and there are loads of subtle dependencies. For example 3.0.3 to 3.0.4 upgraded LinBox from 1.1.5 to 1.1.6.rc0. A seemingly innocent update until you learn that this also means that the name of the wrapper library has changed. So running a 3.0.4 or later Sage library with a linbox-1.1.5 or earlier will cause Sage not to even start any more. In some cases it is imaginable that Sage does start but will exhibit subtle bugs since we fixed something in FOO-1.3.3.p12, but for some reason one user ends up running FOO-1.3.3.p11. Happy bug hunting in that case. * sage -upgrade will be completely broken by introducing the framework you envision. We could disallow upgrading of Sage at some point so that everybody would be forced to start with a clean tree, but so far that has never happened. * Once sage -upgrade works you will end up with ever increasing install sizes of Sage. You can obviously prune the tree, but just the other day I removed about 5 GB of spkgs from two Sage installs that have been updated for a while and actually caused the notebook to crash due to lack of space on the harddisk. Now imagine what those Sage trees would take up on disc if all those spkgs had not been overwritten. Due to the above I don't think using anything like you propose for the core is a good idea. I have changed my mind on fundamental issues like this before (usually from negative to positive once an implementation actually existed), but so far the bad does outweigh the good by a mile. We do KISS for a reason :) But please do not be discourage to attempt to make it work. 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.6.alpha0 released
On Jul 21, 1:35 pm, Andrzej Giniewicz [EMAIL PROTECTED] wrote: Hi, Hi Andrzej, some new informations, gcc 4.2.4 is also affected by this, but all gcc = 4.2.3 are for sure working right, for 4.2.4 and 4.3.1 tachyon segfaults, I'm looking for some live cd with gcc 4.3 to see if problem is also visible in it or not, it seems to appear in gcc trunk somewhere between 2008-02-01(release of 4.2.3, works) and 2008-05-19 (release of 4.2.4, do not work - this really makes me think it is bug in gcc, minor releases should break optimizer I think, it only happened with major versions in past) - 4.3 was exactly between those two dates so it can narrow search a lot to somewhere in 2008-02-01 and 2008-03-05 or 2008-03-05 and 2008-05-19, also trying to see if it can be reproduced with some small code-only test case... Really nice work. should this become trac ticket? If yes I probably will be able to create one I think... Yes and also check with the upstream author if he already knows about the issue. cheers, Andrzej. 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] Sage 3.0.6.rc0 released
Hello folks, this is 3.0.6.rc0 which should be the last release before the ISSAC 2008 special 3.0.6 release for Wednesday. We fixed a bunch of issues and were a little less conservative than I though, but what could go wrong ;) Sources are at http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0.6/sage-3.0.6.rc0.tar Please report any problem and also success builds. Cheers, Michael Merged in Sage 3.0.6.rc0: #10: Gary Furnish, Dan Grayson: update M2 to the 1.1 release [Reviewed by Michael Abshoff, Mike Hansen] #3345: Mike Hansen, William Stein: trace no longer works in 3.0.2 [Reviewed by William Stein, Mike Hansen] #3669: William Stein: improve multiple_of_order command for torsion subgroups of modular abelian varieties [Reviewed by Craig Citro] #3671: Michael Abshoff, Clement Pernet: Fix ssmod.py doctest failures in Sage 3.0.4 or later [Reviewed by William Stein] #3694: Michael Abshoff, Bill Hart: Update FLINT to the 1.0.13 release [Reviewed by William Stein] #3681: William Stein: modulus() randomly broken for gf2e fields [Reviewed by John Cremona, Michael Abshoff] #3695: Ondrej Certik, John Cremona: Improve factor documentation [Reviewed by William Stein, Martin Albrecht] #3696: Michael Abshoff: Fix gmp.spkg build issue on Solaris [Reviewed by William Stein] #3700: Michael Abshoff: Solaris: Fix ntl build issue [Reviewed by William Stein] #3701: Michael Abshoff: Solaris: fix polybori build due to bashism [Reviewed by William Stein] --~--~-~--~~~---~--~~ 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: Trivial problems in the sage 3.0.5 distribution
Thanks Tim for opening the tickets. For the record those are #3686 - $3690. 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: CUDA and Sage
On Jul 22, 1:29 am, Thierry Dumont [EMAIL PROTECTED] wrote: Francesco Biscani a écrit : With the non-header-only Boost libraries (such as Boost.Python), a possible approach could be that of modifying the build system of a package that uses them to compile and link the needed Boost libraries together with the package's own library. I.e., add the Boost libraries' .cpp files directly in the project's Makefile. The solution I imagine is the following: PolyBoRi has a boost::python interface, but we do not install it since we do not use it. It could easily be added back. That way we do not have two boost installations fighting for supremacy. Since PolyBoRi is in Sage and considered very important Cuda breaking PolyBoRi via its boost requirement is a big no no and will not happen. But the way suggested above will make both camps happy. This might happen in the next week, i.e. we would likely have an optional PyCuda.spkg by Dev1 at SFU. Another possibility (especially if the use of Boost is widespread among Sage packages) would be to compile shared library versions of the needed Boost libraries when building Sage and use them when building the packages that need them. As a Boost user, I just want to say that the Boost installation process is not standard (not using automake, but Jam) and taht this a very long task. Actually, most people use packaged versions (.deb in Debian...) to avoid compilation, but this seems precisely what Sage do not want to do. Yeah, and many times one needs to use boost CVS in order to work around bugs in less common OSes like some BSD flavors. So depending on the system provided boost install is something I would prefer to avoid. Re cwitty: I do not mind if you redid the boost::python code in Cython, I am just saying that I do not have the time to do it myself. But I would be more than happy if you did it :) Yours, t.d. Cheers, Michael -- Thierry Dumont. Institut Camille Jordan -- Mathematiques-- Univ. Lyon I,43 Bd du 11 Novembre 1918, 69622 - Villeurbanne Cedex - France. [EMAIL PROTECTED] web:http://math.univ-lyon1.fr/~tdumont tdumont.vcf 1KDownload smime.p7s 5KDownload --~--~-~--~~~---~--~~ 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: Package management and versioning
On Jul 21, 6:18 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi Vincent, Quick and very dirty : 'find . -cmin -5' (files modified less than 5 minutes ago). Not even close :). There are packages that install in less than 10 seconds. That one was a joke, of course. I have used it occasionally for a punctual problem, but it's not for packaging. Ok, you can never be sure around here what people propose :) I am not so sure this is worth it. You are basically writing apt/rpm for user space. And we like to reuse components if they exist and fit the bill :) apt/rpm are way too big for my purposes, I am not even sure I want to consider dependencies between packages just yet. Well, my argument is that once you have the system in place sooner or later someone will suggest and/or implement dependencies and so on. That does not have to happen obviously, but people are packaging Sage for distributions where such mechanisms are already in place. But once you are there, you might as well keep the snapshot, add the package name as one of the file attributes, and bam you have a package management system ! But this is IMHO not KISS - a guiding principle of Sage :). Right now a fresh 3.0.6.alpha0 contains about 107235 files in $SAGE_LOCAL when following symbolic links. That is a lot of IO and disk seeks to do to upgrade for each package. Yes ! I totally agree with you, it is completely unacceptable to traverse the whole Sage directory at each package installation. Which is precisely why we need DESTDIR in every scenario I can think of. Once you have that and you keep track of package manifests for removal, you do in fact have the bare bones of a package manager. Ok, I kind of thought that I made the wrong assumption there and that my argument was slightly idiotic, but it was late and I was tired :) One thing that endlessly annoys me about rpm for example is its sluggish performance, which is largely rooted in its db backend, i.e. berkeley db IIRC. On top of that sqlite's performance sucks even worst. And you also introduce another point of failure where up to now KISS had provided a nearly perfect solution, i.e. any sort of db corruption will break Sage's upgrade system. About sluggish performance, I was in the train without a Sage installation but I started to play around with pysqlite. Given that mathematicians tend to keep on themselves (the extrovert ones are the ones that look at _your_ shoes ;-) :) I thought it was a good idea to package GNU hello for inclusion in Sage. I built a fake sage directory our of random parts, it has around 15k files. Built a sqlite database for it, and timed the hello-related commands : Extraction of the tarball : approx. 1.3 sec (oldish G4 powerbook, unplugged, bare with me ...) ./configure : 41 sec (yes, my laptop is old I told you) make : 6.4 sec (see above) make install : 7.5 sec (same time going to $SAGE_ROOT or to a staging directory) SPKG.insert : 0.4 sec (moves the files from staging to $STAGE_ROOT and updates the database) SPKG.remove : 0.4 sec (removes the installed files for hello, updates the database) So the overhead of the database appears to be minimal. Admittedly my directory is too small by an order of magnitude, but still I don't expect the overhead to grow out of bounds. I would call a 5% overhead at install time within the bounds of reason. Sure, overhead is one concern, but over-engineering another. One example (and I know this is not fair to compare your proposal) is the Windows registry. Sounds like a great idea until you realize that having config information in text files is much smarter in the long term. Another example is to stuff everything into XML files since it is so great and cool, but in the end the vast majority of situations is much better served by plain flat text files. So where is the benefit from using a database or even keep a list of the files? I just don't see it. * Updating one spkg often forces the update of another spkg. For example updating clisp forces a recompile of Maxima. So you cannot just switch between two clisp installs and expect things to work. And there are even more complicated dependencies in the default tree. As I said, I am not intending to manage package dependencies just yet, just removal. Ok. * The Sage library is special and there are loads of subtle dependencies. For example 3.0.3 to 3.0.4 upgraded LinBox from 1.1.5 to 1.1.6.rc0. A seemingly innocent update until you learn that this also means that the name of the wrapper library has changed. So running a 3.0.4 or later Sage library with a linbox-1.1.5 or earlier will cause Sage not to even start any more. In some cases it is imaginable that Sage does start but will exhibit subtle bugs since we fixed something in FOO-1.3.3.p12, but for some reason one user ends up running FOO-1.3.3.p11. Happy bug hunting in that case. (Then it appears that a
[sage-devel] Re: periods.cc:593: error: call of overloaded `log(int)' is ambiguous
On Jul 22, 6:07 am, karakas [EMAIL PROTECTED] wrote: Hi, Here is part of install.log (I have set over more or less sensitive, or boring information): GCC Version gcc -v Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.5/specs Configured with: ../configure --enable-threads=posix --prefix=/usr -- with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/ share/man --enable-languages=c,c++,f77,objc,java,ada --disable- checking --libdir=/usr/lib --enable-libgcj --with-slibdir=/lib --with- system-zlib --enable-shared --enable-__cxa_atexit i586-suse-linux Thread model: posix gcc version 3.3.5 20050117 (prerelease) (SUSE Linux) You need at least gcc 3.4 or higher to build Sage since we require c99. eclib itself does not need c99, but it is not supported to build the current release with gcc 3.4 or earlier. We do have a gcc check, but unfortunately that happens right before building FLINT which is past eclib. The issue is known and in the bug tracker already and I meant to take care of it, but had not had the time to do so. Sorry, hopefully in Sage 3.1 this will be fixed so that Sage tells you immediately that the compiler is not modern enough. 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: Status of Sage for Debian
On Jul 21, 7:44 pm, Timothy G Abbott [EMAIL PROTECTED] wrote: Hi Tim, I figured I'd give everyone an update on how things are going with the Sage packages. I believe (but am not certain) that all of the Sage dependencies that I want to get into Lenny will make it, though I'm still waiting on final review for 5 of them that had copyright problems in the past. On the other hand, Debian is freezing everything starting in around 5 or 6 days. So, I need to have a presentable Sage package in the very near future. There are currently a few showstopper problems: 1) Sage 3.0.4 or 3.0.5 built with polybori 0.5rc fails to find m4ri_build_all_codes and m4ri_destroy_all_codes. This is discussed in http://trac.sagemath.org/sage_trac/ticket/3264. Because this results in Sage not starting, I can't run tests against this version to find other problems. So I built Sage against the polybori spkg included in Sage (which has license problems that prevent me from using it in Debian). Martin, Michael B. and I talked about this issue and we are confident we can resolve the problem. The polybori.spkg you linked from the ticket seems to have some problems, but I will look into them hopefully tomorrow. 2) My current version of Sage 3.0.4 built with the 0.3.1 polybori spkg included in Sage passes most doctests, though it fails a large number of tests ending with a Runtime Error in sage/matrix/matrix_integer_dense.pyx (error output below). I'm guessing that linbox is totally not working. If you've seen a problem like this before (I'm running the new linbox 1.1.6rc), let me know. I would greatly appreciate any help debugging these issues. I can give out ssh access to a test VM with either version of my Debian Sage package installed on it if that would make debugging one of these problems easier. However, the VM's host is very loaded and thus things are quite slow; thus I suspect that (1) will be easier to debug using the patch attached to #3264. Hm, any chance you can get me logged into a box with that problem once the PolyBoRi issue has been taken care off. It does not ring a bell. I also wanted to let you know that we had to patch LinBox 1.1.6.rc0 slightly since it produced wrong results form charpoly mod p. You need to apply a one line patch to fix the issue - see #3671. I do not know if Clement plans to do an 1.1.6rc1 release of Linbox or not. -Tim Abbott 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: why sage is useful for me
On Jul 22, 7:33 am, Dr. David Kirkby [EMAIL PROTECTED] wrote: On Jul 22, 11:17 am, Ondrej Certik [EMAIL PROTECTED] wrote: Hi, Hi Ondrej, I just wanted to share why Sage is (or will be soon) useful for me. 1) I have a program that I do for my master thesis, it's some finite elements method + electronic structure calculations and my boss gave me access to some solaris very fast boxes, Is that UltraSPARC or x86/x64 (i.e. AMD/Intel) based? I'd be interested what you have access to. I could relatively painlessly build you a 64 bit self contained gcc, binutils, shellutils, python, ATLAS, numpy 1.1.1, scipy SVN and hg if you left me know the CPU target you want. I have to offer Sparc US IIIi, Core2 Quad SSE or Opteron. So, mabshoff -- Solaris port +1. Me too wanting that. 3.0.6 contains about five Solaris build fixes, so the list is getting shorter. We mainly did a stabilization release, so some of the more risky stuff was left out. 2) There is a nonzero chance I'll be teaching some undergrad calculus stuff in a year or two and so I was thinking which programs (if any) I'd use and the constrain will probably be windows. Why should it be windows? I feel Windows has some advantages over Solaris or Linux for general office/home use. In particular, you don't need to be as computer savvy to do certain basic tasks, like install printers. But I feel Unix/Linux systems are a much better platform for scientific computing. If you use the principle of best tool for the job then I doubt Windows can be considered the best tool. Why encourage people to a system which seems to have dramatically increased in price in recent years and gets more and more bloated? When I bought my first PC, the hardware cost just over £2000 ($4000) and the operating system license was about £50 ($100). Now, the cost of the OS is a much higher percentage of the total cost. Well, there is a vast people using Windows out there either by choice or because they don't know about alternatives. And Sage can only benefit from being portable. In the end it is all about bringing mathematical OS to the people and not convincing them to switch OSes. They will hopefully learn that Open Source is something good and high quality, but if other people use Windows I am perfectly fine with it. So, mabshoff -- Sage windows port +1. I know he is on to that. It's obvious that given the large number of windows systems, that it will increase Sage's popularity more than ports to Solaris, HP-UX or any other platform ever will. (Personally I'm more keen on Solaris port, but objectively one would have to say a Windows one would do more for Sage's popularity. And that is important.) So the above are rather side effects of the main Sage's aim, but those are things that would make my life much more easier. I just wish I'd had a decent open-source alternative to Mathematica when I started my MSc. Unfortunately I've used Mathematica on/off for the last 17-18 years, so have a lot of time spent using it. I'd rather not have to inflict that anyone else, so they get locked into a system. (I think Mathematica is a good system, just too expensive and proprietary). :) 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: periods.cc:593: error: call of overloaded `log(int)' is ambiguous
On Jul 22, 8:12 am, mabshoff [EMAIL PROTECTED] wrote: On Jul 22, 6:07 am, karakas [EMAIL PROTECTED] wrote: Hi, Here is part of install.log (I have set over more or less sensitive, or boring information): GCC Version gcc -v Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.5/specs Configured with: ../configure --enable-threads=posix --prefix=/usr -- with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/ share/man --enable-languages=c,c++,f77,objc,java,ada --disable- checking --libdir=/usr/lib --enable-libgcj --with-slibdir=/lib --with- system-zlib --enable-shared --enable-__cxa_atexit i586-suse-linux Thread model: posix gcc version 3.3.5 20050117 (prerelease) (SUSE Linux) You need at least gcc 3.4 or higher to build Sage since we require c99. eclib itself does not need c99, but it is not supported to build the current release with gcc 3.4 or earlier. Oops, the above should obviously state *gcc 3.3 or earlier*. Sorry for the mistake and the extra email. We do have a gcc check, but unfortunately that happens right before building FLINT which is past eclib. The issue is known and in the bug tracker already and I meant to take care of it, but had not had the time to do so. Sorry, hopefully in Sage 3.1 this will be fixed so that Sage tells you immediately that the compiler is not modern enough. Cheers, Michael 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: pari slowness
On Jul 22, 11:48 am, David Harvey [EMAIL PROTECTED] wrote: On Jul 22, 2008, at 12:35 PM, David Harvey wrote: SNIP This seems to have been fixed already in 3.0.5. Sorry for the noise. david Hi David, we reverted to the old gmp 4.2.1 spkg in 3.0.5 since the only reason to upgrade was to better support Cygwin and OSX 64 bit. Since both of those platforms are not ready for prime time we decided it would be the more prudent way to go. Obviously we want eMPIRe in Sage ASAP and I need to do my share to make this happen, so please remind me often :) 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: CUDA and Sage
On Jul 22, 2:55 pm, Simon Beaumont [EMAIL PROTECTED] wrote: Hi Simon, I decided to have a play with the pycuda-0.90.2 kit for which I needed boost_1_35_0 Mhh, is 1.35.0 mandatory? We might have to upgrade boost in PolyBoRi then. - the main caveat is to make sure boost is using the sage python include, lib and executable rather than any system installed python. Similarly configure pycuda. My sage server runs as user sage - so I had to run the x server under sage. (I am looking into how to get the nvidia drivers loaded without x). Ok, please let us know what you find out. Upshot is low level api works like a charm from sage notebook (sage 3.0.4 built under gentoo on amd64 h/w). Since I don't need the full BLAS library and I have some optimal kernels that do sgemm better than the library version then I might have a play with this for a while and see what I run into. Yeah, even sgemm could be useful and it would be nice if you could get some numbers of sgemm on the CPU vs. the GPU. Once the IEEE conform hardware is out things will become a lot more interesting. Cheers, Simon 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.5 Solaris-x86-sse3 binary
On Jul 22, 10:17 am, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Hi Brandon
Speaking of Matlab, I was able to get version r2008a (most recent
version) working in a linux-2.6 zone using the CentOS 5 distribution.
I then installed RPyC 3.00 RC1 (http://rpyc.wikispaces.com/)
Interesting, I had never heard of RPyC, but it will likely be of some
interest to some of the people around here.
in both
the lx zone's copy of sage and in the native solaris sage
installation. I started up the RPyC server (which could be turned
into a daemon) in the lx zone:
sage: load rpyc_classic_server.sage # this is one of the server
scripts that came with RPyC, renamed to a .sage file
In the solaris client:
sage: import rpyc
c = rpyc.classic.connect(192.168.5.10) # 192.168.5.10 is the ip of
the linux zone
sage: c.modules.__main__.matlab('3+3')
6
Cool. There is also some code IIRC that let's you use ssh to open a
tunnel to another box to execute commands in some supported
application there. It has been a while, but I believe they also used
Matlab.
Though I suppose this has some minimal use on its own as being a way
to call proprietary software not available natively on solaris while
still using native applications from sage (OpenGL visualization comes
to mind), I think a more common benefit would be in having a solaris
zone that is used to house a sage notebook server while not having to
sacrifice the ability to call proprietary software (from a lx zone).
I am very interested in providing a Solaris Zone with Sage since
isolating the notebook into its own little corner of the system is an
excellent idea. If you have some expertise in that area I would be
glad if you could help out there.
Once I move in to my new apartment and have access to my sever again I
will try it out ... it doesn't look like it will be long before the
solaris port is adequate ;)
Yeah, I am really hoping that William and I will sit down this
Thursday and/or Friday and spend some time nailing down some of those
pesky Solaris bugs. It looks like we now have a solution to a sympow
problem, so hopefully another bug just bit the dust.
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: periods.cc:593: error: call of overloaded `log(int)' is ambiguous
On Jul 22, 10:18 am, karakas [EMAIL PROTECTED] wrote: Hi Chris, Thank you very much for the clear and fast answer. Since upgrading gcc will probably mean an upgrading of glibc too, which will mean a recompilation/upgrade of the whole system, gcc 3.4.6 or 4.0.2 (or is .3 the last one?) will likely build on your box with the current glibc. Just make sure to enable c and c++ as languages and install into some prefix like /usr/local/gcc-3.4.6. Then prepend /usr/local/gcc-3.4.6/bin to PATH and /usr/local/gcc-3.4.6/lib to LD_LIBRARY_PATH and do another clean Sage build from scratch. I guess it is better to postpone compilation until I finish my migration from SuSE to Gentoo (which is going to take a *long* time anyway the way things move (read: technology: fast, me: slow :-))). Considering that the support for that SuSE release ended a while ago that might be a good idea :) 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: Problems in HGCD patch
On Jul 24, 12:11 pm, Bill Hart [EMAIL PROTECTED] wrote: Then again if that is so, it is recorded here incorrectly: http://sagemath.org/packages/standard/ Then again I think SAGE uses FLINT 1.0.13 by now, so that's not up-to- date either. Bill. The FLINT upgrade is in 3.0.6.rc0, so it will show up on once 3.0.6 is released. William and I are poking at some rather mysterious bugs, so hopefully we will get it out on Sunday since both of us are leaving Vienna in about 18 to 24 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: libpng.dylib on OSX
On Jul 25, 5:11 am, Martin Albrecht [EMAIL PROTECTED] wrote: Hi there, Hi Martin, my patch at http://trac.sagemath.org/sage_trac/ticket/3324 is held back by a libPNG problem on OSX, particulary the spkg-install contains the following code: if [ `uname` = Darwin -a $SAGE64 = yes ]; then echo Keeping 64 bit OSX libpng.dylib around else # There is a weird problem on Darwin where most programs # will crash if they see the libpng built as part of this # package instead of the system-wide apple libpng. So # we delete it. # NOTE -- we *only* delete the dylib's. Apps that need libpng can still link it in statically. rm -f $SAGE_LOCAL/lib/libpng*dylib rm -f $SAGE_LOCAL/lib/libpng*.la fi Due to this, I can't link against libpng from the Sage library. Any idea how to deal with this? My patch bit-rotted quite a while now. Sorry, you asked me about this for a while and I did not get around to it. I saw your GF(2) matrix hashing ticket and see why this is important now. The above is actually only a problem on OSX 10.4 only and is IMHO caused by Apple not providing a png.h, but some FrameWork that python and R use. We now have access to a PPC 10.4 G4, so we can attempt to fix the problem in Python and R. If this is not fixed soon it is a good idea to complain about this publically :) Cheers, 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Sage Doc Day 3 (July 27th, 2008)
Hi folks, after a long, long time we want to do another Doc Day this Sunday. William won't be around, but that should not stop us. The goal should be to review patches and also write a bunch of new doctests since one of the goals this year is to get up to 100% doctests this year. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: initial giac spkg
On Aug 18, 10:37 am, Ondrej Certik [EMAIL PROTECTED] wrote: On Mon, Aug 18, 2008 at 7:29 PM, Martin Albrecht Hi, [EMAIL PROTECTED] wrote: Ah I see thanks. I used some other spkg package as a template. Which one? It needs to be fixed :-) Yes :) Well, some unofficial one: http://sage.math.washington.edu/home/gfurnish/spkg/glib-2.14.5.spkg I thought that's the way to do spkg packages. Nope, that one is likely a bad example. Ondrej In general the issue you are hitting with Giac are bugs in its build system. Setting CXXFLAGS work around those issues, but the proper fix is that have a --with-$FOO=$LOCATION flag that then adds proper -I and -L locations in the makefiles. 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 Package Vote: Hidden Markov Models into Sage?
An appropriate amount of time has passed and I consider this a positive vote for the inclusion of GHMM into Sage. 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.1.1 : Gnutls compilation failure
On Aug 18, 1:20 pm, bourbabis [EMAIL PROTECTED] wrote: Hello everybody. Everything is in the title. The install log : http://download69.mediafire.com/fzzdvb2dymmg/mykrpj3thu6/install.log.bz2 Thanks. Hi, this is the same problem as you reported last time. For some reason some part of the toolchain seems to be missing. When building gnutls there ought to be a file called config.log in $SAGE_ROOT/spkg/build/ gnutls - can you look for it and send me a copy in private email? 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.1.final is out
On Aug 19, 12:12 am, Stan Schymanski [EMAIL PROTECTED] wrote: Hi Stan, As mentioned before, the sage -upgrade from sage 3.0.5 did not work for me, but a fresh compilation of the sage-3.1.1.tar into a new directory worked fine on my PowerBook Pro 2.4 GHz with os 10.4.11. I am trying it out right now and my notebooks seem to work faster than with the previous version (sage 3.0.5.). We have been told by various people that the startup time of Sage on OSX 10.4 is much better when build locally since then the linker does not end up looking for libraries in a lot of places because the location of the Sage install moved. sage -testall gave: Ran 52 tests in 8.711s PASSED (successes=52) Thanks for a great software! The above is only the doctests for DSage and there should have been another 900+ tests run. Stan In general it seems that OSX 10.4 is sufficiently different in its behavior than 10.5. Thus a bunch of upgrade issues exist that do not happen on OSX 10.5. I am setting up a laptop with 10.4 so that I can chase down those issues. 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] Bug Day 13: August 23rd, 2008
Hello folks, I would like to suggest a Buh Day for this Saturday, August 23rd, 2008. We will start at 10 am PST and go on until the last person is exhausted. If you plan to participate please add youself to http://wiki.sagemath.org/bug13 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.1.final is out
On Aug 20, 7:40 am, Dr. David Kirkby [EMAIL PROTECTED] wrote: On 16 Aug, 23:18, mabshoff [EMAIL PROTECTED] Please build and test, a final source release should be out tonight. Hi Dave I thought the Solaris specific fixes were planned for 3.1, but I see polybori-0.3.1.p4 still fails to build on my Sun Blade 2000, which is running Solaris 10 update 4. The issue is one you know of - Sun's tools being used instead of GNU ones in the polybori Makefile, for code which suffers GNUisms. Yeah, unfortunately loads of things got bumped from the 3.1 release due to time constraints and Sage Days 9 also did not help too much. I am merging build fixes into 3.1.2 and so far have mostly done 64 bit OSX fixes. Hopefully I will get around to Solaris in 3.1.2 and get more fixes in there. Dave 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.1.final is out
On Aug 21, 9:44 pm, Dr. David Kirkby [EMAIL PROTECTED] wrote: SNIP Yeah, unfortunately loads of things got bumped from the 3.1 release due to time constraints and Sage Days 9 also did not help too much. I am merging build fixes into 3.1.2 and so far have mostly done 64 bit OSX fixes. Hopefully I will get around to Solaris in 3.1.2 and get more fixes in there. Hi Dave, OK, I look forward to seeing the fixes in 3.1.2 (hopefully). Several of them are one line fixes - so should hopefully not take long to do. The first error that causes the compilation of 3.1 to fail only needs two bytes changed (gcc to cc, and cc to gcc), PLUS whatever it needs to create a new .spkg file, and I assume generate a new version number for the .spkg file. I can't help feeling these fixes would be much easier to integrate if the code was not supplied as lots of .spkg files, but just as simple source files. I know for me personally, I would have got a lot more done in a lot less time, if it was just a matter of editing a source file and changing a couple of bytes in it. Not only that, but if someone downloads only changes between versions, it would dramatically reduce the amount of code that needs to be downloaded. The fact any change occurs in the compressed .spkg file means the whole thing needs to be downloaded. The spkg format we use has *zero* to do that those changes are not in the official tree yet. We have discussed this before and I do not think that regurgitating this argument will be of any benefit. The reason those fixes are not in the tree yet is pure and simple that those fixes have to go through review and I have been fixing issues related to Maxima and numpy which are absolutely essential for the OSX 64 bit as well as Solaris port to work. Once those fixes are in I will revisit the build issues and push them into the review que. Dave 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: Problem building sage 3.1 on Debian lenny amd 64
On Aug 25, 1:45 am, Thierry Dumont [EMAIL PROTECTED] wrote: Hi, Hi, I try to compile sage on my opteron machine. When compiling flint, I get the ld error message: /usr/bin/ld: cannot find -lstdc++ Th ld lines are: g++ -I/usr/local/sage-3.1/local/include/ -I/usr/local/sage-3.1/local/include -f PIC -funroll-loops -O3 -c NTL-interface.cpp -o NTL-interface.o gcc -std=c99 -fPIC -shared -Wl,-soname,lib`cat DIRNAME`.so -o lib`cat DIRNAME`.s o mpn_extras.o mpz_extras.o memory-manager.o ZmodF.o ZmodF_mul.o ZmodF_mul-tunin g.o fmpz.o fmpz_poly.o mpz_poly-tuning.o mpz_poly.o ZmodF_poly.o long_extras.o z mod_poly.o NTL-interface.o -L/usr/local/sage-3.1/local/lib/ -L/usr/local/sage-3.1/local/lib/ -lgmp -lpthread -lntl -lm -lstdc++ and so, we certainly try to find a libstdc++ in /usr/local/sage-3.1/local/lib/ and, actually, there is non stl lib installed there. The stl lib is system wide installed Odd to say the least and I am not sure why we even need to link libstdc ++ explicitly here. I assume your C++ compiler works since at that point we have already build NTL. libstdc++.so should be automatically picked up the compiler. To fix this I would remove that linker directive from FLINT. Does Lenny ship with gcc 4.3.1 or did you compile the compiler itself? yours t. Cheers, Michael tdumont.vcf 1KViewDownload smime.p7s 5KViewDownload --~--~-~--~~~---~--~~ 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: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
+1 from me to include Pynac/GiNaC in Sage, Martin Albrecht asked about the Windows porting issue: I looked at the GiNaC code and it is very clean C++. The maintainer is willing to merge MSVC related patches where needed, i.e. export statements for the symbols we need. I am not aware of any other issues that need fixing. The current reason that there is no MSVC target to build GiNaC is the lack of an non-gcc port of CLN which does not apply any more since William removed the dependency on CLN. So I will fix the problem with MSVC during the Windows port. There are now also CLN patches to build with MSVC, but I have not taken a closer look at those. Considering the alternatives (GIAC, code written from scratch) this is by far the best solution IMHO. 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: Manipulating diff. eqs. in Mathematica using pattern matching
On Aug 25, 11:50 pm, Ondrej Certik [EMAIL PROTECTED] wrote: Hi, I think it's just about getting people to fix it. There are many people around who can fix Python/Cython and a little less (I guess) who can fix C++ and C. But a lot less who can fix lisp. As I mentioned before, another big problem is that lisp doesn't manipulate native Python objects efficiently. Python *is* just a C library -- Python and C/C++ play very well together, especially because of Cython. The same is not the case with lisp/maxima. Actually, I think even just couple years ago, even though Python was written in C, it was a *pain* to call it from C easily. Yes, a lot of people did it, but it was a pain. Maybe that's the situation in lisp, surely some implementation is written in C *Every* lisp implementation I am aware of is written in C, some have some assembly added on top to speed some things up. The Lisp machine as hardware died in the early nineties IIRC and it does not look like it will make a comeback anytime soon. Check out http://en.wikipedia.org/wiki/Lisp_machine for a decent primer on lisp machines. and maybe it's possible to call it from C (and pass pointers around). But imho noone is seriously using it. ecl does that well, but we are only slowly getting to the point where we can switch to ecl in Sage. We finally upgraded to Maxima 5.16.2 in 3.1.2.alpha1. I did not want to switch Maxima releases and lisps in the same release, so we will see the ecl switch in Sage 3.2 hopefully. In Python all of this has changed due to Cython, that many many people use in production now, so again, big thanks to the whole Sage community who helped to bring pyrex to production. Well, Sage developers like Python, Cython and C while Maxima developers like lisp (at least for the low level stuff) - so we are having self selecting groups here. It is the best tool for the job, but also the devil you know, so I don't see big changes here in the future. Ondrej 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: Manipulating diff. eqs. in Mathematica using pattern matching
On Aug 26, 12:34 am, Ondrej Certik [EMAIL PROTECTED] wrote: Hi, Well, Sage developers like Python, Cython and C while Maxima developers like lisp (at least for the low level stuff) - so we are having self selecting groups here. It is the best tool for the job, but also the devil you know, so I don't see big changes here in the future. Let me say that I do see big changes here in the future. With Cython, it is actually easier to extend Python in C, than to extend Matlab in C, especially with the new numpy support in Cython soon. Yes, I think people will actually stop being scared by extending Python in C and porting more C libraries to Python Are you kidding? Python probably has the most C library extensions out there for any scripting language I am aware of. Cython makes it better, but many interface wrappers like Swig have done a stellar job :) Ondrej 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: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Aug 26, 1:27 am, William Stein [EMAIL PROTECTED] wrote: On Tue, Aug 26, 2008 at 1:19 AM, Ondrej Certik [EMAIL PROTECTED] wrote: SNIP qepcad relies on an aging library saclib for the algebraic data structures. It would be a worthwhile project to implement CAD/port qepcad so that it is modular, and can work with more recent/better libraries. Maybe someone (Carl Witty?) will take this on (or already has?). :) I think Carl Witty has done a bunch. He gave a talk about this at Sage Days 8.5. Maybe he'll comment on this thread. Carl and Jason Grout have been fixing build and 64 bit issues, but saclib is still not 64 bit. They have been pushing the fixes upstream and there ought to be an experimental spkg soon - the current one got rejected in review. Yes, but this is not necessary to get the infrustructure in and get the easy cases working and working fast. qepcad or other things will come handy when doing the general cases, where simple heuristics will fail. E.g. it's like with limits, the gruntz algorithm is nice and working, but all easy cases can be done (and are done) with heuristics, because it is simpler and way faster. Interesting. Yeah, the code in qepcad looks funny since at least some of it was translated from Fortran and hence has odd indentation for example. -- 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Testing the Notebook using Selenium
On Aug 23, 11:04 am, Mike Hansen [EMAIL PROTECTED] wrote: Hello all, Hi Mike, While we continue to add tests to the notebook code, there are some things that we just can't test directly in Python such as browser interactions / Javascript / etc. Luckily, there is a nice software package designed to handle this problem: Seleniumhttp://selenium.openqa.org/. Selenium has two components -- a server and a client. The server is a Java application which is what handles the control of the browser (IE, Safari, or Firefox). There are client bindings for many languages including Python. There is a Firefox extension (Selenium IDE) which allows you to record your actions and export the as a Python unit test; this makes writing tests pretty easy. We should begin developing a Selenium test suite for Sage that we can run before every release to verify that the notebook does indeed behave as it should. If anyone wants to take on this project, I'm sure a lot of people (including myself) would be very appreciative. In light of the recent failures in the notebook and the lack of testing the interface in the browser I consider this an excellent idea. :) Having seen you demo it I would suggest that we get Timothy or Igor to start writing tests in that direction to cover the notebook as well as @interact. --Mike 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] Vote for new spkg
Hi, at #258 Pablo De Napoli has posted an spkg for gp2c. It is tiny (about 500kb) and is considered useful by many people. It is a tool to translated pari code to C code that in turn can be linked to the pari library. Since that is a rather old ticket that has been sitting around it is now subject to the voting rules. The code works on Windows and as Pari is getting ported to MSVC gp2c will also work. 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] Sage 3.1.2.alpha1 released
Hello folks, alpha1 is finally out. I don't think alpha0 was ever announced here, so I am posting both logs. We merged loads of patches, but especially plotting improvements. Besides that we finally upgraded numpy and matplotlib, so some things might be going wrong there. I need some sleep, so I will see in the morning what blew up :) Sources are available in http://sage.math.washington.edu/home/mabshoff/release-cycles-3.1.2/ Cheers, Michael Merged in Sage 3.1.alpha1: #1539: William Stein: bdist of sage should include devel/doc [Reviewed by Michael Abshoff] #2000: Martin Albrecht: fall back to univariate factoring if possible [Reviewed by Carl Witty] #2410: Jason Grout: parametric_plot and constants [Reviewed by Mike Hansen] #2491: Mike Hansen: Showing source from sloane_functions [Reviewed by Michael Abshoff] #2569: Carl Witty: Add XOR to preparser [Reviewed by Mike Hansen] #3359: Martin Albrecht: bug/inconsistency in multivariate polynomial substitution [Reviewed by Mike Hansen] #3390: Jason Grout: update numpy to the 1.1.0 release [Reviewed by Michael Abshoff] #3392: Tim Abbott, Jason Grout: upgrade matplotlib to 0.98.3 release [Reviewed by Michael Abshoff] #3432: Martin Albrecht: MPolynomial_libsingular does not have a degrees method [Reviewed by Mike Hansen] #3653: Carl Witty: Better random complex numbers [Reviewed by Mike Hansen] #3654: Jason Grout: Deprecation warning function [Reviewed by Michael Abshoff, Mike Hansen] #3655: C. Boncelet, David Joyner: left multiplication in piecewise does not work [Reviewed by Mike Hansen] #3719: David Joyner: bug in group cohomology [Reviewed by Alex Ghitza] #3724: Martin Albrecht: faster hashs for Matrix_mod2_dense [Reviewed by Simon King] #3792: Ondrej Certik: fix Sage build when there is a broken systemwide freetype library [Reviewed by Michael Abshoff] #3794: Jason Grout: Create eigen functions for matrices [Reviewed by John Cremona] #3813: Franco Saliola, Arnaud Bergeron: Improve adaptive rendering in plot() [Reviewed by William Stein, Mike Hansen] #3826: Carl Witty: Empty string in interact prints \x00 [Reviewed by Igor Tolkov] #3853: Mike Hansen, Jason Grout: plot.py improvements part 1: Remove all factories [Reviewed by Jason Grout, Mike Hansen, Michael Abshoff] #3854: Igor Tolkov: interact needs to use notruncate [Reviewed by Martin Albrecht, Mike Hansen] #3869: John Cremona: CremonaDatabase functions iter() and isogeny_classes() sort keys wrongly [Reviewed by Carl Witty] #3873: Jason Grout, Carl Witty: Doctest should test for warnings [Reviewed by Carl Witty, Michael Abshoff] #3896: Robert Bradshaw: Upgrade Cython to 0.9.8.1.1 [Reviewed by Michael Abshoff] #3910: Carl Witty: adjust interval printing: precise integers print as integers [Reviewed by John Cremona] #3913: John Cremona: order function not defined for ideal classes [Reviewed by Alex Ghitza] #3926: Martin Albrecht: fix Macaulay2 building [Reviewed by Michael Abshoff] #3927: John Cremona: Several enhancements and bug fixes for Factorization class [Reviewed by Carl Witty] #3939: Martin Albrecht: copyright notice in integer.pyx [Reviewed by Michael Abshoff] #3942: Robert Miller: Sage interfaces vs. pyprocessing [Reviewed by William Stein] #3946: Chris Holdsworth: Tidier BinaryQF reductions [Reviewed by John Cremona] #3947: Michael Abshoff, David Philp: build python against Sage's readline [Reviewed by Mike Hansen] #3948: Michael Abshoff: Add 64 bit OSX build support for clisp [Reviewed by Mike Hansen] #3952: Mike Hansen: make plot() and parametric_plot() use fast_float on their functions [Reviewed by Carl Witty, Michael Abshoff] #3963: Mike Hansen: bug in converting Sage's rationals to Sympy rationals [Reviewed by Michael Abshoff] Merged in Sage 3.1.alpha0: #1300: Simon King, Martin Albrecht: Customize the output of Singular matrices [Reviewed by Martin Albrecht, Simon King] #1470: Michael Abshoff, Mike Hansen: upgrade maxima.spkg to 5.16.2 [Reviewed by Mike Hansen, Michael Abshoff] #1621: Michael Abshoff: update gd to 2.0.35/update 64 bit OSX support [Reviwed by Robert Miller] #3013: Michael Abshoff: bug in integrate (found during a talk!) [Reviewed by Mike Hansen] #3174: Michael Abshoff: add 64 bit OSX build support to flint [Reviewed by Robert Miller] #3175: Michael Abshoff: add 64 bit OSX build support to zlib [Reviewed by Robert Miller] #3194: Michael Abshoff: fix 64 bit OSX build support for singular [Reviwed by Robert Miller] #3195: Michael Abshoff: add 64 bit OSX build support for polybori [Reviwed by Robert Miller] #3199: Michael Abshoff: fix 64 bit OSX build support for zn_poly [Reviwed by Mike Hansen] #3641: Martin Albrecht: new Singular upstream release [Reviewed by Michael Abshoff] #3683: Simon King, David Joyner: Wrap GAP's meataxe implementation [Reviewed by David Joyner, Simon King] #3707: Ondrej Certik: Make all common Sage classes convertible to SymPy, update Sympy to 0.6.2 [Reviewed by Martin Albrecht] #3710: Andrzej Giniewicz: Segfault in Tachyon on some latest GCC
[sage-devel] Cleanup of sage.math home directories
Hello folks, space is getting right again on sage.math's home partition. I will post a list with the hard drive space consumption winner later on today (PST), so this is a possibility to clean up before I post the list of winners :) 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.1.2.alpha1 released
In general note that #3813 (the new adaptive plotting code) slows down a lot of doctests since we end up creating plots with a lot more points, but much better quality. Mike Hansen has an idea how to fix that performance issue, but there is no ticket yet. Even with his _fast_float fixes the slow down is noticeable. 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.1.2.alpha1 released
On Aug 27, 12:32 pm, William Stein [EMAIL PROTECTED] wrote: On Wed, Aug 27, 2008 at 5:42 AM, mabshoff [EMAIL PROTECTED] wrote: SNIP It fails to build for silly reasons on iras and cleo (our itaniums): checking target system type... ia64-unknown-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... configure: error: newly created file is older t han distributed files! Check your system clock make[2]: *** [config.status] Error 1 make[2]: Leaving directory `/home/wstein/iras/build/sage-3.1.2.alpha1/spkg/build/gd-2.0.35.p0 /src' Error building gd. Mhh, this sounds like an NFS sync issue, but I will take a closer look today. It would not be the first time we are having sync issues at SkyNet. Building in tmp should get rid of the problem if it is a sync issue. 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: Edit a copy does not work on published worksheet
On Aug 27, 2:23 pm, Igor Tolkov [EMAIL PROTECTED] wrote: I prefer Google Docs, since I don't know the wiki code very well. I think, the most logical approach is to enumerate most of the notebook functionality, as well as notebook-related bugs that are open or have been closed in recent versions, and only then compile a testing checklist. I will give it a lot more thought when I get home. Igor *Every* functionality offered by the notebook (as well as interact) should be tested via Selenium and new features to the notebook should only be added when they are accomplished by a Selenium test case. We have learned this lesson over and over again: If we do not automatically test functionality we will have regressions. We created the pickle jar for that and now we will do Selenium based notebook testing and hopefully the next project is verification of the plotting output. There is no other way to make Sage better than to extend the automated testing being run when merging patch. 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.1.2.alpha1 released
On Aug 27, 9:56 pm, Arnaud Bergeron [EMAIL PROTECTED] wrote: 2008/8/27 John Cremona [EMAIL PROTECTED]: Hi Arnaud, Since this bugged me (I did the adaptive rendering thing) I timed the doctests for plot.py on my machine: sage 3.1.1 vanilla sage -t devel/sage-main/sage/plot/plot.py [146.8 s] -- All tests passed! Total time for all tests: 146.8 seconds sage 3.1.1 with trac #3813 applied sage -t devel/sage-plotting/sage/plot/plot.py *** *** Error: TIMED OUT! *** *** For whitespace errors, see the file /Volumes/Place/anakha/Applications/sage/tmp/.doctest_plot.py*** *** Error: TIMED OUT! *** *** [532.7 s] exit code: 1024 -- The following tests failed: sage -t devel/sage-plotting/sage/plot/plot.py Total time for all tests: 532.7 seconds So yeah, there is definitly something wrong there. After investigation, I realized that I messed the order of xmin and xmax in the submitted patch making delta negative. With only that change, the timings go down to more reasonable levels. sage 3.1.1 with trac #3813 and this little diff diff -r c5f36741c6d9 sage/plot/plot.py --- a/sage/plot/plot.py Wed Aug 27 23:52:34 2008 -0400 +++ b/sage/plot/plot.py Thu Aug 28 00:41:01 2008 -0400 @@ -3820,8 +3820,8 @@ #be all plotted together. if isinstance(funcs, (list, tuple)) and not parametric: return reduce(operator.add, (plot(f, (xmin, xmax), polar=polar, **k wds) for f in funcs)) - - delta = float(xmin-xmax) / plot_points + + delta = float(xmax-xmin) / plot_points random = current_randstate().python_random().random exceptions = 0; msg='' sage -t devel/sage-plotting2/sage/plot/plot.py [195.5 s] -- All tests passed! Total time for all tests: 195.5 seconds It is still slower, but much better than before so this little patch above should really be applied. I don't think it warrants its own trac ticket, but if that makes the life of Michael simpler, I will do it. I could also just add it to #3813 if the posting is all that's needed. Thanks for tracking this down. Please open a new ticket and attach the patch to it. We generally attempt to avoid reopening tickets or adding patches to tickets that were closed in previous milestones since that makes reconstructing the exact sequence of patches hard. 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: Sage 3.1.2.alpha1 released
On Aug 27, 8:57 am, John Cremona [EMAIL PROTECTED] wrote: Two build reports. Both built fine, but a few doctest failures: Hi John, 1. Linux version 2.6.24-19-generic ([EMAIL PROTECTED]) (gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)) #1 SMP Fri Jul 11 23:41:49 UTC 2008 The following tests failed: sage -t devel/sage/sage/stats/hmm/chmm.pyx sage -t devel/sage/sage/stats/hmm/hmm.pyx sage -t devel/sage/sage/matrix/matrix_mod2_dense.pyx The first looks like just numerical noise. The second is not just that: sage -t devel/sage/sage/stats/hmm/hmm.pyx ** File /home/john/sage-3.1.2.alpha1/tmp/hmm.py, line 678: sage: a.viterbi([1,0,0,1,0,0,1,1]) Expected: ([1, 0, 0, 1, 1, 0, 1, 1], -11.062453224772216) Got: ([1, 0, 0, 1, 0, 0, 1, 1], -11.062453224772215) Yeah, the above looks odd. Maybe William can tell us what is happening here. ** File /home/john/sage-3.1.2.alpha1/tmp/hmm.py, line 686: sage: a.viterbi([3/4, 'abc', 'abc'] + [3/4]*10) Expected: ([0, 1, 1, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0], -25.299405845367794) Got: ([0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], -25.299405845367794) ** 1 items had failures: 2 of 6 in __main__.example_19 ***Test Failed*** 2 failures. For whitespace errors, see the file /home/john/sage-3.1.2.alpha1/tmp/.doctest_hmm.py [1.8 s] exit code: 1024 The third is this: File /home/john/sage-3.1.2.alpha1/tmp/matrix_mod2_dense.py, line 267: sage: hex(hash(A)) Expected: '0xdeadbeed' Got: '-0x21524113' 2. 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 The following tests failed: sage -t devel/sage/sage/plot/plot.py Martin is following up on this I assume. Rerunning this one took an age (166s, surely over the limit?!) and produced this: File /home/jec/sage-3.1.2.alpha1/tmp/plot.py, line 4505: sage: adaptive_refinement(sin, (0,0), (pi,0), adaptive_tolerance=0.01) Expected: [(0.125*pi, 0.38268343236508978), (0.1875000*pi, 0.7023301960218), (0.250*pi, 0.707106781186547...), (0.3125000*pi, 0.83146961230254524), (0.375*pi, 0.92387953251128674), (0.4375000*pi, 0.98078528040323043), (0.500*pi, 1.0), (0.5625000*pi, 0.98078528040323043), (0.625*pi, 0.92387953251128674), (0.6875000*pi, 0.83146961230254546), (0.750*pi, 0.70710678118654757), (0.8125000*pi, 0.7023301960218), (0.875*pi, 0.38268343236508989)] Got: [(0.125*pi, 0.38268343236508978), (0.1875000*pi, 0.7023301960218), (0.250*pi, 0.70710678118654746), (0.3125000*pi, 0.83146961230254524), (0.375*pi, 0.92387953251128674), (0.4375000*pi, 0.98078528040323043), (0.500*pi, 1.0), (0.5625000*pi, 0.98078528040323043), (0.625*pi, 0.92387953251128674), (0.6875000*pi, 0.83146961230254535), (0.750*pi, 0.70710678118654757), (0.8125000*pi, 0.7023301960218), (0.875*pi, 0.38268343236508989)] which has a single digit of noise difference. I made this #3972 and will post a patch there shortly. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: bad URL to benchmark for graph theory project
On Aug 27, 11:12 pm, Minh Nguyen [EMAIL PROTECTED] wrote: SNIP Hi Minh, I'm assuming that the correct benchmark URL is http://www.sagemath.org:9001/graph_benchmark Is this correct? Yes, at some point the wiki moved to its own domain and then the domain was moved to a different host. All sage.math:9001 urls should now point to www.sagemath.org or even better wiki.sagemath.org. -- Regards Minh Van Nguyen Cheers, Michael Web:http://nguyenminh2.googlepages.com Blog:http://mvngu.wordpress.com --~--~-~--~~~---~--~~ 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: bad URL to benchmark for graph theory project
On Aug 27, 11:35 pm, Minh Nguyen [EMAIL PROTECTED] wrote: Hi Michael, On Thu, Aug 28, 2008 at 6:24 AM, mabshoff [EMAIL PROTECTED] wrote: [...] Yes, at some point the wiki moved to its own domain and then the domain was moved to a different host. All sage.math:9001 urls should now point towww.sagemath.orgor even better wiki.sagemath.org. So you're saying that it's good for links in wiki pages to point to something like [1]http://wiki.sagemath.org:9001/blah/blah If I'm correct, then I'll go ahead and edit links that point to, say http://sage.math.washington.edu:9001/blah/blah with something like [1]. Not exactly: http://wiki.sagemath.org/graph_benchmark is an equivalent to http://www.sagemath.org:9001/graph_benchmark since wiki.sagemath.org is a virtual host. Should we ever change the port of the wiki everything at :9001 will break while wiki.sagemath.org will just keep on working. -- Regards Minh Van Nguyen Cheers, Michael Web:http://nguyenminh2.googlepages.com Blog:http://mvngu.wordpress.com --~--~-~--~~~---~--~~ 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.1.2.alpha1 released
On Aug 28, 4:59 am, Ondrej Certik [EMAIL PROTECTED] wrote: On Thu, Aug 28, 2008 at 1:33 PM, David Joyner [EMAIL PROTECTED] wrote: SNIP Hi, -- The following tests failed: sage -t devel/sage/sage/calculus/calculus.py Total time for all tests: 407.6 seconds Try running with --verbose to determine which tests hangs, or if it just takes a lot of time. It takes forever for me too. It is a known issue and there is a patch by Arnaud. It has not been reviewed and merged yet (in fact there is not even a ticket yet), but the patch will be in the final release. I killed it at this test: Trying: G.show(frame_aspect_ratio=[Integer(1),Integer(1),Integer(1)/Integer(2)])### line 893:_sage_ G.show(frame_aspect_ratio=[1,1,1/2]) Expecting nothing after maybe a minute. Imho 1 minute for one test is way too much. buhu :) - there are more than enough tests that take longer than a minute, but those are only run with -long. Ondrej 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] Reviews, Reviews, Reviews for 3.1.2 ...
Hello folks, fortunately the number of ticket with unreviewed patches has dropped from 100+ to around 40 at the moment. But if you look at http://trac.sagemath.org/sage_trac/report/10 there are still 41 open tickets with patches waiting for review. So if you have some spare cycles to burn come on over and help out in the process. 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.1.2.alpha1 released
On Aug 28, 5:17 am, Ondrej Certik [EMAIL PROTECTED] wrote: Trying: G.show(frame_aspect_ratio=[Integer(1),Integer(1),Integer(1)/Integer(2)])### line 893:_sage_ G.show(frame_aspect_ratio=[1,1,1/2]) Expecting nothing after maybe a minute. Imho 1 minute for one test is way too much. buhu :) - there are more than enough tests that take longer than a minute, but those are only run with -long. huhu. :) with -long, it's fine even if it takes 20 min to run with me. :) - I am just glad to 3.1.2.alpha1 build for you on that odd OpenSUSE box. Thanks for supplying the fixes. Ondrej 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.1.2.alpha1 released
On Aug 28, 9:24 am, Arnaud Bergeron [EMAIL PROTECTED] wrote: 2008/8/28 mabshoff [EMAIL PROTECTED]: Hi Arnaud, Thanks for tracking this down. Please open a new ticket and attach the patch to it. We generally attempt to avoid reopening tickets or adding patches to tickets that were closed in previous milestones since that makes reconstructing the exact sequence of patches hard. This is now #3975 (http://trac.sagemath.org/sage_trac/ticket/3975) Thanks, Mike Hansen has reviewed and rebased it, so it will be in 3.1.2.alpha2 tongiht (as in out before I go to bed around 6am PST) Cheers, Michael Cheers, Michael -- La brigade SnW veut vous recruter -http://brigade.snw.googlepages.com --~--~-~--~~~---~--~~ 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.1.2.alpha1 released
On Aug 28, 6:30 am, William Stein [EMAIL PROTECTED] wrote: On Wed, Aug 27, 2008 at 10:22 PM, mabshoff [EMAIL PROTECTED] wrote: SNIP Yeah, the above looks odd. Maybe William can tell us what is happening here. I think the above is just numerical noise. The Viterbi algorithm is an approximate numerical algorithm using double precision numbers, and can give slightly different answers on different hardware. Can you change the doctest to: sage: a.viterbi([1,0,0,1,0,0,1,1]) # numerical instability on some platforms ([1, 0, 0, 1, ..., 0, 1, 1], -11.06245322477221...) William This is now #3978 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: Command line processing sage-python
On Aug 28, 2:32 pm, William Stein [EMAIL PROTECTED] wrote: On Thu, Aug 28, 2008 at 1:19 PM, Simon Beaumont [EMAIL PROTECTED] wrote: Hi, got a rather weird one - os x 10.5.2 sage 3.1.1 (binary build) I am trying to build boost (python) for this version on os x - so I can get pycuda going against the OS X 2.0 cuda. David Philip has been playing with building PyCuDA against Sage's Python on OSX. He switched the build to use ucs2 and also builds Sage as a FrameWork. It is not 100% ready for prime time, but check out http://trac.sagemath.org/sage_trac/ticket/3924. well the python (python-sage) seems not to handle the -c command like regular python that is import fails with a syntax error and print 'foo' doesn't... Any ideas? For clarification can you post an actual log of what you input and what happens? Yeah, that would be helpful. You need boost 1.35, too, and the experimental boost package we provide is 1.34. Making one for 1.35 should be trivial. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.1.2.alpha1 released
On Aug 28, 1:18 pm, Jaap Spies [EMAIL PROTECTED] wrote: mabshoff wrote: On Aug 28, 9:18 am, Jaap Spies [EMAIL PROTECTED] wrote: Hi Jaap, I guess sailing season this year is coming to an end :) Not yet! I'll go on until the end of October. BUt there have been some problems :-( The engine broke down. For four weeks I'm waiting for the instalation of a new engine. We were lucky on the 17th of July. Two weeks later the troubles started near Greetsiel (Germany). The last weeks I traveled daily to Delfzijl to work on my ship. Next week I'll continue my trip, I hope. The best of luck - I hope you get your ship working again soon. I guess we can hope for some new matrix permanents code in October then :) SNIP sage -t devel/sage/sage/stats/hmm/chmm.pyx sage -t devel/sage/sage/stats/hmm/hmm.pyx Known problems, but can you post the output at #3978 Sure. Ok, the issues it spits out at are actually sufficiently different so that the doctests have to fix a couple more issues than I originally though. Total time for all tests: 8708.8 seconds Please see /home/jaap/downloads/sage-3.1.2.alpha1/tmp/test.log for the complete log from this test. [EMAIL PROTECTED] sage-3.1.2.alpha1]$ Jaap Cheers, 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: python binding for nauty in optional spkg
On Aug 28, 1:20 pm, Stephen Hartke [EMAIL PROTECTED] wrote: Hi Stephen, I've added my Python binding for nauty into Jason Grout's optional nauty spkg. (Jason: I hope that's okay. Since the extension needs to include nauty and link against it, it seems simplest to include it in one package.) It can be downloaded athttp://www.math.unl.edu/~shartke2/files/nauty-24b7.spkg and sample usage files that call nauty for a Sage graph can be found here:http://www.math.unl.edu/~shartke2/files/sagenauty.tar.bz2 Cool. Both of these works are still preliminary, and I have questions about the best way to implement things. Specifically, I have a question about linking the extension: The Python extension is linked against nauty object files, and gcc complains these should be compiled with the flag -fPIC to make relocatable code. nauty does not have this flag normally, so I modified the makefile to add this flag using sed. Is the right way to handle this problem? Is it okay for the executables that Jason is installing in bin to be compiled with -fPIC, or should two separate compilings be done? A fix that like should go upstream, but it is probably most easily added by setting CFLAGS. If someone opens a ticket and links the spkg there I can get it reviewed and hopefully merged soon. Thanks for any input! Stephen 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: python binding for nauty in optional spkg
On Aug 28, 2:54 pm, Jason Grout [EMAIL PROTECTED] wrote: Hi, Stephen Hartke wrote: I've added my Python binding for nauty into Jason Grout's optional nauty spkg. (Jason: I hope that's okay. Since the extension needs to include nauty and link against it, it seems simplest to include it in one package.) It can be downloaded at http://www.math.unl.edu/~shartke2/files/nauty-24b7.spkg and sample usage files that call nauty for a Sage graph can be found here: http://www.math.unl.edu/~shartke2/files/sagenauty.tar.bz2 I think it's a great idea to include a more natural interface to nauty in the spkg. +1 Both of these works are still preliminary, and I have questions about the best way to implement things. Specifically, I have a question about linking the extension: The Python extension is linked against nauty object files, and gcc complains these should be compiled with the flag -fPIC to make relocatable code. nauty does not have this flag normally, so I modified the makefile to add this flag using sed. Is the right way to handle this problem? Is it okay for the executables that Jason is installing in bin to be compiled with -fPIC, or should two separate compilings be done? Others (mabshoff?) can comment on what to do about -fPIC. However, my guess is that using sed at spkg install time is probably not a good idea, or at least not in line with official practices. It seems that the official way to change the makefile is to store the new makefile in the patches directory and copy it over to the src directory at spkg install time. Using sed in general is fine since various packages in Sage do depend on it at build time. But Jason is right that it should be changed in the makefile, put into patches and then copied over in spkg-install at build time. If someone opens a ticket I will review the spkg and hopefully someone else will look at the Python bindings. Depending on how things are we might also upgrade to the latest upstream release at the same time. Thanks for your work on this! +1 Jason 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] Doc Day 3: Saturday August 30th, 2008
Hello folks, September 1st is around the corner and we wanted to hit 60% coverage by the end of August. The current coverage in my alpha2 merge tree is Overall weighted coverage score: 57.2% Total number of functions: 20912 and Mike Hansen is writing doctests for all the expect interfaces as I type this message. So we wanted to get together this Saturday and hopefully get close to the 60% goal. I would suggest getting together this Saturday around 10 am PST and knock out doctest patches and get them reviewed and merged. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Additive Groups
On Aug 29, 2:24 am, Nils Skoruppa [EMAIL PROTECTED] wrote: SNIP Hi Nils, I cannot explain why this works, but if you want to have a look:http://hg.countnumber.de/fqm-devel/file/98bb736f0c07/cn_group/finite_... (and then line 2132 class FiniteQuadraticModuleElement(AdditiveGroupElement). ---Nils Out of curiosity: Do you plan to submit the code to Sage eventually? 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] Sage 3.1.2.alpha2 released
Hello folks, here is alpha2. We fixed another boatload of small and not so small issues. The performance regression with plotting is fixed, but there are still doctesting issues with the ghmm code. We will tackle that in alpha3 which hopefully will be done before Doc Day 3. Aside from that we also updated jmol and a bunch of other spkgs. One goal is to upgrade ATLAS to the 3.8.2 release in alpha3 and also finish up merging a bunch of the 40 or so patches awaiting review. The goal of Doc Day 3 is to get coverage up to 60% from currently 57.3%. To reach that goal we need to add 564 doctests (unless we remove some dead code), so this is certainly an ambitious goal. Sources are at http://sage.math.washington.edu/home/mabshoff/release-cycles-3.1.2/sage-3.1.2.alpha2.tar and a sage.math only binary is at http://sage.math.washington.edu/home/mabshoff/release-cycles-3.1.2/sage-3.1.2.alpha2-sage.math-only-x86_64-Linux.tar.gz Thoughts? Comments? Cheers, Michael #132: Simon King, Mike Hansen: maxima -- implement special arithmetic for MaximaFunction class [Reviewed by Martin Albrecht] #772: Carl Witty, Jason Grout: create experimental QEPCAD.spkg for quantifier elimination and solving systems of inequalities [Reviewed by Michael Abshoff, Jason Grout, Carl Witty] #1952: Martin Albrecht, Mike Hansen: Follow up to #1940: Ideal comparison improvements [Reviewed by Mike Hansen, Martin Albrecht] #2209: Steve Linton: gap on itanium - incorporate steve linton's new fixes so gap builds fine with optimizations [Reviewed by William Stein] #2366: Mike Hansen: add docstring to sloane_find and sloane_sequence [Reviewed by Timothy Clemans] #3253: Alex Ghitza: f.jacob() used to work to compute jacobian ideal. Now it doesn't [Reviewed by Martin Albrecht] #3431: Carl Witty: QEPCAD interface [Reviewed by Jason Grout] #3440: Martin Albrecht: Our PolyBoRi's GB calculation in AES mode is broken [Reviewed by Burcin Erocal] #3630: Yi Qiang: upgrade twisted.spkg to 8.1.0 release [Reviewed by Michael Abshoff] #3635: Martin Albrecht: If m is a matrix, then m.plot() should call matrix_plot [Reviewed by Jason Grout] #3823: Igor Tolkov: Interact - get rid of default height [Reviewed by Jason Grout] #3883: John Cremona: Streamline elliptic curve division (torsion) polynomials [Reviewed by Chris Wuthrich] #3892: Hamish Ivey-Law, Martin Albrecht: PowerSeries random element over GF(q) (Givaro) fails [Reviewed by Alex Ghitza] #3909: Josh Kantor: Updating jmol package to 11.6rc8 [Reviewed by Jason Grout, Michael Abshoff] #3915: Martin Albrecht: PolyBoRi interface improvements [Reviewed by Michael Brickenstein] #3935: Jason Merrill: ode_solver __init__ method ignores many parameters [Reviewed by Jason Grout] #3961: John Cremona: bug in ell_finite_field.abelian_group() [Reviewed by Alex Ghitza] #3965: Martin Albrecht: one line fix for PolyBoRi to Magma conversion [Reviewed by Burcin Erocal] #3966: Jason Grout: The ode cython example gives errors [Reviewed by Jason Merrill] #3968: Jason Grout: Magma interface sometimes fails on long inputs [Reviewed by Willem Jan Palenstijn] #3971: William Stein: hidden markov models -- implement nsteps and log_likelihood_cutoff [Reviewed by Josh Kantor] #3972: Michael Abshoff: 3.1.2.alpha1: numerical noise in plot.py [Reviewed by Craig Citro] #3973: Chris Wuthrich: short_weierstrass_model in characteristic 3 [Reviewed by John Cremona] #3975: Arnaud Bergeron: Small mistake in the new plot() code [Reviewed by Mike Hansen] #3976: Mike Hansen: improve doctests to expect.py, maxima.py, and lie.py [Reviewed by Robert Miller] #3977: Mike Hansen: get interfaces/octave.py up to 100% coverage [Reviewed by Robert Miller] #3982: Robert Miller: Pipe stdout to /dev/null to help sage_timeit with print statements [Reviewed by Mike Hansen] #3983: Mike Hansen: get coverage for sage/interfaces/sage0.py up to 100% [Reviewed by Michael Abshoff] #3989: Michael Abshoff: fix autotools issues with gd-2.0.35 [Reviewed by Craig Citro] --~--~-~--~~~---~--~~ 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: colours in trac
On Aug 29, 3:58 am, John Cremona [EMAIL PROTECTED] wrote: 2008/8/29 chris wuthrich [EMAIL PROTECTED]: Hi, I wonder if a user can change the colours on the trac pages for patches. Being green-red colour-blind, I would prefer to swap, say, green for blue. +1 from another red-green challenged developer. John we can likely fix the CSS for the trac patch page, so I see little problems there. Harald: Can you poke around? Otherwise I will do it once I get up again. PS Chris, I have nearly finished my re-working of your elliptic curve torsion over number fields enhancement. Nice. Sorry if this question is not really a sage-devel question... Chris. No problem, issues like that are relevant for development, so feel free to raise them. 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.1.2.alpha2 released
On Aug 29, 7:09 am, John Cremona [EMAIL PROTECTED] wrote:
Build reports for 3.1.2.alpha2
Hi John,
32-bit still running
64-bit on
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
Build ok, one doctest failed: sage -t devel/sage/sage/interfaces/octave.py
Details: (it appears that this machine does not have octave, but
surely -testall should be able to detect that instead of failing?
sage -t devel/sage/sage/interfaces/octave.py
**
File /home/jec/sage-3.1.2.alpha2/tmp/octave.py, line 279:
sage: octave.set('x', '2') #optonal -- requires Octave
Notice optonal - this needs to be optional. That is now #3992 and
I will likely post the trivial patch that fixes this in 3 minutes.
Thanks for testing - let's hope 32 bit goes well, too.
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.1.2.alpha2 released
On Aug 29, 10:16 am, John Cremona [EMAIL PROTECTED] wrote: 2008/8/29 mabshoff [EMAIL PROTECTED]: Hi John, Thanks for testing - let's hope 32 bit goes well, too. The following tests failed: sage -t devel/sage/sage/stats/hmm/chmm.pyx sage -t devel/sage/sage/stats/hmm/hmm.pyx Ok, those two will hopefully be resolved today. sage -t devel/sage/sage/matrix/matrix_mod2_dense.pyx Malb has a patch coming for this, but Robert also seems to be working on matrix hashing - so we will see how it goes. sage -t devel/sage/sage/interfaces/octave.py Patch is up at #3992 and should be trivial to review. The first three are the same as in alpha1, and the last you know about! 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: virtual box
On Aug 29, 12:31 pm, bnewbold [EMAIL PROTECTED] wrote: Hi, I got pretty frustrated setting up vmware (workstation, have a license through school) under Ubuntu linux for the purpose of building a FreeBSD development image; lots of license issues, networking was a pain to configure, and eventually I gave up after spending too many weekend hours on it. I'd be interested in trying VirtualBox OSE though, would that be an acceptable alternative for development images? My tolerance for pain is much higher for open source applications. FWIW, i'd still be happy to configure a FreeBSD development environment if somebody else gets it set up somewhere I can log in to. I'd also be willing to give one or two trusted developers logins to my snappy well connected freebsd 6.3 box for development. The MIT student information processing board is also working on providing large numbers of virtual machines to students for any purpose, once that project stabilizes I can try setting up a hosted image there. -bryan There are FreeBSD VMWare images out there - for example http://www.thoughtpolice.co.uk/vmware/. I have been playing with one of them (6.2 based), but the port I have been doing will likely be based on the latest release, i.e. 7. The fixes for 6.x are minor AFAIK and patches are always 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage on french TV
On Aug 29, 2:34 pm, Jaap Spies [EMAIL PROTECTED] wrote: Philippe Saade wrote: Hi dev team, Some of you know that wednesday and thursday i made an official presentation of Sage at the Maths' Teachers' Summer School (French Educational System). Notebook ended up on TV (well 3 seconds) i my respectable person too :-) If you want to have a look at it : http://jt.france3.fr/regions/popup.php?id=c63a_1920 (you can start playing the video at 05'06'' ) Windows only? :-( !? It is Windows Media Player that is to blame here. Given enough spare time one can use open source tools to get it to play, but it would be easier if someone grabbed the stream and converted it to something saner. Jaap They don't mention Sage but it's funny to see the notebook !! I'll tell you more in few hours. Cool. Regards Philippe 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: reopening Sage - Blender discussion
On Aug 29, 4:52 pm, Carl Witty [EMAIL PROTECTED] wrote: On Aug 29, 4:36 pm, Philippe Saade [EMAIL PROTECTED] wrote: Hi, Hi, after many discussion with Sage potential users (this week, around me), i get convinced that it would be great to use Blender Python APi to rendre 3D scenes and animations. I have done some 3D animations few years ago with Blender (all of science facts, so mostly computed mesh) and even if the learning of the API sometimes was hard, the result was really satisfactory to me. Has anybody an opinion on that ? I think it would be great to have an optional Blender spkg, and some code in the Sage library to facilitate working with the API from within Sage (for instance, a Blender backend for plot3d). Once we got some experience with this, we could talk about making Blender a standard part of Sage, but I doubt if we'd do that... Blender is awfully big (the Debian package is more than 20 megabytes). Hehe, jmol isn't exactly lightweight either, but I agree with Carl here. In the future of Sage I see a core that people will start building distribution like packages around, i.e. Sage for Physicists for example. Unfortunately, I don't have any time to work on this project. Fortunately there are Blender Python bindings - see http://www.blender.org/documentation/245PythonDoc/API_intro-module.html Carl 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: Doc Day 3: Saturday August 30th, 2008
On Aug 28, 3:43 pm, mabshoff [EMAIL PROTECTED] wrote: Hello folks, September 1st is around the corner and we wanted to hit 60% coverage by the end of August. The current coverage in my alpha2 merge tree is Overall weighted coverage score: 57.2% Total number of functions: 20912 and Mike Hansen is writing doctests for all the expect interfaces as I type this message. So we wanted to get together this Saturday and hopefully get close to the 60% goal. I would suggest getting together this Saturday around 10 am PST and knock out doctest patches and get them reviewed and merged. Thoughts? Hi, this is reminder about tomorrow's Doc Day. The current alpha3 merge tree has the following coverage Overall weighted coverage score: 57.8% This is in very large part thanks to the work by Mike Hansen who has been adding doctests mainly to the interface directory. We will likely put out alpha3 before Doc Day, so if you are adding doctests to something related to plotting, MV polynomials or interfaces it is highly recommended that you upgrade to alpha3 before writing code in that area. Most areas aside from that should be fine with 3.1.2.alpha2 or even 3.1.1. Cheers, Michael 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: Doc Day 3: Saturday August 30th, 2008
On Aug 29, 7:42 pm, Martin Albrecht [EMAIL PROTECTED] wrote: Hi there, Hi Martin, I've got a couple of questions about Doc Day 3. Who is attending? There doesn't seem to be Wiki page for it. At least William, Mike Hansen, rlm and me will meet physically in Seattle. We will probably do a wiki page in the next couple hours. The Doc Day grew out of the motivation to achieve the 60% goal for doctests that William set a while back. Also, the last bug day was underwhelming since as far as I can tell not that many people showed up. I suspect this is related to the short notice with which these days are announced or even the fact that they are announced rather than proposed (I mean mainly the date here). Yes, I agree with 100% and you did raise the issue in IRC, too, so I did not forget. It has been noticeable that the more short term *Days have had fewer people attend, but these days the usual suspects get together in IRC anyway before a release and/or on Saturdays. I'd therefor suggest: At least announce these days 2 or 3 weeks before they happen such that one can make plans. Also, proposing two alternative dates + vote on a favorite might be beneficial. This way, hopefully more people show up and it is more fun. I agree. We should probably plan to do a Bug Day the Saturday in two weeks then. Furthermore, it might be a good idea to stress in these announcements/proposals that everybody is welcome. I.e. if someone wants to get started with Sage development but doesn't know how/when/what, this is his/her chance to get any question about Sage answered in realtime. Absolutely - we should probably come up with some boilerplate announcement text that only needs the details added. Did you just volunteer to write one? :) Thoughts? 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Error installing pynac
On Aug 29, 7:57 pm, Jason Merrill [EMAIL PROTECTED] wrote: Hi Jason, I tried to install pynac on OS X 10.5, but it died. Here's an excerpt of install.log pynac-0.1 Machine: Darwin jmerrill.local 9.4.0 Darwin Kernel Version 9.4.0: Mon Jun 9 19:30:53 PDT 2008; root:xnu-1228.5.20~1/RELEASE_I386 i386 Deleting directories from past builds of previous/current versions of pynac-0.1 Extracting package /Applications/sage/spkg/optional/pynac-0.1.spkg ... -rw-r--r-- 1 jm843 admin 268 Aug 26 23:14 /Applications/sage/ spkg/optional/pynac-0.1.spkg pynac-0.1/ pynac-0.1/.hg/ ... Configuration of GiNaC 1.4.3 done. Now type make. cd . /bin/sh /Applications/sage/spkg/build/pynac-0.1/src/missing -- run autoheader This probably needs to be done once in the spkg sources before packaging them. aclocal.m4:14: error: this file was generated for autoconf 2.61. You have another version of autoconf. If you want to use that, you should regenerate the build system entirely. aclocal.m4:14: the top level autom4te: /opt/local/bin/gm4 failed with exit status: 63 autoheader: '/opt/local/bin/autom4te' failed with exit status: 63 make: *** [config.h.in] Error 1 Error building ginac. I guess the important bit is you have another version of autoconf, but I don't know what I should do about it. My thanks for any advice. We will fix it in the spkg. We had some similar issues just now in the gd-2.0.35.spkg. JM 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: Vote for new spkg: gp2c
Hi, I guess due to lack of interest we will make gp2c an optinal.spkg. I need to investigate how that works out, but since I want to upgrade pari anyway to the latest release I can integrate those changes needed for gp2c in its spkg-install. 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.1.2.alpha2 released
On Aug 30, 2:36 am, Jaap Spies [EMAIL PROTECTED] wrote: mabshoff wrote: SNIP Hi Jaap, Where have I seen this before? the same issue hit your box before and we ended up filtering some non- ascii characters out of the stream. I will dig for the ticket and see what is turning up. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] #4006: Remove unused code in sage/libs/pari/functional.py
Hi, while looking for code to doctest Mike Hansen came across sage/libs/ pari/functional.py It is a file with 191 one line functions that attempt to do things like the following: def FOO(x): return pari(x).FOO() There is no user of the code, the only file that imports it is bg.py which is another file that looks like something that got abandoned. The import in bg.py is also broken. So we ended up deleting both files since a) the code is broken b) there are no users c) the code even if it worked would have never passed review would it be submitted now d) the code is unchanged since early 2006, i.e. except for a one line addition it is unchanged since *0.10.12* So if anybody has any use of the code please let us know. For now the code is gone and resubmitting it for inclusion will require a substantial amount of work. 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: colours in trac
Hi Chris, Mike Hansen and I changed the green to blue in the diff view for patches. Could you let us know if this is better for you? 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.1.2.alpha3 released
On Aug 31, 7:44 am, John Cremona [EMAIL PROTECTED] wrote: Hi John, Build report 1: on the 64-bit machine 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 I have three all-new failures: sage -t devel/sage/sage/interfaces/sage0.py sage -t devel/sage/sage/interfaces/lisp.py sage -t devel/sage/sage/tests/benchmark.py The last one is all about missing maple (which is not installed on that machine). The others are quite long, but I can post them if that would be helpful. Can you post all three outputs please? The last one should be easy enough to fix, the other two likely involve stripping some \n from the commands - at least that seems what jaap did hit. My 32-bit build is still running since I forgot to set SAGE_ATLAS_LIB... That long build time for ATLAS ought to be fixed in 3.8.2.final. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.1.2.alpha3 released
On Aug 31, 3:33 pm, David Joyner [EMAIL PROTECTED] wrote: Built fine on amd64 hardy heron but the test for benchmark.py failed. Do you want me to post it? It was similar to the output John posted. Hi David, I don't think we will need it. The Maple issue is now #4025 and I will post a patch there shortly and ping you to test it once it is up. 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: Doc Day 3: Saturday August 30th, 2008
Hi, as it turned out about 6 people contributed doctest patches while a number of other people dropped by and did some other work. So in total I would call it a success, especially since we reached 59.9% coverage and with some of the patches posted, but not reviewed in time for 3.1.2 we will make it past 60% today :) 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.1.2.alpha3 released
On Aug 31, 4:33 pm, Martin Albrecht [EMAIL PROTECTED] wrote: On Sunday 31 August 2008, John Cremona wrote: SNIP Hi there, that means that I screwed up 32-bit compatibility. I'll look into it tomorrow. This is now #4027. Note that on OSX in addition the following happens too: m4ri_mm_calloc: calloc returned NULL. Then the doctest actually crashes. I am checking into whether the latest upstream fixes it or now. Cheers, 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Followup to Sage 3.1.2.alpha3 released - new_with_bits_prec(pi, 100) issue
Hi, this is a followup to the above thread. Mike Hansen wrote a doctest for gp.py and we hit the following problem: sage -t devel/sage/sage/interfaces/gp.py ** File /Users/mabshoff/sage-3.1.2.alpha3/tmp/gp.py, line 522: sage: gp.new_with_bits_prec(pi, 100) Expected: 3.1415926535897932384626433832795028842 Got: 3.141592653589793238462643383 ** 1 items had failures: 1 of 3 in __main__.example_27 ***Test Failed*** 1 failures. For whitespace errors, see the file /Users/mabshoff/sage-3.1.2.alpha3/ tmp/.doctest_gp.py [4.1 s] exit code: 1024 But notice the following: 32 bit: bash-3.2$ ./sage -- | SAGE Version 3.1.2.alpha3, Release Date: 2008-08-31| | Type notebook() for the GUI, and license() for information.| -- sage: gp.new_with_bits_prec(pi, 100) 3.141592653589793238462643383 sage: gp.new_with_bits_prec(pi, 1000) 3.141592653589793238462643383 sage: gp.new_with_bits_prec(pi, 1) 3.141592653589793238462643383 sage: gp.new_with_bits_prec(pi, 10) 3.141592653589793238462643383 64 bit: [EMAIL PROTECTED]:/scratch/mabshoff/release-cycle/sage-3.1.2.alpha3$ ./ sage -- | SAGE Version 3.1.2.alpha3, Release Date: 2008-08-31| | Type notebook() for the GUI, and license() for information.| -- sage: gp.new_with_bits_prec(pi, 100) 3.1415926535897932384626433832795028842 sage: gp.new_with_bits_prec(pi, 1000) 3.1415926535897932384626433832795028842 sage: gp.new_with_bits_prec(pi, 1) 3.1415926535897932384626433832795028842 sage: gp.new_with_bits_prec(pi, 100) 3.1415926535897932384626433832795028842 I remember there being another ticket where the precision from pari went a little nuts and I believe there is a patch by John Cremona. But the above seems either related or a similar bug. We are tracking the issue at #4023 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.1.2.alpha3 released
On Aug 31, 8:57 pm, Jaap Spies [EMAIL PROTECTED] wrote: mabshoff wrote: Hello folks, Doc Day 3 went well and we barely missed the goal of 60% coverage with 59.9%. Tomorrow we will merge a couple more patches from the que and will surpass the August 2008 goal. Aside from the doctesting code merged a couple of long standing open ticket like the libm4ri improvements. Binaries and sources are in the usual place, i.e. http://sage.math.washington.edu/home/mabshoff/release-cycles-3.1.2/ Tomorrows plan is to finish merging features, i.e. ATLAS 3.8.2. and then put out 3.1.2.rc0 and then hopefully make a release on Monday or Tuesday. Please build and test and report any unknown problems. On Fedora 9, 32 bits: Hi Jaap, let me guess: -- The following tests failed: sage -t devel/sage/sage/graphs/graph_generators.py Timeout sage -t devel/sage/sage/matrix/matrix_mod2_dense.pyx #4027 sage -t devel/sage/sage/combinat/root_system/weyl_characters.py Timeout sage -t devel/sage/sage/interfaces/lisp.py synchronization issues - we can reproduce this on OSX now. sage -t devel/sage/sage/interfaces/gp.py #4023 sage -t devel/sage/sage/interfaces/sage0.py newline crap? ipython escape sequence noise? sage -t devel/sage/sage/stats/hmm/chmm.pyx sage -t devel/sage/sage/stats/hmm/hmm.pyx known issue. Total time for all tests: 10240.8 seconds Please see /home/jaap/downloads/sage-3.1.2.alpha3/tmp/test.log for the complete log from this test. [EMAIL PROTECTED] sage-3.1.2.alpha3]$ Jaap So it looks like we will do alpha4 tonight/tomorrow since we have quite a number of issues to fix. Hopefully William will be around on Monday so we can start killing the last couple release critical bugs. 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] Final stretch for 3.1.2 reviews
Hello folks, the end of the 3.1.2 release cycle is near - at least the point where we will only merge bug fixes or even critical bug fixes. So if you have things sitting in trac waiting to make it in please find somebody to review the patch. Please also make sure that the positively reviewed patch shows up at report 11 since that is what I use to find them. One issue I found today is that that report does not pick up ticket if there is more than one space between positive and reviewed. Report 12 in trac are tickets that need work and many of them have been sitting there for a while. So if one of those belongs to you please have a look. 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: Final stretch for 3.1.2 reviews
On Sep 2, 6:43 am, John Cremona [EMAIL PROTECTED] wrote: Hi John, I hope I didn't kill #1115's chances by relabelling it from a bug fix to an enhancement, since I didn't just fix the bug... Nope, code from that area is high level and usually does introduce no failures that are platform specific. And we are still pre-rc0, which will probably take 24 or so hours to get out. The only problem with the current patch is that we found a call to dumps() crashes on a 64-bit machine but is fine on a 32-bit machine. Anyone have any idea what might cause that? No clue. Can you do a sage -ba on the tree and see of the problem goes away? What does the backtrace from gdb say? Are there any weak references involved in that code? We have been seeing oddities with weak references and Cython. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.1.2.alpha4 released
On Sep 2, 9:20 am, John Cremona [EMAIL PROTECTED] wrote: Build reports Hi John, 32-bit: just the already known failures: sage -t devel/sage/sage/stats/hmm/chmm.pyx sage -t devel/sage/sage/stats/hmm/hmm.pyx sage -t devel/sage/sage/interfaces/gp.py on Linux version 2.6.24-19-generic ([EMAIL PROTECTED]) (gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)) #1 SMP Wed Aug 20 22:56:21 UTC 2008 ok, those are all known failures with tickets. 64-bit: just one failure: sage -t devel/sage/sage/interfaces/lisp.py on 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 which I think is also in Michael's list of known issues. Yes, it does not have a ticket number yet, but will do so shortly. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Script in spkg/base not commited
On Sep 3, 10:46 am, Arnaud Bergeron [EMAIL PROTECTED] wrote: Hi Arnaud, hg diff in spkg/base gives the diff at the bottom in a just-extracted sage-3.1.2.alpha4. Should this repository be ignored or is this just an oversight? Oops, those scripts get copied from the local/bin repo and are indeed out of date. I will check them in - this happens every once in a while. Thanks, 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] Sciface Software GmbH (makers of MuPAD) bought by Mathworks (i.e. the MATLAB people)
In German from heise.de: http://www.heise.de/newsticker/MuPAD-verschwindet-aber-nur-als-Produktname--/meldung/115390 the gist: * MuPAD will only be sold until September 28th 2008 * MuPAD (Pro) licenses will remain valid * MuPAD will be available as part of the symbolic Matlab toolbox * MuPAD applications will run im größtmöglichen Ausmaß (to the largest extend possible?) with Matlab's Symbolic Math Toolbox 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 -~--~~~~--~~--~--~---
