[sage-devel] Re: Sage 2.11.alpha1 released!
On Mar 26, 5:45 am, Justin C. Walker [EMAIL PROTECTED] wrote: Hi, Hichael, On Mar 25, 2008, at 19:16 , mabshoff wrote: On Mar 26, 2:58 am, Justin C. Walker [EMAIL PROTECTED] wrote: On Mar 22, 2008, at 16:02 , mabshoff wrote: http://sage.math.washington.edu/home/mabshoff/release-cycles-2.11/sag ... Things didn't go so well on my system (Mac OS X, 10.5.2, Dual Quad Xeon, -j6). The tail of the log is below. The whole log is on sage.math.washington.edu:~justin/logs/2.10.11.A1.log.[snip] gcc -std=c99 -single_module -fPIC -dynamiclib -o libflint.dylib mpn_extras.o mpz_extras.o memory-manager.o ZmodF.o ZmodF_mul.o ZmodF_mul-tuning.o fmpz.o fmpz_poly.o mpz_poly-tuning.o mpz_poly.o ZmodF_poly.o long_extras.o -L/Users/tmp/sage-2.11.alpha1/local/ lib/ - lgmp -lpthread -lm ld: duplicate symbol ___gmpz_abs in mpz_extras.o and mpn_extras.o [snip] more GMP trouble. Can you post the output from uname -r | sed s/9\. [0-9]\.0/9\.0\.0/ and a uname -a. $ uname -a Darwin zippo 9.2.2 Darwin Kernel Version 9.2.2: Tue Mar 4 21:17:34 PST 2008; root:xnu-1228.4.31~1/RELEASE_I386 i386 $ uname -r | sed s/9\.[0-9]\.0/9\.0\.0/ 9.2.2 Ok, this is the culprit. It will need fixes all over the place and this time we might as well do it right. We haven't touched either the GMP nor the FLINT package in a while, so did you upgrade your OSX or XCode version by any chance? Nope; There hasn't been a (public) update to Xcode for a while. A third possibility is that FLINT is all the sudden picking up a stray gmp.h. Can you check your system? I have two versions of GMP installed: one I built recently in /usr/ local, and one built as part of MacPorts in /opt/local. I moved both out of the way, and rebuilt from scratch: same result. Yeah, the culprit is the above regexp. I will fix those before 2.11.alpha2. Sorry for the mess. I made this #2672 - a blocker for 2.11. Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for the Enhancement of the Director's Income Experience is what you get when you don't get what you want. 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 2.11.alpha1 released!
On Mar 26, 3:25 am, Soroosh Yazdani [EMAIL PROTECTED] wrote: Should I uninstall atlas if I want to check your patch for the future version? Atlas is installed system wide on my computer, and linbox seemed to have found those libraries as it compiled afterward. Is there a way to force linbox to compile against the local version? Cheers, Soroosh If it works now don't worry about it. I am just puzzled that it works the second time around. Did you delete/move/add/change anything in between those two tries? It might be that the system's ATLAS has the f95 runtime library merged into libatlas.a for example. But the problem [the missing -lf95] has popped up often enough here and in linbox-use that I ought to finally fix it via some autoconf magic, unless Clement wants to beat me to it ;) 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 2.11.alpha1 released!
It started working after I installed atlas system wide. Atlas was not installed in the first attempt to compile sage. After linbox failed, my solution was to install atlas through gentoo package manager and try again. Cheers, Soroosh On Wed, Mar 26, 2008 at 3:36 AM, mabshoff [EMAIL PROTECTED] wrote: On Mar 26, 3:25 am, Soroosh Yazdani [EMAIL PROTECTED] wrote: Should I uninstall atlas if I want to check your patch for the future version? Atlas is installed system wide on my computer, and linbox seemed to have found those libraries as it compiled afterward. Is there a way to force linbox to compile against the local version? Cheers, Soroosh If it works now don't worry about it. I am just puzzled that it works the second time around. Did you delete/move/add/change anything in between those two tries? It might be that the system's ATLAS has the f95 runtime library merged into libatlas.a for example. But the problem [the missing -lf95] has popped up often enough here and in linbox-use that I ought to finally fix it via some autoconf magic, unless Clement wants to beat me to it ;) 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: Request for Reviews, Reviews, Reviews!
On Tue, 25 Mar 2008 at 07:22PM -0700, mabshoff wrote: But there are still plenty of patches in trac that deserve to be looked at and merged. Might I recommend 2565? http://sagetrac.org/sage_trac/ticket/2565 The logging facilities currently are totally broken. The above ticket has a patch that not only fixes all the problems with them, but adds a text logger to go along with the html and dvi ones. Dan -- --- Dan Drake [EMAIL PROTECTED] - KAIST Department of Mathematical Sciences --- http://math.kaist.ac.kr/~drake signature.asc Description: Digital signature
[sage-devel] Re: Glib algorithms #2436 vote
+1 --Mike On Tue, Mar 25, 2008 at 7:15 PM, [EMAIL PROTECTED] wrote: On Tue, 25 Mar 2008, Gary Furnish wrote: Trac #2436 adds the following algorithms from glib to libcsage: Multiplatform threads Thread pools Asynchronous Queues Memory Slices Doubly and Singly linked lists Queues Sequences Hash Tables Arrays Balanced Binary Trees N-ary Trees Quarks +1, I can use this to speed up the polynomial evaluation code. In particular it features a slab memory allocator based on: http://citeseer.ist.psu.edu/bonwick94slab.html http://citeseer.ist.psu.edu/bonwick01magazines.html The documentation for glib is found at http://library.gnome.org/devel/glib/2.14/glib-Memory-Slices.html The files are all GPL 2.0 or greater. Although glib normally has extensive dependencies, all of them have been removed, as have parts of glib that are not strictly algorithms (such as string parsing). To avoid autoconf/make troubles, the new parallel build system currently in experimental testing features a simple, elegant python autoconf replacement. The extra build time for libcsage is minimal, and wall time often decreases due to the new parallel build system. Finally, until testing is complete, parallel build and glib are orthogonal and can exist in parallel to all existing Sage code, making review significantly easier. Right now there are no easy to use C libraries included with sage. Using c++ stl requires extremely painful Cython wrapping. Therefore everywhere pure performance is needed, ad hoc solutions are often used (see integer.pyx, etc), which often introduce subtle and painful bugs. Furthermore there are many places in Sage that could benefit from a unified slab allocator (as opposed to a pool which can only grow). Finally the extensive symbolics modifications I am working on make use of glib (especially trees and lists) to enable very fast symbolic manipulations. By using glib algorithms I avoid having to roll my own code that would require extensive manual review and debugging. This code drop is big enough that Mabshoff would like a formal +1 vote, and I'd be happy to address any concerns. Mar 25 00:00:13 mabshoffyes. It isn't an spkg, but the code drop is large enought to warrent a vote. Mar 25 00:00:21 mabshoffYou can quote me on that. Mar 25 00:00:35 mabshoffYou should say *why* it is a good idea and *what* goodies it does provide. Mar 25 00:00:59 mabshoffSince it will only become useful after the switch to pbuild and doesn't Mar 25 00:01:21 mabshoffharm anything with the old build it also doesn't have an impact on the current Mar 25 00:01:24 mabshoffcodebase. Mar 25 00:01:31 mabshoffYou can quote me on that, too. --Gary --~--~-~--~~~---~--~~ 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: Glib algorithms #2436 vote
On Wednesday 26 March 2008, Gary Furnish wrote: Trac #2436 adds the following algorithms from glib to libcsage: Multiplatform threads Thread pools Asynchronous Queues Memory Slices Doubly and Singly linked lists Queues Sequences Hash Tables Arrays Balanced Binary Trees N-ary Trees Quarks I am all for that, so +1. In particular it features a slab memory allocator based on: http://citeseer.ist.psu.edu/bonwick94slab.html http://citeseer.ist.psu.edu/bonwick01magazines.html The documentation for glib is found at http://library.gnome.org/devel/glib/2.14/glib-Memory-Slices.html The files are all GPL 2.0 or greater. Although glib normally has extensive dependencies, all of them have been removed, as have parts of glib that are not strictly algorithms (such as string parsing). To avoid autoconf/make troubles, the new parallel build system currently in experimental testing features a simple, elegant python autoconf replacement. The extra build time for libcsage is minimal, and wall time often decreases due to the new parallel build system. Finally, until testing is complete, parallel build and glib are orthogonal and can exist in parallel to all existing Sage code, making review significantly easier. Right now there are no easy to use C libraries included with sage. Using c++ stl requires extremely painful Cython wrapping. Therefore everywhere pure performance is needed, ad hoc solutions are often used (see integer.pyx, etc), which often introduce subtle and painful bugs. This was already discussed at http://groups.google.com/group/sage-devel/browse_thread/thread/a25146f45a5c6b97/3e996f8485802a01 and IMHO the outcome was that it is unclear whether GLIB can improve the integer.pyx experience. There is a reason integer.pyx looks like it does (avoiding going up the inheritance tree etc.). Furthermore there are many places in Sage that could benefit from a unified slab allocator (as opposed to a pool which can only grow). Sage already ships several Slab allocators: PyMem_Malloc, OMalloc, Givaro's slab allocator etc. Sure Sage could use those more but adding another slab allocator won't help, unless: - it is easier to debug, develop with, enable/disable, etc and/or - it offers better performance. Cheers, Martin -- 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 question, possible contribution to project
At this link, http://sagemath.org/doc/html/prog/node1.htmlwe have, Absolutely *everybody* who uses *Sage* should contribute something back to *Sage* at some point. I have had my fun with sage, and debated, How can I return something to the community, however small? I submitted a couple documentation fixes, but probably to the wrong place. A few questions led to tickets bug fixes. I have a trac account at *dmoore*. Had time when too distracted to submit code / fixes / whatever, but a bit more time now. I recently was fiddling with something that required the area of a polygonhttp://mathworld.wolfram.com/PolygonArea.html, which does not seem implemented that I can find -- this linkhttp://www.google.com/search?hl=enlr=as_qdr=allq=polygon+area++site%3Ahttp%3A%2F%2Fsagemath.orgbtnG=Searchdoesn't return much. I wrote some code to do it. While fairly simple, perhaps others will find it useful. It's not too hard to code a few other things as, say, centroid. A start -- the usual observations of the construction of Rome. Or if other things are hotter,' so be it. Wasn't sure where such should go. Maybe http://www.sagemath.org/hg/sage-main/file/211b127eab5d/sage/plot/graph.py ? Read through the coding guide gave what I thought a basic format to my function, possible gotchas!, what not. Of perhaps some note in a different department, I recently posted something at published workbooks https://www.sagenb.org/pub, but there is an Internal Server Error when I try to go there. The error has been there a good while. Probably deserves to be looked at. Thanks for ideas. Dean --~--~-~--~~~---~--~~ 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 2.11.alpha1 released!
On Mar 26, 2008, at 24:27 , mabshoff wrote: On Mar 26, 5:45 am, Justin C. Walker [EMAIL PROTECTED] wrote: On Mar 25, 2008, at 19:16 , mabshoff wrote: [snip] more GMP trouble. Can you post the output from uname -r | sed s/9\. [0-9]\.0/9\.0\.0/ and a uname -a. $ uname -a Darwin zippo 9.2.2 Darwin Kernel Version 9.2.2: Tue Mar 4 21:17:34 PST 2008; root:xnu-1228.4.31~1/RELEASE_I386 i386 $ uname -r | sed s/9\.[0-9]\.0/9\.0\.0/ 9.2.2 Ok, this is the culprit. It will need fixes all over the place and this time we might as well do it right. Oh, what the heck. Do it wrong for a couple of more times :-} We haven't touched either the GMP nor the FLINT package in a while, so did you upgrade your OSX or XCode version by any chance? Nope; There hasn't been a (public) update to Xcode for a while. A third possibility is that FLINT is all the sudden picking up a stray gmp.h. Can you check your system? I have two versions of GMP installed: one I built recently in /usr/ local, and one built as part of MacPorts in /opt/local. I moved both out of the way, and rebuilt from scratch: same result. Yeah, the culprit is the above regexp. I will fix those before 2.11.alpha2. Sorry for the mess. I made this #2672 - a blocker for 2.11. You certainly don't have to apologize. This is why god invented the alpha cycle :-} Justin -- Justin C. Walker, Curmudgeon-At-Large, Director Institute for the Enhancement of the Director's Income The path of least resistance: it's not just for electricity any more. --~--~-~--~~~---~--~~ 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 2.11.alpha1 released!
On Mar 26, 4:43 pm, Justin C. Walker [EMAIL PROTECTED] wrote: On Mar 26, 2008, at 24:27 , mabshoff wrote: Ok, this is the culprit. It will need fixes all over the place and this time we might as well do it right. Oh, what the heck. Do it wrong for a couple of more times :-} Poking around it isn't too bad, so the fixes will be in alpha2. We haven't touched either the GMP nor the FLINT package in a while, so did you upgrade your OSX or XCode version by any chance? Nope; There hasn't been a (public) update to Xcode for a while. A third possibility is that FLINT is all the sudden picking up a stray gmp.h. Can you check your system? I have two versions of GMP installed: one I built recently in /usr/ local, and one built as part of MacPorts in /opt/local. I moved both out of the way, and rebuilt from scratch: same result. Yeah, the culprit is the above regexp. I will fix those before 2.11.alpha2. Sorry for the mess. I made this #2672 - a blocker for 2.11. You certainly don't have to apologize. This is why god invented the alpha cycle :-} Yeah, but that mean that any Sage release that is supposed to work will so far only work up to 10.5.1. I didn't know that the tiny version number of OSX can be unequal to zero. Justin 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 Journal
Hello all I had the idea of publishing an online Journal with articles about Sage - a mixture between blogs and a real journal. This could be an excellent vehicle to promote Sage and the ideas behind to a bigger audience. This could be about: * how to use Sage, explaining functionalities, ... * new features, new packages * changes * article for new users, introduction * algorithms, explain some details * developer's corner: something for those who actually program Sage or with Sage * teaching: how to teach with Sage * politics/philosophy/community/... * events I've written down my ideas on that page: http://wiki.sagemath.org/SageJournal Have a look and decide if you want to write an article, because that's the most important ingredient of all !!! greetings, Harald (designated editor) --~--~-~--~~~---~--~~ 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 question, possible contribution to project
On Wednesday 26 March 2008 11:34, dean moore wrote: At this link, http://sagemath.org/doc/html/prog/node1.htmlwe have, Absolutely *everybody* who uses *Sage* should contribute something back to *Sage* at some point. I have had my fun with sage, and debated, How can I return something to the community, however small? I submitted a couple documentation fixes, but probably to the wrong place. A few questions led to tickets bug fixes. I have a trac account at *dmoore*. I can't speak for the rest of the developers, but as someone who has submitted a decent number of patches and has more in the works, I don't at all think you should let that sentence about everybody contributing make you feel guilty. Personally, I'd be much more happy with a statement like: Absolutely *everybody* who uses *Sage* is in a position to contribute something back to *Sage* at some point -- bug reports, mailing list participation, evangelism, and simple patches are all meaningful contributions. However, even if you do none of those little things, it is virtually inconceivable that you can be a heavy user of opensource with-out doing at least some evangelism or bug reporting. If you pay me back for my patches by doing something for another totally unrelated package that I use (or maybe don't happen to use), I feel well-paid. And, well shoot, I've already been paid by learning so much from the other sage developers. Helping sage development is worth it simply for the educational value. I realize that guilt is probably not your main motivation, but I'm just sharing my thoughts as a long time user of opensource software who also doesn't feel like I've contributed back as many good things as I've enjoyed myself. -- Joel --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 2.11.alpha1 released!
On Mar 26, 2008, at 09:15 , mabshoff wrote: On Mar 26, 4:43 pm, Justin C. Walker [EMAIL PROTECTED] wrote: On Mar 26, 2008, at 24:27 , mabshoff wrote: [snip] Yeah, the culprit is the above regexp. I will fix those before 2.11.alpha2. Sorry for the mess. I made this #2672 - a blocker for 2.11. You certainly don't have to apologize. This is why god invented the alpha cycle :-} Yeah, but that mean that any Sage release that is supposed to work will so far only work up to 10.5.1. I didn't know that the tiny version number of OSX can be unequal to zero. This sed script must be new, then. Here's what I get from that macro on 10.4.11: 8.11.1 Note: this is how the Mac OS X versions and darwin/xnu versions line up: 10.5.2 9.2.2 10.4.11 8.11.1 The third position in the kernel version is independent of the 3rd position in the Mac OS X version. For the kernel, the third position corresponds to a (released) version of the xnu kernel. Thus, as of 10.5.2, there have been three 10.5 kernels, 9.2.0, 9.2.1, and 9.2.2). It's possible that not everyone will see a given point-release of a kernel (e.g., when a major new platform is released, it may require a point-release of the kernel). Note also that these positions need not be single digits. We've seen that in 10.4 (the minor Mac OS X releases 10.4.10 and 10.4.11 broke a number of software hacks that expected only single digits). Justin -- Justin C. Walker, Curmudgeon at Large Institute for the Absorption of Federal Funds --- If it weren't for carbon-14, I wouldn't date at all. --- --~--~-~--~~~---~--~~ 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: Glib algorithms #2436 vote
On Mar 25, 5:12 pm, Gary Furnish [EMAIL PROTECTED] wrote: Trac #2436 adds the following algorithms from glib to libcsage: Multiplatform threads Thread pools Asynchronous Queues Memory Slices Doubly and Singly linked lists Queues Sequences Hash Tables Arrays Balanced Binary Trees N-ary Trees Quarks +1, I've been waiting for this! --~--~-~--~~~---~--~~ 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: Glib algorithms #2436 vote
Is any of the code gpl v3+ only? How difficult will it be to update our version whenever upstream changes? Do only you know how to do this? Why put this in c_lib instead of a separate spkg called glib-min? Couldn't such a package be useful outside of sage? Any chance the glib people might see this as a fork? On 3/26/08, Robert Miller [EMAIL PROTECTED] wrote: On Mar 25, 5:12 pm, Gary Furnish [EMAIL PROTECTED] wrote: Trac #2436 adds the following algorithms from glib to libcsage: Multiplatform threads Thread pools Asynchronous Queues Memory Slices Doubly and Singly linked lists Queues Sequences Hash Tables Arrays Balanced Binary Trees N-ary Trees Quarks +1, I've been waiting for this! -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 2.11.alpha1 released!
On Mar 26, 5:53 pm, Justin C. Walker [EMAIL PROTECTED] wrote: On Mar 26, 2008, at 09:15 , mabshoff wrote: On Mar 26, 4:43 pm, Justin C. Walker [EMAIL PROTECTED] wrote: On Mar 26, 2008, at 24:27 , mabshoff wrote: [snip] Yeah, the culprit is the above regexp. I will fix those before 2.11.alpha2. Sorry for the mess. I made this #2672 - a blocker for 2.11. You certainly don't have to apologize. This is why god invented the alpha cycle :-} Yeah, but that mean that any Sage release that is supposed to work will so far only work up to 10.5.1. I didn't know that the tiny version number of OSX can be unequal to zero. This sed script must be new, then. Here's what I get from that macro on 10.4.11: 8.11.1 Note: this is how the Mac OS X versions and darwin/xnu versions line up: 10.5.2 9.2.2 10.4.11 8.11.1 The third position in the kernel version is independent of the 3rd position in the Mac OS X version. For the kernel, the third position corresponds to a (released) version of the xnu kernel. Thus, as of 10.5.2, there have been three 10.5 kernels, 9.2.0, 9.2.1, and 9.2.2). It's possible that not everyone will see a given point-release of a kernel (e.g., when a major new platform is released, it may require a point-release of the kernel). Thanks for providing that info. I didn't know too many details in that area. Note also that these positions need not be single digits. We've seen that in 10.4 (the minor Mac OS X releases 10.4.10 and 10.4.11 broke a number of software hacks that expected only single digits). Yeah, that is exactly what my concern is. The current hack ought to be good for another six months, but I am sure it will bite us in the ass at some point. I plan to use avail.h or something which should be much cleaner. Justin Cheers, Michael -- Justin C. Walker, Curmudgeon at Large Institute for the Absorption of Federal Funds --- If it weren't for carbon-14, I wouldn't date at all. --- --~--~-~--~~~---~--~~ 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 Journal
Hello, On Wed, 26 Mar 2008 09:32:36 -0700 (PDT) Harald Schilly [EMAIL PROTECTED] wrote: I had the idea of publishing an online Journal with articles about Sage - a mixture between blogs and a real journal. This could be an excellent vehicle to promote Sage and the ideas behind to a bigger audience. This could be about: * how to use Sage, explaining functionalities, ... * new features, new packages * changes * article for new users, introduction * algorithms, explain some details * developer's corner: something for those who actually program Sage or with Sage * teaching: how to teach with Sage * politics/philosophy/community/... * events I've written down my ideas on that page: http://wiki.sagemath.org/SageJournal Is it possible to call it Sage Monthly or Quarterly, so that it is not confused with JSage? Burcin --~--~-~--~~~---~--~~ 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: Glib algorithms #2436 vote
On Mar 26, 6:02 pm, William Stein [EMAIL PROTECTED] wrote: Is any of the code gpl v3+ only? No. How difficult will it be to update our version whenever upstream changes? Do only you know how to do this? Not particularly hard. Why put this in c_lib instead of a separate spkg called glib-min? Couldn't such a package be useful outside of sage? It is easiest if we put it into libcsage. Any chance the glib people might see this as a fork? Not really. We don't want to deal with all the i18n crap and other dependencies. If the glib people would provide a stripped down version of glib we should switch. 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 Journal
On Wed, Mar 26, 2008 at 10:08 AM, Burcin Erocal [EMAIL PROTECTED] wrote: Hello, On Wed, 26 Mar 2008 09:32:36 -0700 (PDT) Harald Schilly [EMAIL PROTECTED] wrote: I had the idea of publishing an online Journal with articles about Sage - a mixture between blogs and a real journal. This could be an excellent vehicle to promote Sage and the ideas behind to a bigger audience. This could be about: * how to use Sage, explaining functionalities, ... * new features, new packages * changes * article for new users, introduction * algorithms, explain some details * developer's corner: something for those who actually program Sage or with Sage * teaching: how to teach with Sage * politics/philosophy/community/... * events I've written down my ideas on that page: http://wiki.sagemath.org/SageJournal Is it possible to call it Sage Monthly or Quarterly, so that it is not confused with JSage? Yes, the name should either change as you suggest, or this should somehow merge with JSage, and JSage itself would become less academic. (Note that JSage hasn't really started yet, in any real sense.)Maybe something like Harald is proposing is a better direction to go in that the current JSage direction (which is to be purely very academic and research-oriented). William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Glib algorithms #2436 vote
On Wed, Mar 26, 2008 at 10:09 AM, mabshoff [EMAIL PROTECTED] wrote: On Mar 26, 6:02 pm, William Stein [EMAIL PROTECTED] wrote: Is any of the code gpl v3+ only? No. That's good. How difficult will it be to update our version whenever upstream changes? Do only you know how to do this? Not particularly hard. You didn't answer my second question. Why put this in c_lib instead of a separate spkg called glib-min? Couldn't such a package be useful outside of sage? It is easiest if we put it into libcsage. That's not a good enough answer. Until now almost all code in libcsage and the main sage library has been new code we've written -- except a few exceptions, where we greatly regretted them greatly and moved the code out later. So from experience I'm very opposed to this code being in c_lib. I vote -1 to this code going into sage unless: (1) it is put in a separate spkg, and (2) the process of extracting glib-min from the official glib tarball is automated. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 2.11.alpha1 released!
On Wed, Mar 26, 2008 at 9:15 AM, mabshoff [EMAIL PROTECTED] wrote: On Mar 26, 4:43 pm, Justin C. Walker [EMAIL PROTECTED] wrote: On Mar 26, 2008, at 24:27 , mabshoff wrote: Ok, this is the culprit. It will need fixes all over the place and this time we might as well do it right. Oh, what the heck. Do it wrong for a couple of more times :-} Poking around it isn't too bad, so the fixes will be in alpha2. We haven't touched either the GMP nor the FLINT package in a while, so did you upgrade your OSX or XCode version by any chance? Nope; There hasn't been a (public) update to Xcode for a while. A third possibility is that FLINT is all the sudden picking up a stray gmp.h. Can you check your system? I have two versions of GMP installed: one I built recently in /usr/ local, and one built as part of MacPorts in /opt/local. I moved both out of the way, and rebuilt from scratch: same result. Yeah, the culprit is the above regexp. I will fix those before 2.11.alpha2. Sorry for the mess. I made this #2672 - a blocker for 2.11. You certainly don't have to apologize. This is why god invented the alpha cycle :-} Yeah, but that mean that any Sage release that is supposed to work will so far only work up to 10.5.1. I didn't know that the tiny version number of OSX can be unequal to zero. Yep, that's a serious problem. I have tried about 4 times to upgrade my laptop from 10.5.1 to 10.5.2, but failed every time. The last time, I just left it upgrading before I went to sleep, and 8 hours later it was still sitting there upgrading. Is it supposed to take that long? I'll try upgrading my desktop instead, so we have at least one 10.5.2 machine in the regular testing cycle. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Glib algorithms #2436 vote
On Mar 26, 6:43 pm, William Stein [EMAIL PROTECTED] wrote: On Wed, Mar 26, 2008 at 10:09 AM, mabshoff [EMAIL PROTECTED] wrote: On Mar 26, 6:02 pm, William Stein [EMAIL PROTECTED] wrote: Is any of the code gpl v3+ only? No. That's good. How difficult will it be to update our version whenever upstream changes? Do only you know how to do this? Not particularly hard. You didn't answer my second question. Gary did it and I didn't pay much attention to it. I assume it will be documented. I don't consider such a thing hard once it has been documented. Why put this in c_lib instead of a separate spkg called glib-min? Couldn't such a package be useful outside of sage? It is easiest if we put it into libcsage. That's not a good enough answer. Until now almost all code in libcsage and the main sage library has been new code we've written -- except a few exceptions, where we greatly regretted them greatly and moved the code out later. So from experience I'm very opposed to this code being in c_lib. I vote -1 to this code going into sage unless: (1) it is put in a separate spkg, and We can certainly do that. (2) the process of extracting glib-min from the official glib tarball is automated. That is unlikely to happen since it requires manual interaction. It will break in the next release in six months and writing automated tools will take longer than actually doing the work in the first place. -- 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] hg churn and contributions
Mercurial 1.0 is out now and one of the new standard extensions is the churn command, which apparently gives the numbers of lines of changed code per person (well, per email address). I thought the output (see below) was interesting. This is as of 2.10.4 and a few extra patches on top of it. We all still have a *long* way to go to catch up to William. He is quite literally off the charts (his bar wraps to the next line in my email program). Good job everyone! P.S. Another really cool feature in 1.0 is the qrecord command, which brings the darcs-style interactive commits to mercurial queues (so you can include just part of the changes in a file in a patch). Jason [EMAIL PROTECTED] 424564 ** [EMAIL PROTECTED] 138071 ** [EMAIL PROTECTED] 111518 [EMAIL PROTECTED] 85543 * [EMAIL PROTECTED] 76713 [EMAIL PROTECTED] 74154 [EMAIL PROTECTED]69768 *** [EMAIL PROTECTED]64563 ** [EMAIL PROTECTED] 61706 ** [EMAIL PROTECTED] 36213 *** [EMAIL PROTECTED]32169 *** [EMAIL PROTECTED] 30247 *** [EMAIL PROTECTED] 28010 *** [EMAIL PROTECTED] 21594 ** [EMAIL PROTECTED] 20447 ** [EMAIL PROTECTED] 17300 * [EMAIL PROTECTED]15626 * [EMAIL PROTECTED] 15338 * [EMAIL PROTECTED] 14718 * [EMAIL PROTECTED]9135 [EMAIL PROTECTED] 8580 Emily Kirkman 8475 [EMAIL PROTECTED] 8164 [EMAIL PROTECTED] 7378 [EMAIL PROTECTED]6936 [EMAIL PROTECTED] 5712 [EMAIL PROTECTED] 5045 [EMAIL PROTECTED] 4175 [EMAIL PROTECTED] 3475 [EMAIL PROTECTED]3286 [EMAIL PROTECTED] 3098 [EMAIL PROTECTED]2870 [EMAIL PROTECTED] 2619 [EMAIL PROTECTED] 2445 [EMAIL PROTECTED] 2372 [EMAIL PROTECTED] 2330 [EMAIL PROTECTED]2279 [EMAIL PROTECTED]2167 [EMAIL PROTECTED] 1982 [EMAIL PROTECTED] 1527 [EMAIL PROTECTED]1366 [EMAIL PROTECTED] 1333 [EMAIL PROTECTED] 1316 [EMAIL PROTECTED] 1282 [EMAIL PROTECTED] 1172 [EMAIL PROTECTED]1099 [EMAIL PROTECTED] 1090 [EMAIL PROTECTED] 1058 [EMAIL PROTECTED] 1043 [EMAIL PROTECTED] 1012 [EMAIL PROTECTED] 955 cremona 830 [EMAIL PROTECTED] 543 [EMAIL PROTECTED]513 [EMAIL PROTECTED] 513 [EMAIL PROTECTED] 503 [EMAIL PROTECTED]496 [EMAIL PROTECTED] 396 [EMAIL PROTECTED] 365 [EMAIL PROTECTED]332 Jason Grout 319 [EMAIL PROTECTED] 308 [EMAIL PROTECTED] 277 [EMAIL PROTECTED] 272 [EMAIL PROTECTED]244 [EMAIL PROTECTED]236 [EMAIL PROTECTED] 227 [EMAIL PROTECTED] 211 [EMAIL PROTECTED] 210 [EMAIL PROTECTED] 199 [EMAIL PROTECTED] 189 [EMAIL PROTECTED] 180 [EMAIL PROTECTED] 177 [EMAIL PROTECTED] 174 bill,[EMAIL PROTECTED] 173 [EMAIL PROTECTED]169 [EMAIL PROTECTED]166 [EMAIL PROTECTED] 165 [EMAIL PROTECTED]
[sage-devel] another matrix() corner case for sparse matrices
Ryan Hinton brought up a good point at #2651:
Currently, matrix(3,{(1,1): 2}) gives the 3x2 sparse matrix
[0 0]
[0 2]
[0 0]
However, for other cases, if we specify just the number of rows, the
returned matrix is square (except when we are giving all the entries of
the matrix and there aren't enough entries). So:
Should the above command return the following instead?
[0 0 0]
[0 2 0]
[0 0 0]
Sorry for bringing up the nitpicky corner cases, but since matrix() is
used in a huge number of things, we don't want to mess something up when
we replace the constructor.
Jason
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Sage Journal
Fantastic idea, Harald! Along these lines, how about a Sage User Group? We could hold it on Second Life or use Skype and screen sharing software. --~--~-~--~~~---~--~~ 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 2.11.alpha1 released!
On Mar 26, 2008, at 10:37 , William Stein wrote: On Wed, Mar 26, 2008 at 9:15 AM, mabshoff [EMAIL PROTECTED] wrote: [snip] Yeah, but that mean that any Sage release that is supposed to work will so far only work up to 10.5.1. I didn't know that the tiny version number of OSX can be unequal to zero. Yep, that's a serious problem. I have tried about 4 times to upgrade my laptop from 10.5.1 to 10.5.2, but failed every time. The last time, I just left it upgrading before I went to sleep, and 8 hours later it was still sitting there upgrading. Is it supposed to take that long? I'll try upgrading my desktop instead, so we have at least one 10.5.2 machine in the regular testing cycle. That's really strange. I've been through the 10.5.2 upgrade on two different systems, with no problems. Well, no problems that made the move from short- to medium-term memory :-}. You were just doing the normal software update, and the software uprade window was stuck? Or did it get beyond that to restart/install/ reboot stage? Justin -- Justin C. Walker, Curmudgeon-At-Large, Director Institute for the Enhancement of the Director's Income The path of least resistance: it's not just for electricity any more. --~--~-~--~~~---~--~~ 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: another matrix() corner case for sparse matrices
On Wed, Mar 26, 2008 at 11:01 AM, Jason Grout
[EMAIL PROTECTED] wrote:
Ryan Hinton brought up a good point at #2651:
Currently, matrix(3,{(1,1): 2}) gives the 3x2 sparse matrix
[0 0]
[0 2]
[0 0]
However, for other cases, if we specify just the number of rows, the
returned matrix is square (except when we are giving all the entries of
the matrix and there aren't enough entries). So:
Should the above command return the following instead?
[0 0 0]
[0 2 0]
[0 0 0]
Sorry for bringing up the nitpicky corner cases, but since matrix() is
used in a huge number of things, we don't want to mess something up when
we replace the constructor.
I very strongly agree that the output of matrix(3,{(1,1): 2}) should be the
sparse matrix:
[0 0 0]
[0 2 0]
[0 0 0]
BTW, there should be an example in the docstring for matrix that illustrates
how to make a dense matrix given a dictionary as input. E.g.,
sage: matrix(2,{(1,1):5},sparse=False).parent()
Full MatrixSpace of 2 by 2 dense matrices over Integer Ring
-- William
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Sage 2.11.alpha1 released!
On Wed, Mar 26, 2008 at 11:05 AM, Justin C. Walker [EMAIL PROTECTED] wrote: On Mar 26, 2008, at 10:37 , William Stein wrote: On Wed, Mar 26, 2008 at 9:15 AM, mabshoff [EMAIL PROTECTED] wrote: [snip] Yeah, but that mean that any Sage release that is supposed to work will so far only work up to 10.5.1. I didn't know that the tiny version number of OSX can be unequal to zero. Yep, that's a serious problem. I have tried about 4 times to upgrade my laptop from 10.5.1 to 10.5.2, but failed every time. The last time, I just left it upgrading before I went to sleep, and 8 hours later it was still sitting there upgrading. Is it supposed to take that long? I'll try upgrading my desktop instead, so we have at least one 10.5.2 machine in the regular testing cycle. That's really strange. I've been through the 10.5.2 upgrade on two different systems, with no problems. Well, no problems that made the move from short- to medium-term memory :-}. You were just doing the normal software update, and the software uprade window was stuck? Or did it get beyond that to restart/install/ reboot stage? Thanks for doing Apple tech support on sage-devel :-). Anyway, if this goes beyond 2 messages it should go offlist. I got the problem during the install stage of restart/install/reboot.The progress meter doesn't move after about 6 hours.Maybe it's a networking problem -- I'll try using a wired network and see if things work. Also, is there any way to get debugging info. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: another matrix() corner case for sparse matrices
On Wed, Mar 26, 2008 at 2:01 PM, Jason Grout
[EMAIL PROTECTED] wrote:
Ryan Hinton brought up a good point at #2651:
Currently, matrix(3,{(1,1): 2}) gives the 3x2 sparse matrix
[0 0]
[0 2]
[0 0]
However, for other cases, if we specify just the number of rows, the
returned matrix is square (except when we are giving all the entries of
the matrix and there aren't enough entries). So:
Should the above command return the following instead?
[0 0 0]
[0 2 0]
[0 0 0]
Yes, I think the matrix should be square way since that is the
behavior for dense matrices.
didier
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Get Paid to work on the Sage Notebook all Summer
Hi, If you are a student and would really like to get paid to work on the Sage Notebook all summer, go to this web page and fill out an application http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants Apply to the Python Software Foundation as mentoring organization. Also, email me. Your application must be submitted by this coming Monday (March 31). -- William -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Glib algorithms #2436 vote
On Wed, Mar 26, 2008 at 1:52 PM, mabshoff [EMAIL PROTECTED] wrote: On Mar 26, 6:43 pm, William Stein [EMAIL PROTECTED] wrote: On Wed, Mar 26, 2008 at 10:09 AM, mabshoff [EMAIL PROTECTED] wrote: On Mar 26, 6:02 pm, William Stein [EMAIL PROTECTED] wrote: Is any of the code gpl v3+ only? No. That's good. How difficult will it be to update our version whenever upstream changes? Do only you know how to do this? Not particularly hard. You didn't answer my second question. Gary did it and I didn't pay much attention to it. I assume it will be documented. I don't consider such a thing hard once it has been documented. Why put this in c_lib instead of a separate spkg called glib-min? Couldn't such a package be useful outside of sage? It is easiest if we put it into libcsage. That's not a good enough answer. Until now almost all code in libcsage and the main sage library has been new code we've written -- except a few exceptions, where we greatly regretted them greatly and moved the code out later. So from experience I'm very opposed to this code being in c_lib. I vote -1 to this code going into sage unless: (1) it is put in a separate spkg, and We can certainly do that. (2) the process of extracting glib-min from the official glib tarball is automated. That is unlikely to happen since it requires manual interaction. It will break in the next release in six months and writing automated tools will take longer than actually doing the work in the first place. How frequent are the glib releases? If they're not that frequent, this should less than an issue as long as Gary documents what he's done somewhere :) didier -- 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 Journal
On Mar 26, 6:33 pm, William Stein [EMAIL PROTECTED] wrote: On Wed, Mar 26, 2008 at 10:08 AM, Burcin Erocal [EMAIL PROTECTED] wrote: Is it possible to call it Sage Monthly or Quarterly, so that it is not confused with JSage? Yes, the name should either change as you suggest,... I've no problems about another name, this is one of my smallest concerns and i'm not a dictator ;) Sage News, Sage Newsletter, Sage Letters, Sage in the Print, Sage Reader, Sage eLetters, Sage eNews, ... there are countless possibilities. Merging yes, a week ago when i first mentioned it on irc, i wasn't aware of JSage. But I'm not the one who decides about its future. possible as a subset of that journal idea? sure. harald --~--~-~--~~~---~--~~ 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: Glib algorithms #2436 vote
On Wed, Mar 26, 2008 at 11:16 AM, didier deshommes [EMAIL PROTECTED] wrote: On Wed, Mar 26, 2008 at 1:52 PM, mabshoff [EMAIL PROTECTED] wrote: On Mar 26, 6:43 pm, William Stein [EMAIL PROTECTED] wrote: On Wed, Mar 26, 2008 at 10:09 AM, mabshoff [EMAIL PROTECTED] wrote: On Mar 26, 6:02 pm, William Stein [EMAIL PROTECTED] wrote: Is any of the code gpl v3+ only? No. That's good. How difficult will it be to update our version whenever upstream changes? Do only you know how to do this? Not particularly hard. You didn't answer my second question. Gary did it and I didn't pay much attention to it. I assume it will be documented. I don't consider such a thing hard once it has been documented. Why put this in c_lib instead of a separate spkg called glib-min? Couldn't such a package be useful outside of sage? It is easiest if we put it into libcsage. That's not a good enough answer. Until now almost all code in libcsage and the main sage library has been new code we've written -- except a few exceptions, where we greatly regretted them greatly and moved the code out later. So from experience I'm very opposed to this code being in c_lib. I vote -1 to this code going into sage unless: (1) it is put in a separate spkg, and We can certainly do that. (2) the process of extracting glib-min from the official glib tarball is automated. That is unlikely to happen since it requires manual interaction. It will break in the next release in six months and writing automated tools will take longer than actually doing the work in the first place. How frequent are the glib releases? If they're not that frequent, this should less than an issue as long as Gary documents what he's done somewhere :) If you've been maintaining packages for Sage for three years, and expect to be maintaining them for years to come, you'de view this as a much bigger deal. It's really bad when there is a big chunk of code in Sage that gets out of stream with up stream, but no easy way to resolve that problem. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [sage-support] Re: modular forms bug(s)?
Hey all, (I'm cc'ing this to sage-devel, because I think there are people there who care about modular forms who might not read sage-support.) So I've also posted a patch on #2674, which actually fixes both of these issues, as well as the fact that it currently is the case that adding an element of CuspForms(22) to an element of ModularForms(22) breaks. Now, I agree with William's point here: Note that b[0] + 0 and 0 + b[0] should *not* work, since in each case that's a canonical coercion, and there is no natural map from ZZ (the parent of 0) into CuspForms(...) for any weight except 0. In Sage coercions should not happen automatically unless they are in some way natural and well defined on the whole domain of the coercion (in this case ZZ). However, the modular forms code isn't the culprit -- it just tries to coerce in by calling the coercion code for the underlying free module. Here's why this actually works: sage: M = ZZ**3 sage: M(0) (0, 0, 0) sage: M(1) # goes boom There are some canonical coercions that one *should* have in the context of modular forms that aren't there, probably partly because this whole canonical coercions business was after I wrote the modular forms code. Here's an example bug (=lack of a coercion that should be there): sage: b=CuspForms(22).basis() sage: sum(b, b[0].parent()(0)) This now works fine with the patch I posted to #2674. Currently, there are no coercions between different levels; which such coercions would people like to see? Coercing from Gamma0(M) to Gamma0(Md) seems plausible, though one argue that it's a choice of one specific degeneracy map. That is, it seems standard but not canonical. I think it's the same as asking for a natural map from ZZ['x'] to ZZ['y']. Of course, this works in Sage, so maybe the above map should, too. Maybe also maps from Gamma0 to Gamma1 and GammaH? And GammaH to Gamma1? Which maps seem reasonable to people? Jay, are there any of these that you would expect to work that don't? -cc --~--~-~--~~~---~--~~ 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] mercurial -- plain text -- mercurial
Hi Jason (or anybody), Does anybody have a clue if it is possible to take a directory (e.g., devel/sage/) with an .hg repo directory in it, and do the following: (1) export everything in the .hg repo to something (perhaps a ton of stuff) in plain text format, (2) delete .hg (3) do something that recovers the .hg directory from the output of (1). Note that just doing hg_sage.export([0..1]), where say 1 is the tip, doesn't work, because that looses all information about branching, etc., hence fails completely. If mercurial can't do the above, that is a _very_ serious problem for the longterm viability of Mercurial at least for Sage. So any ideas how to do the above? The reason for doing (1) -- (3) is that it is possible to scan an .hg directory with antivirus tools. Thus something silly like base64-encode a tarball of .hg won't work. -- william -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Glib algorithms #2436 vote
Honestly, independent of the spkg vs libcsage issue, which is really an issue of semantics in my opinion, Sage has no high speed implementations of C algorithms. Sage can not escape this forever. Either someone will have to write their own at some point or we can use glib as a starting block. It is a big chunk of code, but Sage needs fast lists, hash tables, etc. Using glib as a starting point dramatically reduces debugging time, and is therefore preferable. I don't see how blocking a glib patch because of maintenance issues really helps solve this problem in the long run. Is it really preferable that I code up custom versions of the things so that I can have fast symbolic implementations? Most of the bloat in glib is internationaliztaion, which is not included in this patch. The parts that are included are simple enough and well documented enough (either in the code or in glib documents) that anyone should be able to easily maintain it. Furthermore, I intend to help maintain the C algorithms. I fully intend to work on them actively if their speed is not sufficient. Making a seperate spkg dramatically increases the difficulty of active development. On Wed, Mar 26, 2008 at 12:26 PM, William Stein [EMAIL PROTECTED] wrote: On Wed, Mar 26, 2008 at 11:16 AM, didier deshommes [EMAIL PROTECTED] wrote: On Wed, Mar 26, 2008 at 1:52 PM, mabshoff [EMAIL PROTECTED] wrote: On Mar 26, 6:43 pm, William Stein [EMAIL PROTECTED] wrote: On Wed, Mar 26, 2008 at 10:09 AM, mabshoff [EMAIL PROTECTED] wrote: On Mar 26, 6:02 pm, William Stein [EMAIL PROTECTED] wrote: Is any of the code gpl v3+ only? No. That's good. How difficult will it be to update our version whenever upstream changes? Do only you know how to do this? Not particularly hard. You didn't answer my second question. Gary did it and I didn't pay much attention to it. I assume it will be documented. I don't consider such a thing hard once it has been documented. Why put this in c_lib instead of a separate spkg called glib-min? Couldn't such a package be useful outside of sage? It is easiest if we put it into libcsage. That's not a good enough answer. Until now almost all code in libcsage and the main sage library has been new code we've written -- except a few exceptions, where we greatly regretted them greatly and moved the code out later. So from experience I'm very opposed to this code being in c_lib. I vote -1 to this code going into sage unless: (1) it is put in a separate spkg, and We can certainly do that. (2) the process of extracting glib-min from the official glib tarball is automated. That is unlikely to happen since it requires manual interaction. It will break in the next release in six months and writing automated tools will take longer than actually doing the work in the first place. How frequent are the glib releases? If they're not that frequent, this should less than an issue as long as Gary documents what he's done somewhere :) If you've been maintaining packages for Sage for three years, and expect to be maintaining them for years to come, you'de view this as a much bigger deal. It's really bad when there is a big chunk of code in Sage that gets out of stream with up stream, but no easy way to resolve that problem. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: hg churn and contributions
On Wed, Mar 26, 2008 at 10:55 AM, Jason Grout [EMAIL PROTECTED] wrote: Mercurial 1.0 is out now and one of the new standard extensions is the churn command, which apparently gives the numbers of lines of changed code per person (well, per email address). I thought the output (see below) was interesting. This is as of 2.10.4 and a few extra patches on top of it. Wow, that's pretty cool. We need to get Mercurial 1.0 into Sage asap. :-) We all still have a *long* way to go to catch up to William. He is quite literally off the charts (his bar wraps to the next line in my email program). Well I don't have a long way to go to catch up to William :-). By the way, the Tornaria line below is almost all me as well -- that was from when he checked all my code into his darcs repository under his name... Good job everyone! Indeed! P.S. Another really cool feature in 1.0 is the qrecord command, which brings the darcs-style interactive commits to mercurial queues (so you can include just part of the changes in a file in a patch). Jason [EMAIL PROTECTED] 424564 ** [EMAIL PROTECTED] 138071 ** [EMAIL PROTECTED] 111518 [EMAIL PROTECTED] 85543 * [EMAIL PROTECTED] 76713 [EMAIL PROTECTED] 74154 [EMAIL PROTECTED]69768 *** [EMAIL PROTECTED]64563 ** [EMAIL PROTECTED] 61706 ** [EMAIL PROTECTED] 36213 *** [EMAIL PROTECTED]32169 *** [EMAIL PROTECTED] 30247 *** [EMAIL PROTECTED] 28010 *** [EMAIL PROTECTED] 21594 ** [EMAIL PROTECTED] 20447 ** [EMAIL PROTECTED] 17300 * [EMAIL PROTECTED]15626 * [EMAIL PROTECTED] 15338 * [EMAIL PROTECTED] 14718 * [EMAIL PROTECTED]9135 [EMAIL PROTECTED] 8580 Emily Kirkman 8475 [EMAIL PROTECTED] 8164 [EMAIL PROTECTED] 7378 [EMAIL PROTECTED]6936 [EMAIL PROTECTED] 5712 [EMAIL PROTECTED] 5045 [EMAIL PROTECTED] 4175 [EMAIL PROTECTED] 3475 [EMAIL PROTECTED]3286 [EMAIL PROTECTED] 3098 [EMAIL PROTECTED]2870 [EMAIL PROTECTED] 2619 [EMAIL PROTECTED] 2445 [EMAIL PROTECTED] 2372 [EMAIL PROTECTED] 2330 [EMAIL PROTECTED]2279 [EMAIL PROTECTED]2167 [EMAIL PROTECTED] 1982 [EMAIL PROTECTED] 1527 [EMAIL PROTECTED]1366 [EMAIL PROTECTED] 1333 [EMAIL PROTECTED] 1316 [EMAIL PROTECTED] 1282 [EMAIL PROTECTED] 1172 [EMAIL PROTECTED]1099 [EMAIL PROTECTED] 1090 [EMAIL PROTECTED] 1058 [EMAIL PROTECTED] 1043 [EMAIL PROTECTED] 1012 [EMAIL PROTECTED] 955 cremona 830 [EMAIL PROTECTED] 543 [EMAIL PROTECTED]513 [EMAIL PROTECTED] 513 [EMAIL PROTECTED] 503 [EMAIL PROTECTED]496 [EMAIL PROTECTED] 396 [EMAIL PROTECTED] 365 [EMAIL PROTECTED]332 Jason Grout 319 [EMAIL PROTECTED] 308 [EMAIL PROTECTED] 277 [EMAIL PROTECTED] 272 [EMAIL PROTECTED]244 [EMAIL PROTECTED]236 [EMAIL PROTECTED] 227 [EMAIL PROTECTED] 211 [EMAIL PROTECTED]
[sage-devel] Re: hg churn and contributions
On Wednesday 26 March 2008 13:55, Jason Grout wrote: Mercurial 1.0 is out now and one of the new standard extensions is the churn command, which apparently gives the numbers of lines of changed code per person (well, per email address). I thought the output (see below) was interesting. This is as of 2.10.4 and a few extra patches on top of it. The list below is certainly very cool and amusing to read, but I became quite suspicious of it's meaning when I saw me ([EMAIL PROTECTED]) that high on the list. I don't think that's a very accurate representation of me ... I think I should be much lower. I am kind of curious how I managed to score that many lines of code. -- Joel [EMAIL PROTECTED] 424564 ** [EMAIL PROTECTED] 138071 ** [EMAIL PROTECTED] 111518 [EMAIL PROTECTED] 85543 * [EMAIL PROTECTED] 76713 [EMAIL PROTECTED] 74154 [EMAIL PROTECTED]69768 *** [EMAIL PROTECTED]64563 ** [EMAIL PROTECTED] 61706 ** [EMAIL PROTECTED] 36213 *** [EMAIL PROTECTED]32169 *** [EMAIL PROTECTED] 30247 *** [EMAIL PROTECTED] 28010 *** [EMAIL PROTECTED] 21594 ** [EMAIL PROTECTED] 20447 ** [EMAIL PROTECTED] 17300 * [EMAIL PROTECTED]15626 * [EMAIL PROTECTED] 15338 * [EMAIL PROTECTED] 14718 * [EMAIL PROTECTED]9135 [EMAIL PROTECTED] 8580 Emily Kirkman 8475 [EMAIL PROTECTED] 8164 [EMAIL PROTECTED] 7378 [EMAIL PROTECTED]6936 [EMAIL PROTECTED] 5712 [EMAIL PROTECTED] 5045 [EMAIL PROTECTED] 4175 [EMAIL PROTECTED] 3475 [EMAIL PROTECTED]3286 [EMAIL PROTECTED] 3098 [EMAIL PROTECTED]2870 [EMAIL PROTECTED] 2619 [EMAIL PROTECTED] 2445 [EMAIL PROTECTED] 2372 [EMAIL PROTECTED] 2330 [EMAIL PROTECTED]2279 [EMAIL PROTECTED]2167 [EMAIL PROTECTED] 1982 [EMAIL PROTECTED] 1527 [EMAIL PROTECTED]1366 [EMAIL PROTECTED] 1333 [EMAIL PROTECTED] 1316 [EMAIL PROTECTED] 1282 [EMAIL PROTECTED] 1172 [EMAIL PROTECTED]1099 [EMAIL PROTECTED] 1090 [EMAIL PROTECTED] 1058 [EMAIL PROTECTED] 1043 [EMAIL PROTECTED] 1012 [EMAIL PROTECTED] 955 cremona 830 [EMAIL PROTECTED] 543 [EMAIL PROTECTED]513 [EMAIL PROTECTED] 513 [EMAIL PROTECTED] 503 [EMAIL PROTECTED]496 [EMAIL PROTECTED] 396 [EMAIL PROTECTED] 365 [EMAIL PROTECTED]332 Jason Grout 319 [EMAIL PROTECTED] 308 [EMAIL PROTECTED] 277 [EMAIL PROTECTED] 272 [EMAIL PROTECTED]244 [EMAIL PROTECTED]236 [EMAIL PROTECTED] 227 [EMAIL PROTECTED] 211 [EMAIL PROTECTED] 210 [EMAIL PROTECTED] 199 [EMAIL PROTECTED] 189 [EMAIL PROTECTED] 180 [EMAIL PROTECTED] 177 [EMAIL PROTECTED] 174 bill,[EMAIL PROTECTED] 173 [EMAIL PROTECTED]169 [EMAIL PROTECTED]166
[sage-devel] Re: mercurial -- plain text -- mercurial
On Mar 26, 7:53 pm, William Stein [EMAIL PROTECTED] wrote: Hi Jason (or anybody), Does anybody have a clue if it is possible to take a directory (e.g., devel/sage/) with an .hg repo directory in it, and do the following: (1) export everything in the .hg repo to something (perhaps a ton of stuff) in plain text format, (2) delete .hg (3) do something that recovers the .hg directory from the output of (1). There is nothing that does that currently that I am awake of. I did play around with this and wrote some dummy scripts that a) export every commit from a tree b) create an empty hg repo c) reimport each exported changeset The md5sum of the files inside the .hg repo is different afterwards, but parents and changesets and all that fun stuff remains the same. Note that just doing hg_sage.export([0..1]), where say 1 is the tip, doesn't work, because that looses all information about branching, etc., hence fails completely. I need to see what happens with branches, but I am not sure what happens in case of multi head merges. If mercurial can't do the above, that is a _very_ serious problem for the longterm viability of Mercurial at least for Sage. So any ideas how to do the above? The reason for doing (1) -- (3) is that it is possible to scan an .hg directory with antivirus tools. Thus something silly like base64-encode a tarball of .hg won't work. -- william Cheers, Michael -- William Stein Associate Professor of Mathematics University of Washingtonhttp://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: mercurial -- plain text -- mercurial
William, git can do this. Since git uses a hash it will always regenerate the same hash from the same file. In fact, git uses hashes all the way down the tree so you can just look at the hash code of the root of the tree to see if anything changes. Equal hash codes, even across the net, imply exact copies of the source tree. Axiom uses arch, cvs, svn, and git. I have used several other systems in the past. Now all of the primary work is in git and is export-only to the other systems (git can work with them transparently). git has fundamentally changed the way I work and the way Axiom is maintained, all for the better. I know it is a challenge to change source code systems but the gain is well worth the pain in this case. The fact that git works with legacy humans is a huge plus in minimizing the pain. Tim Daly Axiom --~--~-~--~~~---~--~~ 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 Journal
On Mar 26, 10:33 am, William Stein [EMAIL PROTECTED] wrote: On Wed, 26 Mar 2008 09:32:36 -0700 (PDT) Harald Schilly [EMAIL PROTECTED] wrote: I had the idea of publishing an online Journal with articles about Sage - a mixture between blogs and a real journal. This could be an excellent vehicle to promote Sage and the ideas behind to a bigger audience. Yes, the name should either change as you suggest, or this should somehow merge with JSage, and JSage itself would become less academic. (Note that JSage hasn't really started yet, in any real sense.)Maybe something like Harald is proposing is a better direction to go in that the current JSage direction (which is to be purely very academic and research-oriented). William Perhaps this would also be a good way of getting the original JSage intentions rolling. Quite a few people have recently been doing the kind of work that would make ideal articles for that. If JSage were a real thing you might start seeing submissions in the research-oriented sector, anyway. I also like the idea of the journal as a recruiting possibility. Having articles about Sage internals is probably the right way to attract the kind of developers we are looking for. As for politics/philosophy/community/..., this might be best left in letters to the editor, for the journal's sake. --~--~-~--~~~---~--~~ 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: mercurial -- plain text -- mercurial
On Wed, Mar 26, 2008 at 1:18 PM, root [EMAIL PROTECTED] wrote: William, git can do this. Since git uses a hash it will always regenerate the same hash from the same file. In fact, git uses hashes all the way down the tree so you can just look at the hash code of the root of the tree to see if anything changes. Equal hash codes, even across the net, imply exact copies of the source tree. Axiom uses arch, cvs, svn, and git. I have used several other systems in the past. Now all of the primary work is in git and is export-only to the other systems (git can work with them transparently). git has fundamentally changed the way I work and the way Axiom is maintained, all for the better. I know it is a challenge to change source code systems but the gain is well worth the pain in this case. The fact that git works with legacy humans is a huge plus in minimizing the pain. We are indeed considering changing to git. The repo -- plain text -- original repo problem is a show stopper -- i.e., if Mercurial absolutely can't do that, then we have no choice but to dump mercurial for git. I hope Mercurial can do that though, since we've spent a lot of time getting going with Mercurial, and it works fairly well. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: hg churn and contributions
On Wed, Mar 26, 2008 at 12:02 PM, Joel B. Mohler [EMAIL PROTECTED] wrote: On Wednesday 26 March 2008 13:55, Jason Grout wrote: Mercurial 1.0 is out now and one of the new standard extensions is the churn command, which apparently gives the numbers of lines of changed code per person (well, per email address). I thought the output (see below) was interesting. This is as of 2.10.4 and a few extra patches on top of it. The list below is certainly very cool and amusing to read, but I became quite suspicious of it's meaning when I saw me ([EMAIL PROTECTED]) that high on the list. I don't think that's a very accurate representation of me ... I think I should be much lower. I am kind of curious how I managed to score that many lines of code. I think refactoring code also counts -- it's just lines you've changed. Notice that the sum of the lines in the list is much bigger than the total lines in Sage itself. So if you renamed a file, you get a bunch of points in that list. It would be interesting to see how many new lines (initial commits from nothing) that people have contributed. I don't know if this is possible with churn. William -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: hg churn and contributions
Did we check in a big chunk of the ntl wrapper under your name? (That one would be fair, of course). Or maybe when we moved libcsage into the sage tree, that went in under your name? -cc On Wed, Mar 26, 2008 at 12:02 PM, Joel B. Mohler [EMAIL PROTECTED] wrote: On Wednesday 26 March 2008 13:55, Jason Grout wrote: Mercurial 1.0 is out now and one of the new standard extensions is the churn command, which apparently gives the numbers of lines of changed code per person (well, per email address). I thought the output (see below) was interesting. This is as of 2.10.4 and a few extra patches on top of it. The list below is certainly very cool and amusing to read, but I became quite suspicious of it's meaning when I saw me ([EMAIL PROTECTED]) that high on the list. I don't think that's a very accurate representation of me ... I think I should be much lower. I am kind of curious how I managed to score that many lines of code. -- Joel [EMAIL PROTECTED] 424564 ** [EMAIL PROTECTED] 138071 ** [EMAIL PROTECTED] 111518 [EMAIL PROTECTED] 85543 * [EMAIL PROTECTED] 76713 [EMAIL PROTECTED] 74154 [EMAIL PROTECTED]69768 *** [EMAIL PROTECTED]64563 ** [EMAIL PROTECTED] 61706 ** [EMAIL PROTECTED] 36213 *** [EMAIL PROTECTED]32169 *** [EMAIL PROTECTED] 30247 *** [EMAIL PROTECTED] 28010 *** [EMAIL PROTECTED] 21594 ** [EMAIL PROTECTED] 20447 ** [EMAIL PROTECTED] 17300 * [EMAIL PROTECTED]15626 * [EMAIL PROTECTED] 15338 * [EMAIL PROTECTED] 14718 * [EMAIL PROTECTED]9135 [EMAIL PROTECTED] 8580 Emily Kirkman 8475 [EMAIL PROTECTED] 8164 [EMAIL PROTECTED] 7378 [EMAIL PROTECTED]6936 [EMAIL PROTECTED] 5712 [EMAIL PROTECTED] 5045 [EMAIL PROTECTED] 4175 [EMAIL PROTECTED] 3475 [EMAIL PROTECTED]3286 [EMAIL PROTECTED] 3098 [EMAIL PROTECTED]2870 [EMAIL PROTECTED] 2619 [EMAIL PROTECTED] 2445 [EMAIL PROTECTED] 2372 [EMAIL PROTECTED] 2330 [EMAIL PROTECTED]2279 [EMAIL PROTECTED]2167 [EMAIL PROTECTED] 1982 [EMAIL PROTECTED] 1527 [EMAIL PROTECTED]1366 [EMAIL PROTECTED] 1333 [EMAIL PROTECTED] 1316 [EMAIL PROTECTED] 1282 [EMAIL PROTECTED] 1172 [EMAIL PROTECTED]1099 [EMAIL PROTECTED] 1090 [EMAIL PROTECTED] 1058 [EMAIL PROTECTED] 1043 [EMAIL PROTECTED] 1012 [EMAIL PROTECTED] 955 cremona 830 [EMAIL PROTECTED] 543 [EMAIL PROTECTED]513 [EMAIL PROTECTED] 513 [EMAIL PROTECTED] 503 [EMAIL PROTECTED]496 [EMAIL PROTECTED] 396 [EMAIL PROTECTED] 365 [EMAIL PROTECTED]332 Jason Grout 319 [EMAIL PROTECTED] 308 [EMAIL PROTECTED] 277 [EMAIL PROTECTED] 272 [EMAIL PROTECTED]244 [EMAIL PROTECTED]236 [EMAIL PROTECTED] 227 [EMAIL PROTECTED] 211 [EMAIL PROTECTED]
[sage-devel] Re: mercurial -- plain text -- mercurial
It seems like the mercurial mailing list would be the best place to go for this. Using queues has made me quite a bit more productive, and I'd like to avoid switching to a version control system without them. Also, the git documentation leaves something to be desired compared to the Mercurial book. --Mike On Wed, Mar 26, 2008 at 12:12 PM, William Stein [EMAIL PROTECTED] wrote: On Wed, Mar 26, 2008 at 1:18 PM, root [EMAIL PROTECTED] wrote: William, git can do this. Since git uses a hash it will always regenerate the same hash from the same file. In fact, git uses hashes all the way down the tree so you can just look at the hash code of the root of the tree to see if anything changes. Equal hash codes, even across the net, imply exact copies of the source tree. Axiom uses arch, cvs, svn, and git. I have used several other systems in the past. Now all of the primary work is in git and is export-only to the other systems (git can work with them transparently). git has fundamentally changed the way I work and the way Axiom is maintained, all for the better. I know it is a challenge to change source code systems but the gain is well worth the pain in this case. The fact that git works with legacy humans is a huge plus in minimizing the pain. We are indeed considering changing to git. The repo -- plain text -- original repo problem is a show stopper -- i.e., if Mercurial absolutely can't do that, then we have no choice but to dump mercurial for git. I hope Mercurial can do that though, since we've spent a lot of time getting going with Mercurial, and it works fairly well. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: mercurial -- plain text -- mercurial
On Mar 26, 8:12 pm, William Stein [EMAIL PROTECTED] wrote: On Wed, Mar 26, 2008 at 1:18 PM, root [EMAIL PROTECTED] wrote: William, git can do this. Since git uses a hash it will always regenerate the same hash from the same file. In fact, git uses hashes all the way down the tree so you can just look at the hash code of the root of the tree to see if anything changes. Equal hash codes, even across the net, imply exact copies of the source tree. Axiom uses arch, cvs, svn, and git. I have used several other systems in the past. Now all of the primary work is in git and is export-only to the other systems (git can work with them transparently). git has fundamentally changed the way I work and the way Axiom is maintained, all for the better. I know it is a challenge to change source code systems but the gain is well worth the pain in this case. The fact that git works with legacy humans is a huge plus in minimizing the pain. We are indeed considering changing to git. The repo -- plain text -- original repo problem is a show stopper -- i.e., if Mercurial absolutely can't do that, then we have no choice but to dump mercurial for git. I hope Mercurial can do that though, since we've spent a lot of time getting going with Mercurial, and it works fairly well. I did play around with a small repo that included a bundle that I did merge without conflict and in that case reimporting the commits one by one yields the same md5sums for all the files in the repo. When I imported a merge changeset I got the following: [EMAIL PROTECTED] c]$ hg import ../b/5.patch applying ../b/5.patch abort: 00changelog.i: no node 1711dd4455804471c46598ec4f92f672de73916e! But it didn't make a difference, expect that in the end the repo had one fewer commit. I am still curious what happens if you resolve a merge conflict in that changeset. I am not too positive about the outcome since hg help export states: NOTE: export may generate unexpected diff output for merge changesets, as it will compare the merge changeset against its first parent only. I guess I need to take on the Sage repo and see what happens when I do the same thing with 9,000+ commits. -- 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: mercurial -- plain text -- mercurial
Mike, Using queues has made me quite a bit more productive, and I'd like to avoid switching to a version control system without them. Also, the git documentation leaves something to be desired compared to the Mercurial book. The queues feature in Mercurial is available independently in the quilt system. Mercurial makes this point: http://hgbook.red-bean.com/hgbookch12.html Tim Daly Axiom --~--~-~--~~~---~--~~ 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: Fast matrices over GF(p)
Dear all, i made a new version of my wrapper that is based on the most recent MeatAxe. You can find it at http://sage.math.washington.edu/home/SimonKing/MeatAxe.tar.gz The tar'd folder contains: - a part of the unaltered source files of MeatAxe 2.4, - additional (very simplistic) C-code in MoreFeatures.c and .h, - my wrapper comprising mtx.pxd and mtx.pyx, - a Makefile, - and some files such as p005.zzz that you can ignore. On Sage.Math, you simply say make to build mtx.so, which can be loaded into Sage. On a different machine, you probably have to alter the hard-coded path to sage-python in the Makefile. Concerning p005.zzz and p007.zzz: Files like this will be written to your current directory when you handle MTX over Z/5 or Z/7. I don't like it, but that is how MeatAxe works. I made some timings on Sage.Math, that you find in http://sage.math.washington.edu/home/SimonKing/MTXtiming.txt This also provides some examples how MTX matrices work. On Mar 25, 5:02 pm, Simon King [EMAIL PROTECTED] wrote: On Mar 25, 6:31 am, Clement Pernet [EMAIL PROTECTED] wrote: I still did not look at the code of Meat axe, but I remember having been really impressed a presentation at MSRI last year about MeatAxe. The timings were really impressive especially the matmul ones. So I am really surprised by your experience with slow matmul. Were these timings about matmul? Then it is really surprising. According to my timings, in fact matrix multiplication is slow: It was 453 ms with Sage matrices but 937 ms with MTX. Since MeatAxe's MatMul alters the first input matrix, i need one additional copy operation. But the copy works very fast, less than 1 ms. So, that can't be the reason. Surprisingly, MTX.nullspace(), which essentially yields what .kernel().basis() does for Sage matrices, is fast: 46.57 s with Sage matrices, but 4.74 s for the corresponding MTX matrix. I understood that Sage caches part of the result - MTX does not, yet. But i don't need these executables, my wrapper does all these things in memory. Only exception: I need the executable maketab... No, i don't. mtx.so suffices, no additional executable besides sage is needed. My opinion is: Personally, I have reasons to use MTX in my project. But the little progress (if there is any) would probably not justify to include yet another matrix type into Sage. Yours Simon --~--~-~--~~~---~--~~ 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: mercurial -- plain text -- mercurial
The queues feature in Mercurial is available independently in the quilt system. Mercurial makes this point: http://hgbook.red-bean.com/hgbookch12.html There are things with queues that you don't get with quilt. Quoting from the book, As an example, the integration of patches with revision control makes understanding patches and debugging their effects—and their interplay with the code they're based on—enormously easier. Since every applied patch has an associated changeset, you can use hg log filename to see which changesets and patches affected a file. You can use the bisect extension to binary-search through all changesets and applied patches to see where a bug got introduced or fixed. You can use the hg annotate command to see which changeset or patch modified a particular line of a source file. And so on. --Mike --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: hg churn and contributions
On Wednesday 26 March 2008 15:16, Craig Citro wrote: Did we check in a big chunk of the ntl wrapper under your name? (That one would be fair, of course). Or maybe when we moved libcsage into the sage tree, that went in under your name? I suspect that both of these things are a big contributor (the ntl_wrap.cc file was quite long). I guess the real point is that as with all lines-of-code-counting metrics this one needs to be viewed with a bit of suspicion. Anyhow, it really doesn't matter one way or the other. Here's a relevant wise quote from Edsgar Dijkstra: http://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html *** ... From there it is only a small step to measuring programmer productivity in terms of number of lines of code produced per month. This is a very costly measuring unit because it encourages the writing of insipid code, but today I am less interested in how foolish a unit it is from even a pure business point of view. My point today is that, if we wish to count lines of code, we should not regard them as lines produced but as lines spent: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger. *** -- Joel --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: mercurial -- plain text -- mercurial
The queues feature in Mercurial is available independently in the quilt system. Mercurial makes this point: http://hgbook.red-bean.com/hgbookch12.html There are things with queues that you don't get with quilt. Quoting from the book, As an example, the integration of patches with revision control makes understanding patches and debugging their effects--and their interplay with the code they're based on--enormously easier. Since every applied patch has an associated changeset, you can use hg log filename to see which changesets and patches affected a file. You can use the bisect extension to binary-search through all changesets and applied patches to see where a bug got introduced or fixed. You can use the hg annotate command to see which changeset or patch modified a particular line of a source file. And so on. Sorry, I didn't mean to start a debate about the relative feature set of the various systems. The git system can do what you want (e.g. bisect, branch, etc.). Having gone thru the series of changes cvs-arch-svn-git I understand why you would be reluctant to change. The original point was the question of regenerating the information. Since git uses hashing to guarantee uniqueness you know that any root (or subtree) with equal hashs has the same code. This makes it impossible to inject a virus. It also makes it very convenient to recreate the exact sources used by a user reporting a bug since you simply undo the changes until the root is equal and you have the exact sources reporting the bug. Given the high change rate of Sage this could be a major feature. Another point worth mentioning is that git only stores one copy of a file if they hash to the same value. Since the GMP library, BLAS, LAPACK or other common libraries might show up in several spkgs there is the potential for a significant reduction in storage space. I also noticed that arch and svn seem to keep a second copy of the system somewhere (not sure what hg does) but moving to git immediately reduced the required disk space by a factor of 2. For a system as large as Sage this might prove interesting. If I get the time I can try to import Sage into git to quantify the gain. Tim Daly Axiom --~--~-~--~~~---~--~~ 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: mercurial -- plain text -- mercurial
On Mar 26, 11:53 am, William Stein [EMAIL PROTECTED] wrote: Hi Jason (or anybody), Does anybody have a clue if it is possible to take a directory (e.g., devel/sage/) with an .hg repo directory in it, and do the following: (1) export everything in the .hg repo to something (perhaps a ton of stuff) in plain text format, (2) delete .hg (3) do something that recovers the .hg directory from the output of (1). Note that just doing hg_sage.export([0..1]), where say 1 is the tip, doesn't work, because that looses all information about branching, etc., hence fails completely. If mercurial can't do the above, that is a _very_ serious problem for the longterm viability of Mercurial at least for Sage. So any ideas how to do the above? The reason for doing (1) -- (3) is that it is possible to scan an .hg directory with antivirus tools. Thus something silly like base64-encode a tarball of .hg won't work. I still don't understand the requirements. First, that last paragraph makes a lot more sense with it is impossible than it is possible. Did you mean impossible? Second, are you worried about people checking in viruses, or people concealing a virus in the .hg directory without it being checked in? For the former concern, it seems that it would be sufficient to check out the files, and you don't need to recreate the repository. For the latter concern, perhaps something based on hg verify would suffice to ensure that nothing nasty has been hidden in the repository. Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: mercurial -- plain text -- mercurial
On Mar 26, 9:27 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: On Mar 26, 2008, at 11:53 AM, William Stein wrote: Hi Jason (or anybody), Does anybody have a clue if it is possible to take a directory (e.g., devel/sage/) with an .hg repo directory in it, and do the following: (1) export everything in the .hg repo to something (perhaps a ton of stuff) in plain text format, (2) delete .hg (3) do something that recovers the .hg directory from the output of (1). Note that just doing hg_sage.export([0..1]), where say 1 is the tip, doesn't work, because that looses all information about branching, etc., hence fails completely. If mercurial can't do the above, that is a _very_ serious problem for the longterm viability of Mercurial at least for Sage. So any ideas how to do the above? The reason for doing (1) -- (3) is that it is possible to scan an .hg directory with antivirus tools. Thus something silly like base64-encode a tarball of .hg won't work. I think it should be possible to export a series of patches and a (python) script that would apply the patches in the right order, clone, and merge to get back the original repository. It might not be the most efficient however. I'll look into this more. Has anyone tried contacting the mercurial developers? Nope, that doesn't work on the Sage repo. Exporting all 9028 changesets of 2.11.alpha1 took about 40 minutes, but on reimport to a fresh repo failed around 1300 changesets. The problem is that export of a merge on diffs against on parent. So if you resolve a merge conflict in a merge changeset things go FUBAR. That was with 0.9.5, but I haven't tried 1.0 yet. - 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: mercurial -- plain text -- mercurial
On Mar 26, 2008, at 1:30 PM, mabshoff wrote: On Mar 26, 9:27 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: On Mar 26, 2008, at 11:53 AM, William Stein wrote: Hi Jason (or anybody), Does anybody have a clue if it is possible to take a directory (e.g., devel/sage/) with an .hg repo directory in it, and do the following: (1) export everything in the .hg repo to something (perhaps a ton of stuff) in plain text format, (2) delete .hg (3) do something that recovers the .hg directory from the output of (1). Note that just doing hg_sage.export([0..1]), where say 1 is the tip, doesn't work, because that looses all information about branching, etc., hence fails completely. If mercurial can't do the above, that is a _very_ serious problem for the longterm viability of Mercurial at least for Sage. So any ideas how to do the above? The reason for doing (1) -- (3) is that it is possible to scan an .hg directory with antivirus tools. Thus something silly like base64-encode a tarball of .hg won't work. I think it should be possible to export a series of patches and a (python) script that would apply the patches in the right order, clone, and merge to get back the original repository. It might not be the most efficient however. I'll look into this more. Has anyone tried contacting the mercurial developers? Nope, that doesn't work on the Sage repo. Exporting all 9028 changesets of 2.11.alpha1 took about 40 minutes, but on reimport to a fresh repo failed around 1300 changesets. The problem is that export of a merge on diffs against on parent. So if you resolve a merge conflict in a merge changeset things go FUBAR. That was with 0.9.5, but I haven't tried 1.0 yet. I was talking about something more sophisticated than export/import, which won't work the instant one has multiple branches. One needs to actually create multiple heads, apply patches, then resolve them. Hg export doesn't have enough information to do this. - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: mercurial -- plain text -- mercurial
On Mar 26, 9:35 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: I was talking about something more sophisticated than export/import, which won't work the instant one has multiple branches. One needs to actually create multiple heads, apply patches, then resolve them. Hg export doesn't have enough information to do this. Ok, sounds good. Do you have any pointers or documentation on this? - 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: mercurial -- plain text -- mercurial
On Mar 26, 2008, at 1:56 PM, mabshoff wrote: On Mar 26, 9:35 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: I was talking about something more sophisticated than export/import, which won't work the instant one has multiple branches. One needs to actually create multiple heads, apply patches, then resolve them. Hg export doesn't have enough information to do this. Ok, sounds good. Do you have any pointers or documentation on this? Not at the moment, but I've mucked around with mercurial more than most so I don't think it should be too hard once I start looking into it. - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Glib algorithms #2436 vote
On Mar 26, 2008, at 11:57 AM, Gary Furnish wrote: Honestly, independent of the spkg vs libcsage issue, which is really an issue of semantics in my opinion, Sage has no high speed implementations of C algorithms. Sage can not escape this forever. Either someone will have to write their own at some point or we can use glib as a starting block. It is a big chunk of code, but Sage needs fast lists, hash tables, etc. Using glib as a starting point dramatically reduces debugging time, and is therefore preferable. Browsing the glib documentation, looking at its features, and reading what other people have to say about it I think this is a worthy set of things to include. One question I have is how much faster glib hashtables are than python dictionaries (as accessed directly through the Python/C API, which they will be from Cython if declared as type dict) and how much faster glib (linked or non-linked) lists are then Python lists. Have you run any tests? If there is not a significant speed difference, it would be preferable to use the Python datatypes to store Python objects when possible (for cleaner code and to minimize recounting woes). This wouldn't mean that glib isn't worth including however. I don't see how blocking a glib patch because of maintenance issues really helps solve this problem in the long run. Is it really preferable that I code up custom versions of the things so that I can have fast symbolic implementations? No. I think the point is that before including it we should consider issues of maintenance and this may influence where we put it. (Much easier, for instance, than trying to move it later.) I agree that it should probably be a seperate spkg. Most of the bloat in glib is internationaliztaion, which is not included in this patch. The parts that are included are simple enough and well documented enough (either in the code or in glib documents) that anyone should be able to easily maintain it. Furthermore, I intend to help maintain the C algorithms. I fully intend to work on them actively if their speed is not sufficient. Making a seperate spkg dramatically increases the difficulty of active development. I agree that making an spkg raises the barrier of working on it, but not by that much. Also, as an spkg, other components of Sage can make use of it, and I think it will be much easier to keep in sync with and contribute upstream. I'd also really like to avoid a fork, which is what this could easily turn into. I'm noticing a lot of changes from glib 2.16.1 at GNOME. Is this the version you started from? Are you simply copying a subset of the c/h files, or are there significant changes that need to be done every time glib is updated (every month or two looking at the history)? I would like to see this included, but I think these issues need to be resolved now, or they never will until it hurts us. - Robert On Wed, Mar 26, 2008 at 12:26 PM, William Stein [EMAIL PROTECTED] wrote: On Wed, Mar 26, 2008 at 11:16 AM, didier deshommes [EMAIL PROTECTED] wrote: On Wed, Mar 26, 2008 at 1:52 PM, mabshoff [EMAIL PROTECTED] wrote: On Mar 26, 6:43 pm, William Stein [EMAIL PROTECTED] wrote: On Wed, Mar 26, 2008 at 10:09 AM, mabshoff [EMAIL PROTECTED] wrote: On Mar 26, 6:02 pm, William Stein [EMAIL PROTECTED] wrote: Is any of the code gpl v3+ only? No. That's good. How difficult will it be to update our version whenever upstream changes? Do only you know how to do this? Not particularly hard. You didn't answer my second question. Gary did it and I didn't pay much attention to it. I assume it will be documented. I don't consider such a thing hard once it has been documented. Why put this in c_lib instead of a separate spkg called glib-min? Couldn't such a package be useful outside of sage? It is easiest if we put it into libcsage. That's not a good enough answer. Until now almost all code in libcsage and the main sage library has been new code we've written -- except a few exceptions, where we greatly regretted them greatly and moved the code out later. So from experience I'm very opposed to this code being in c_lib. I vote -1 to this code going into sage unless: (1) it is put in a separate spkg, and We can certainly do that. (2) the process of extracting glib-min from the official glib tarball is automated. That is unlikely to happen since it requires manual interaction. It will break in the next release in six months and writing automated tools will take longer than actually doing the work in the first place. How frequent are the glib releases? If they're not that frequent, this should less than an issue as long as Gary documents what he's done
[sage-devel] Re: Sage 2.11.alpha1 released!
mabshoff wrote: Hi folks, Sage 2.11.alpha1 is out. It is a collection of various fixes, nothing particular seems to stand out. We finally pushed the updated experimental mayavi and vtl.spkg. [...] #2493: Jaap Spies: Updated experimental vtk spkg (vtk-5.0.4.spkg) #2495: Jaap Spies: Updated experimental Mayavi2 spkg (mayavi_2.1.1) linux only MayaVi2 seems to build, but fails to run mlab! What the difference between mayavi_2.1.1-20080307.p1.spkg and my original mayavi_2.1.1-20080307.spkg? 1) mv mayavi_build src 2) rm all .svn stuff 3) add .hg and friends I don't understand why: With mayavi_2.1.1-20080307.p1.spkg I get after ./sage -wthread: sage: from enthought.mayavi import mlab as M --- type 'exceptions.ValueError'Traceback (most recent call last) /home/jaap/work/downloads/sage-2.11.alpha1/ipython console in module() /home/jaap/work/downloads/sage-2.11.alpha1/local/lib/python2.5/site-packages/enthought.mayavi-2.1.1.dev-py2.5.egg/enthought/mayavi/mlab.py in module() 15 from tools.config import get_engine, show_engine 16 --- 17 from tools.helper_functions import contour3d, test_contour3d, \ [...] /home/jaap/work/downloads/sage-2.11.alpha1/local/lib/python2.5/site-packages/enthought.pyface-2.0.3-py2.5.egg/enthought/pyface/image_resource.py in _get_image_not_found_image(self) 165 # be broken! 166 else: -- 167 raise ValueError(Rick's installer is broken) 168 169 return image type 'exceptions.ValueError': Rick's installer is broken While mayavi_2.1.1-20080307.spkg builds, installs and runs fine: [EMAIL PROTECTED] sage-2.11.alpha1]$ ./sage -wthread -- | SAGE Version 2.11.alpha1, Release Date: 2008-03-22 | | Type notebook() for the GUI, and license() for information.| -- sage: from enthought.mayavi import mlab as M sage: M. M.axes M.flow M.outline M.show_engineM.test_points3d M.__class__ M.gcfM.pipeline M.__str__M.test_quiver3d M.clfM.__getattribute__ M.plot3d M.surf M.test_quiver3d_2d_data M.colorbar M.get_engine M.points3d M.test_contour3d M.test_simple_surf M.contour3d M.__hash__ M.quiver3d M.test_contour_surf M.test_surf M.contour_surf M.imshow M.__reduce__ M.test_fancy_meshM.text M.__delattr__M.__init__ M.__reduce_ex__ M.test_flow M.title M.__dict__ M.mesh M.__repr__ M.test_imshowM.vectorbar M.__doc__M.__name__ M.roll M.test_mesh M.view M.draw M.__new__M.savefig M.test_mesh_sphere M.xlabel M.figure M.optionsM.scalarbar M.test_molecule M.ylabel M.__file__ M.orientationaxesM.__setattr__ M.test_plot3dM.zlabel My hypothesis for now is that the .svn directories contain essential information for the build system. I might be wrong, ... Jaap --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 2.11.alpha1 released!
On Mar 26, 10:31 pm, Jaap Spies [EMAIL PROTECTED] wrote: mabshoff wrote: Hi folks, Sage 2.11.alpha1 is out. It is a collection of various fixes, nothing particular seems to stand out. We finally pushed the updated experimental mayavi and vtl.spkg. [...] #2493: Jaap Spies: Updated experimental vtk spkg (vtk-5.0.4.spkg) #2495: Jaap Spies: Updated experimental Mayavi2 spkg (mayavi_2.1.1) linux only MayaVi2 seems to build, but fails to run mlab! What the difference between mayavi_2.1.1-20080307.p1.spkg and my original mayavi_2.1.1-20080307.spkg? 1) mv mayavi_build src 2) rm all .svn stuff 3) add .hg and friends I don't understand why: With mayavi_2.1.1-20080307.p1.spkg I get after ./sage -wthread: sage: from enthought.mayavi import mlab as M --- type 'exceptions.ValueError' Traceback (most recent call last) /home/jaap/work/downloads/sage-2.11.alpha1/ipython console in module() /home/jaap/work/downloads/sage-2.11.alpha1/local/lib/python2.5/site-packages/enthought.mayavi-2.1.1.dev-py2.5.egg/enthought/mayavi/mlab.py in module() 15 from tools.config import get_engine, show_engine 16 --- 17 from tools.helper_functions import contour3d, test_contour3d, \ [...] /home/jaap/work/downloads/sage-2.11.alpha1/local/lib/python2.5/site-packages/enthought.pyface-2.0.3-py2.5.egg/enthought/pyface/image_resource.py in _get_image_not_found_image(self) 165 # be broken! 166 else: -- 167 raise ValueError(Rick's installer is broken) 168 169 return image type 'exceptions.ValueError': Rick's installer is broken While mayavi_2.1.1-20080307.spkg builds, installs and runs fine: [EMAIL PROTECTED] sage-2.11.alpha1]$ ./sage -wthread -- | SAGE Version 2.11.alpha1, Release Date: 2008-03-22 | | Type notebook() for the GUI, and license() for information. | -- sage: from enthought.mayavi import mlab as M sage: M. M.axes M.flow M.outline M.show_engine M.test_points3d M.__class__ M.gcf M.pipeline M.__str__ M.test_quiver3d M.clf M.__getattribute__ M.plot3d M.surf M.test_quiver3d_2d_data M.colorbar M.get_engine M.points3d M.test_contour3d M.test_simple_surf M.contour3d M.__hash__ M.quiver3d M.test_contour_surf M.test_surf M.contour_surf M.imshow M.__reduce__ M.test_fancy_mesh M.text M.__delattr__ M.__init__ M.__reduce_ex__ M.test_flow M.title M.__dict__ M.mesh M.__repr__ M.test_imshow M.vectorbar M.__doc__ M.__name__ M.roll M.test_mesh M.view M.draw M.__new__ M.savefig M.test_mesh_sphere M.xlabel M.figure M.options M.scalarbar M.test_molecule M.ylabel M.__file__ M.orientationaxes M.__setattr__ M.test_plot3d M.zlabel My hypothesis for now is that the .svn directories contain essential information for the build system. I might be wrong, ... Well, maybe I did accidentally nuke more than the .svn directories. I cannot imagine a scenario where anything would depend on the content of a .svn directory to run. But I wouldn't be surprised to be proven wrong ;) 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: Sage 2.11.alpha1 released!
mabshoff wrote: Well, maybe I did accidentally nuke more than the .svn directories. I cannot imagine a scenario where anything would depend on the content of a .svn directory to run. But I wouldn't be surprised to be proven wrong ;) I did a diff -r on both directories, only .svn files missing! This egg_build.py is really mysterious :)! Jaap --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Winners of the waste space on sage.math contest March 2008
Hello folks, home on sage.math did just get filled up to the last byte, so things tend to work less well than they used to. Various people in IRC did clean up some of their home directories and now 26 GB are free again. But of the 705G total the following people use at least a Gigabyte: 1.9Gabhinav 5.2Gacgetchell 4.2Gadam 1.4Gaklemm 1.4Galfredo 2.0Gallan 4.3Gbgranger 15G binegar 11G boothby 1.1Gburcin 20G burhanud 4.9Gclarita 1.5Gcswiercz 3.6Gcwitty 1.9Gdav 7.0Gdbm25 2.4Gdeldotdr 12G dfdeshom 1.1Gdisabled_accounts 5.8Gdmharvey 1.5Gekirkman 3.9Ggeorgesk 5.7Ggfurnish 20K Grammian 3.8Gjason 2.4Gjbmohler 1.7Gjec 7.3Gjen 1.1Gjetchev 1.3Gjipsen 3.3Gjkantor 6.0Gjvoight 1.1Gkathy 1.3Gkedlaya 1.4Gmabshoff 2.5Gmacaulay2 4.4Gmalb 1.7Gmanny 4.8Gmhansen 3.9Gmoretti 2.3Gnathan 4.3Gncalexan 6.5Gnovoselt 3.6Gondrej 3.8Gpadicgroup 4.2Gpage 16G pernet 2.9Gpurbon 12G rlmill 3.4Grobertwb 1.4Groed 1.9Gsaliola 28G savitt 5.3Gsimuw 3.1Gsuperstein 1.5Gtclemans 1.2Gtkosan 2.1Gtornaria 416Gwas 4.4Gwatkins 1.1Gwbhart 6.2Gwdj 3.0Gyqiang William wins with 416G, but since he bought the box I guess he can do what he wants. If you have an account and can delete old Sage installs or otherwise useless data please do so. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 2.11.alpha1 released!
On Mar 26, 10:53 pm, Jaap Spies [EMAIL PROTECTED] wrote: mabshoff wrote: Well, maybe I did accidentally nuke more than the .svn directories. I cannot imagine a scenario where anything would depend on the content of a .svn directory to run. But I wouldn't be surprised to be proven wrong ;) I did a diff -r on both directories, only .svn files missing! This egg_build.py is really mysterious :)! Jaap Could it be that some old install of previous spkgs does interfere? When we updated numpy and scipy the last time it was essential that we nuked their old install directories - maybe this is also the case here? 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 2.11.alpha1 released!
mabshoff wrote: On Mar 26, 10:53 pm, Jaap Spies [EMAIL PROTECTED] wrote: mabshoff wrote: Well, maybe I did accidentally nuke more than the .svn directories. I cannot imagine a scenario where anything would depend on the content of a .svn directory to run. But I wouldn't be surprised to be proven wrong ;) I did a diff -r on both directories, only .svn files missing! This egg_build.py is really mysterious :)! Jaap Could it be that some old install of previous spkgs does interfere? When we updated numpy and scipy the last time it was essential that we nuked their old install directories - maybe this is also the case here? I don't think so. I did a fresh install on fresh installed sage-2.10.4, sage-2.11.alpha0, sage-2.11.alpha1 on two machines. The results are consistent. Jaap --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: mercurial -- plain text -- mercurial
Mike Hansen wrote: The queues feature in Mercurial is available independently in the quilt system. Mercurial makes this point: http://hgbook.red-bean.com/hgbookch12.html There are things with queues that you don't get with quilt. Quoting from the book, As an example, the integration of patches with revision control makes understanding patches and debugging their effects—and their interplay with the code they're based on—enormously easier. Since every applied patch has an associated changeset, you can use hg log filename to see which changesets and patches affected a file. You can use the bisect extension to binary-search through all changesets and applied patches to see where a bug got introduced or fixed. You can use the hg annotate command to see which changeset or patch modified a particular line of a source file. And so on. I use git to manage my personal/professional file repository. To me, Mercurial is much simpler, but git is more powerful and feels more stable. I don't have a huge amount of experience with git, though; I keep forgetting the commands to do things, so I keep putting off checking things in and working on things in git :). Thank goodness for the git-gui, gitk, and qgit tools that give graphical interfaces to a git repository! As to queues, of course, the concept and original software originated with the linux development model, as far as I know. Git has a tool called StGit (Stacked Git; http://procode.org/stgit/; it's in python!) and also has Guilt. The messages at http://fixunix.com/kernel/368500-announce-stacked-git-0-14-2-a.html seem to indicate that the two tools overlap (as well as the debian description http://packages.debian.org/unstable/devel/guilt). I haven't used either tool. Git also has some very powerful tools in the way of lightweight branching and rebasing. One thing in a recent release is git rebase --interactive, which allows you to basically go back and edit a commit or change the order of commits, thereby providing queue functionality that is fully integrated with the versioning system (see http://blog.madism.org/index.php/2007/09/09/138-git-awsome-ness-git-rebase-interactive). I don't think, in the end, that there is anything we can do with queues that we can't do with git (possibly using one of the above tools on top of git). However, I haven't tried (I've only read about it), so count that opinion as worth the electrons that conveyed it :). Personally, after getting over the initial learning hump (which I see as much greater than the mercurial learning hump), I think git would provide more power. William, I presume you're looking for something exactly analogous to svnadmin dump for SVN (see http://svnbook.red-bean.com/en/1.1/ch05s03.html ). That command came in very handy for me when I kept things in SVN for a while. One option for what Williams wants to do is to convert a copy of the hg repository to a git repository and then do the text dump (apparently that is possible...I don't have first-hand experience with that). I'm not sure how lossless the conversion would be, but my gut feeling is that it would be good. Jason --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage question, possible contribution to project
No guilt. I feel no personal guilt over ancestors who owned slaves. Just a feeling it's worthwhile to contribute something more substantial that a few bug reports -- I guess meaning can get lost in ASCII. Some of us relatively new people feel like we're lost in a non-English megalopolis with no map -- to where from here? Gee, I can slice, dice, and even julienne, but -- the project is so *$#@ huge, with various included packages and imperfect documentation. What needs done? How to do it? If say, I think, Gee someone might really like this functionality, or, This thing might work better if we tightened this nut, or, This documentation is unclear ... I've read the developer's sites, but still feel a little lost. I recently thought, oh, a means to easily compute the area of a polygon would be nice, but unsure of where to go from here. I try to think like Billy Wilder, whose reputed philosophy was, What movie would** I like to see? -- and was usually right. Tap a writing talent like Raymond Chandler you make *Double Indemnity*. Not pontificating, but did a doctorate in math a few years ago, though my thesis was pretty abstract -- would like to do something a bit more solid. Here or via private e-mail is OK. Thanks for ideas. Dean --- On Wed, Mar 26, 2008 at 10:34 AM, Joel B. Mohler [EMAIL PROTECTED] wrote: On Wednesday 26 March 2008 11:34, dean moore wrote: At this link, http://sagemath.org/doc/html/prog/node1.htmlwe have, Absolutely *everybody* who uses *Sage* should contribute something back to *Sage* at some point. I have had my fun with sage, and debated, How can I return something to the community, however small? I submitted a couple documentation fixes, but probably to the wrong place. A few questions led to tickets bug fixes. I have a trac account at *dmoore*. I can't speak for the rest of the developers, but as someone who has submitted a decent number of patches and has more in the works, I don't at all think you should let that sentence about everybody contributing make you feel guilty. Personally, I'd be much more happy with a statement like: Absolutely *everybody* who uses *Sage* is in a position to contribute something back to *Sage* at some point -- bug reports, mailing list participation, evangelism, and simple patches are all meaningful contributions. However, even if you do none of those little things, it is virtually inconceivable that you can be a heavy user of opensource with-out doing at least some evangelism or bug reporting. If you pay me back for my patches by doing something for another totally unrelated package that I use (or maybe don't happen to use), I feel well-paid. And, well shoot, I've already been paid by learning so much from the other sage developers. Helping sage development is worth it simply for the educational value. I realize that guilt is probably not your main motivation, but I'm just sharing my thoughts as a long time user of opensource software who also doesn't feel like I've contributed back as many good things as I've enjoyed myself. -- Joel --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Glib algorithms #2436 vote
There are non trivial changes involved in getting compilation without internationalization, primarily because their error handling system uses internationalization in many places. Its not just a copy and paste job, but now that I've figured out exactly what headers we need and set up autoconf replacement its not too difficult either (I'd say I could probably do it in an hour and someone not familiar in two or three). On the other hand applying individual patches to files would be very easy. I also noticed many changes but most of them did not seem to be centered around the algorithms that I actually added. I do not agree with the maintence argument for a seperate spkg, but I would be more then willing to move it out of libcsage if others are interested in using the algorithms for other Sage SPKGs. I have not yet benchmarked hash tables (nor actually tried them out), but one of the big advantages is that they avoid much of the memory management issues, so I don't expect them to be slower (and if they are, I may have to fix that). On Wed, Mar 26, 2008 at 3:06 PM, Robert Bradshaw [EMAIL PROTECTED] wrote: On Mar 26, 2008, at 11:57 AM, Gary Furnish wrote: Honestly, independent of the spkg vs libcsage issue, which is really an issue of semantics in my opinion, Sage has no high speed implementations of C algorithms. Sage can not escape this forever. Either someone will have to write their own at some point or we can use glib as a starting block. It is a big chunk of code, but Sage needs fast lists, hash tables, etc. Using glib as a starting point dramatically reduces debugging time, and is therefore preferable. Browsing the glib documentation, looking at its features, and reading what other people have to say about it I think this is a worthy set of things to include. One question I have is how much faster glib hashtables are than python dictionaries (as accessed directly through the Python/C API, which they will be from Cython if declared as type dict) and how much faster glib (linked or non-linked) lists are then Python lists. Have you run any tests? If there is not a significant speed difference, it would be preferable to use the Python datatypes to store Python objects when possible (for cleaner code and to minimize recounting woes). This wouldn't mean that glib isn't worth including however. I don't see how blocking a glib patch because of maintenance issues really helps solve this problem in the long run. Is it really preferable that I code up custom versions of the things so that I can have fast symbolic implementations? No. I think the point is that before including it we should consider issues of maintenance and this may influence where we put it. (Much easier, for instance, than trying to move it later.) I agree that it should probably be a seperate spkg. Most of the bloat in glib is internationaliztaion, which is not included in this patch. The parts that are included are simple enough and well documented enough (either in the code or in glib documents) that anyone should be able to easily maintain it. Furthermore, I intend to help maintain the C algorithms. I fully intend to work on them actively if their speed is not sufficient. Making a seperate spkg dramatically increases the difficulty of active development. I agree that making an spkg raises the barrier of working on it, but not by that much. Also, as an spkg, other components of Sage can make use of it, and I think it will be much easier to keep in sync with and contribute upstream. I'd also really like to avoid a fork, which is what this could easily turn into. I'm noticing a lot of changes from glib 2.16.1 at GNOME. Is this the version you started from? Are you simply copying a subset of the c/h files, or are there significant changes that need to be done every time glib is updated (every month or two looking at the history)? I would like to see this included, but I think these issues need to be resolved now, or they never will until it hurts us. - Robert On Wed, Mar 26, 2008 at 12:26 PM, William Stein [EMAIL PROTECTED] wrote: On Wed, Mar 26, 2008 at 11:16 AM, didier deshommes [EMAIL PROTECTED] wrote: On Wed, Mar 26, 2008 at 1:52 PM, mabshoff [EMAIL PROTECTED] wrote: On Mar 26, 6:43 pm, William Stein [EMAIL PROTECTED] wrote: On Wed, Mar 26, 2008 at 10:09 AM, mabshoff [EMAIL PROTECTED] wrote: On Mar 26, 6:02 pm, William Stein [EMAIL PROTECTED] wrote: Is any of the code gpl v3+ only? No. That's good. How difficult will it be to update our version whenever upstream changes? Do only you know how to do this? Not particularly hard. You didn't answer my second question. Gary did it and I didn't pay much attention to it. I assume it will be documented. I don't consider such a thing hard once it has
[sage-devel] Re: Glib algorithms #2436 vote
On Wed, 26 Mar 2008 14:06:08 -0700, Robert Bradshaw [EMAIL PROTECTED] wrote: On Mar 26, 2008, at 11:57 AM, Gary Furnish wrote: Honestly, independent of the spkg vs libcsage issue, which is really an issue of semantics in my opinion, Sage has no high speed implementations of C algorithms. Sage can not escape this forever. Either someone will have to write their own at some point or we can use glib as a starting block. It is a big chunk of code, but Sage needs fast lists, hash tables, etc. Using glib as a starting point dramatically reduces debugging time, and is therefore preferable. Browsing the glib documentation, looking at its features, and reading what other people have to say about it I think this is a worthy set of things to include. I have to strongly agree that I really want something with the feature set of glib included, and that I don't think we have any business writing it from scratch. One question I have is how much faster glib hashtables are than python dictionaries (as accessed directly through the Python/C API, which they will be from Cython if declared as type dict) and how much faster glib (linked or non-linked) lists are then Python lists. Have you run any tests? If there is not a significant speed difference, it would be preferable to use the Python datatypes to store Python objects when possible (for cleaner code and to minimize recounting woes). This wouldn't mean that glib isn't worth including however. This is certainly worth knowing. I don't see how blocking a glib patch because of maintenance issues really helps solve this problem in the long run. Is it really preferable that I code up custom versions of the things so that I can have fast symbolic implementations? No. I think the point is that before including it we should consider issues of maintenance and this may influence where we put it. (Much easier, for instance, than trying to move it later.) I agree that it should probably be a seperate spkg. Most of the bloat in glib is internationaliztaion, which is not included in this patch. The parts that are included are simple enough and well documented enough (either in the code or in glib documents) that anyone should be able to easily maintain it. Furthermore, I intend to help maintain the C algorithms. I fully intend to work on them actively if their speed is not sufficient. Making a seperate spkg dramatically increases the difficulty of active development. I agree that making an spkg raises the barrier of working on it, but not by that much. Also, as an spkg, other components of Sage can make use of it, and I think it will be much easier to keep in sync with and contribute upstream. I'd also really like to avoid a fork, which is what this could easily turn into. I'm noticing a lot of changes from glib 2.16.1 at GNOME. Is this the version you started from? Are you simply copying a subset of the c/h files, or are there significant changes that need to be done every time glib is updated (every month or two looking at the history)? I would like to see this included, but I think these issues need to be resolved now, or they never will until it hurts us. I agree. And I don't think the above has been sufficiently addressed yet. Sorry to be a pain, but what you're proposing doing with glib is almost the same as say taking the pyrex code and sticking it in SAGE_ROOT/devel/sage/pyrex under the main Sage hg repo. Doing that would amount to both a fork and a maintenance problem. Even I didn't go that far to entagle Pyrex with Sage when forking Pyrex. I want to emphasize again that I strongly disagree with putting all of glib-lite in SAGE_ROOT/devel/sage/, and I don't see why doing that is going to make maintenance easier. But I also want to emphasize that I strongly support glib-lite going into Sage in some form, and I greatly greatly appreciate the hard work you've put into making this possible. -- William -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: mercurial -- plain text -- mercurial
On Wed, 26 Mar 2008 13:59:10 -0700, Robert Bradshaw [EMAIL PROTECTED] wrote: On Mar 26, 2008, at 1:56 PM, mabshoff wrote: On Mar 26, 9:35 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: I was talking about something more sophisticated than export/import, which won't work the instant one has multiple branches. One needs to actually create multiple heads, apply patches, then resolve them. Hg export doesn't have enough information to do this. Ok, sounds good. Do you have any pointers or documentation on this? Not at the moment, but I've mucked around with mercurial more than most so I don't think it should be too hard once I start looking into it. Several people suggested asking on the Mercurial list, and we should do that. There might already be an extension or something to do this. I really don't like the prospect of say Jason Grout's idea to convert the whole Sage repo to git and back just to do that. Ick. Carl Witty said: I still don't understand the requirements. To convert the hg repo to a plain text non-obfuscated format from which one can recreate the original hg repo. Second, are you worried about people checking in viruses, or people concealing a virus in the .hg directory without it being checked in? Both. Yes, I'm worried about people checking viruses. Yes, I'm also worried about people concealing a virus in the .hg directory without it being checked in. For the former concern, it seems that it would be sufficient to check out the files, and you don't need to recreate the repository. That requires trusting Mercurial, and that there aren't any bugs in Mercurial that allow one to work around such checks. That isn't a reasonable hypothesis, unfortunately. Also, the virus could be in an old version of the repo, so you have to check out that last 9000 or so states of the repo. For the latter concern, perhaps something based on hg verify would suffice to ensure that nothing nasty has been hidden in the repository. Again, this requires trusting Mercurial, and that nobody found a way to workaround something like this in Mercurial. That's again not a reasonable assumption to make. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Glib algorithms #2436 vote
On Wed, 26 Mar 2008 11:57:26 -0700, Gary Furnish [EMAIL PROTECTED] wrote: Honestly, independent of the spkg vs libcsage issue, which is really an issue of semantics in my opinion, Sage has no high speed implementations of C algorithms. Sage can not escape this forever. Either someone will have to write their own at some point or we can use glib as a starting block. It is a big chunk of code, but Sage needs fast lists, hash tables, etc. Using glib as a starting point dramatically reduces debugging time, and is therefore preferable. I don't see how blocking a glib patch because of maintenance issues really helps solve this problem in the long run. Is it really preferable that I code up custom versions of the things so that I can have fast symbolic implementations? I'm not trying to block the patch in order to solve the problem. I'm just hoping to convince you that putting this code in libcsage is the wrong approach for numerous reasons. That a glib-lite derivative of glib is best done as a separate spkg, and that this has by far the best chance of living, being useful outside of Sage, etc. Also, from my point of view almost _everybody_ involved in Sage has come and gone, at one point or another, and I want *nothing* in Sage whose maintenance depends on only one person. I'm scared of a bus factor of 1 for anything in Sage. Most of the bloat in glib is internationaliztaion, which is not included in this patch. The parts that are included are simple enough and well documented enough (either in the code or in glib documents) that anyone should be able to easily maintain it. That's very good to know. Furthermore, I intend to help maintain the C algorithms. I fully intend to work on them actively if their speed is not sufficient. Making a seperate spkg dramatically increases the difficulty of active development. Why??? I could have said the same about Pyrex two years ago, and it would have been silly. So could you please explain why this is true of glib-lite. I'm not saying it isn't try! I just don't see why it should be. I know you're extremely good at writing and arguing points, so please be patient with me and explain why Making a seperate spkg dramatically increases the difficulty of active development. Again, I'm *not* at all sure I'm right! And you've been much closer to that code than I am, so you're much more likely to be right. That said, you've not given any argument, and this is the time to work these things out -- that's why we have a vote, etc., for packages. -- William On Wed, Mar 26, 2008 at 12:26 PM, William Stein [EMAIL PROTECTED] wrote: On Wed, Mar 26, 2008 at 11:16 AM, didier deshommes [EMAIL PROTECTED] wrote: On Wed, Mar 26, 2008 at 1:52 PM, mabshoff [EMAIL PROTECTED] wrote: On Mar 26, 6:43 pm, William Stein [EMAIL PROTECTED] wrote: On Wed, Mar 26, 2008 at 10:09 AM, mabshoff [EMAIL PROTECTED] wrote: On Mar 26, 6:02 pm, William Stein [EMAIL PROTECTED] wrote: Is any of the code gpl v3+ only? No. That's good. How difficult will it be to update our version whenever upstream changes? Do only you know how to do this? Not particularly hard. You didn't answer my second question. Gary did it and I didn't pay much attention to it. I assume it will be documented. I don't consider such a thing hard once it has been documented. Why put this in c_lib instead of a separate spkg called glib-min? Couldn't such a package be useful outside of sage? It is easiest if we put it into libcsage. That's not a good enough answer. Until now almost all code in libcsage and the main sage library has been new code we've written -- except a few exceptions, where we greatly regretted them greatly and moved the code out later. So from experience I'm very opposed to this code being in c_lib. I vote -1 to this code going into sage unless: (1) it is put in a separate spkg, and We can certainly do that. (2) the process of extracting glib-min from the official glib tarball is automated. That is unlikely to happen since it requires manual interaction. It will break in the next release in six months and writing automated tools will take longer than actually doing the work in the first place. How frequent are the glib releases? If they're not that frequent, this should less than an issue as long as Gary documents what he's done somewhere :) If you've been maintaining packages for Sage for three years, and expect to be maintaining them for years to come, you'de view this as a much bigger deal. It's really bad when there is a big chunk of code in Sage that gets out of stream with up stream, but no easy way to resolve that
[sage-devel] Re: Glib algorithms #2436 vote
On Mar 26, 2008, at 4:48 PM, Gary Furnish wrote: I have not yet benchmarked hash tables (nor actually tried them out), but one of the big advantages is that they avoid much of the memory management issues, so I don't expect them to be slower (and if they are, I may have to fix that). It is my understanding that Python dictionaries have been optimized a lot, because in the end most of the speed of Python boils down to how fast it can do dictionary lookups. I'm thinking specifically of the case where keys and/or values are Python objects. (If they are not then wrapping them can be a large overhead.) As for memory management issues, if one is storing Python objects than this is actually a bonus, otherwise one would have to do the memory management manually (which is both error-prone and negates any savings). - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
