[sage-devel] Mercurial Chapter in Progamming Guide
Chapter 7 in the Progamming Guide, about using Mercurial, only mentions hg_sage but not hg_c_lib,hg_doc, hg_extcode, hg_scripts.I just discovered the existence of hg_extcode as I had been editing some extcode! Now presumably I could rewrite that myself using hg_doc and submit a patch While I'm here, where it says that in hg_sage.ci() the ci is short for commit, I think it's actually short for check in (thinking of RCS rather than CVS...) John -- John Cremona --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Mercurial Chapter in Progamming Guide
Actually, on that same page it talks about hg_log() while it really means hg_sage.log()... That should be changed as well! Paul On Aug 20, 11:14 am, John Cremona [EMAIL PROTECTED] wrote: Chapter 7 in the Progamming Guide, about using Mercurial, only mentions hg_sage but not hg_c_lib,hg_doc, hg_extcode, hg_scripts.I just discovered the existence of hg_extcode as I had been editing some extcode! Now presumably I could rewrite that myself using hg_doc and submit a patch While I'm here, where it says that in hg_sage.ci() the ci is short for commit, I think it's actually short for check in (thinking of RCS rather than CVS...) John -- John Cremona --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Mercurial Chapter in Progamming Guide
John Cremona wrote: While I'm here, where it says that in hg_sage.ci() the ci is short for commit, I think it's actually short for check in (thinking of RCS rather than CVS...) My fault. Jaap Spies --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Toward sage-2.8.2 and 2.8.3
- A new if you work on something it should be in trac rule: Instead of submitting patches directly to William you should create tickets in Sage's trac. So write William an Email and get a track account. - I volunteered to take care of Sage's trac installation and do bug triage and attempt to coordinate fixes. We should really avoid letting bugs get stale in trac and also make sure that we close tickets for issues that have been fixed either accidentally or via some other patch. Obviously if you like to help out let me know. One thing that I think has helped sage enormously is inline doctests that are executed frequently. Well-formed trac reports more or less include doctests, i.e. the offending code, but these failtests are never executed. Would it be possible to doctest trac to find bugs that have been incidentally closed, etc? On an unrelated note, is there a way to interface to trac via email? I find that submitting bug reports via the web interface is far away from my development environment; my email client is not. Nick --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Toward sage-2.8.2 and 2.8.3
On Aug 20, 6:18 pm, Nicholas Alexander [EMAIL PROTECTED] wrote:
- A new if you work on something it should be in trac rule: Instead
of submitting patches directly to William you should create tickets in
Sage's trac. So write William an Email and get a track account.
- I volunteered to take care of Sage's trac installation and do bug
triage and attempt to coordinate fixes. We should really avoid letting
bugs get stale in trac and also make sure that we close tickets for
issues that have been fixed either accidentally or via some other
patch. Obviously if you like to help out let me know.
One thing that I think has helped sage enormously is inline doctests
that are executed frequently. Well-formed trac reports more or less
include doctests, i.e. the offending code, but these failtests are
never executed. Would it be possible to doctest trac to find bugs
that have been incidentally closed, etc?
On an unrelated note, is there a way to interface to trac via email?
I find that submitting bug reports via the web interface is far away
from my development environment; my email client is not.
Nick
Hello,
another neat thing to have would be installation of the mercial trac
plugin. That way we can refer to specific commits in the trac wiki as
well as on tickets.
When I requested the trac page {4} Assigned, Active Tickets by
Owner (see http://www.sagemath.org:9002/sage_trac/report/4 ) I
couldn't find was or me. Does anybody know the solution because the
above query shows a total of 8 tickets open.
Cheers,
Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] next bug squash?
Hi, I propose that the next SAGE bug squash even be Saturday, September 1, which is in two weeks. Whose interested? It might be fun for the Seattle-area people to all meet up in a common location for this. -- William Stein Associate Professor of Mathematics University of Washington http://www.williamstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: next bug squash?
On Aug 20, 8:05 pm, William Stein [EMAIL PROTECTED] wrote: Hi, Hello, I propose that the next SAGE bug squash even be Saturday, September 1, which is in two weeks. Whose interested? I am. Date is fine, Saturday is also a good day because it lets one recover on Sunday. How does this relate to the 2.8.3 release date? I have started triaging potentially interesting bugs to be fixed for the 2.8.3 milestone. While I haven't gotten as far as I would like yet I would really like somebody with detailed knowledge of the notebook to go through the open notebook bugs and decide which have been fixed and which are still relevant. At Bug Day 1 the notebook got very little love tender care, but there are plenty of tickets that are notebook related. While we are milestones: Do you have any thoughts on 3.0 regrading features and timing? I think it would also be great if the patches that went to referees would also go into trac as a ticket, that way interested parties know what is coming up. It might be fun for the Seattle-area people to all meet up in a common location for this. Love to join you, but my commute is a bitch :) I am about to finish the summary of Bug Day 1 and I have put a preliminary version at http://www.sagemath.org:9001/bug1/Results - the biggest lesson I have learned from Bug Day 1 is to report the results in real time because if you have to go through a log with a couple thousand lines after the fact it is a little more work than hoped for. Cheers, Michael -- William Stein Associate Professor of Mathematics University of Washingtonhttp://www.williamstein.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sage-devel group. To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel?hl=en -~--~~~~--~~--~--~---
[sage-devel] Re: next bug squash?
On Aug 20, 2007, at 2:05 PM, William Stein wrote: I propose that the next SAGE bug squash even be Saturday, September 1, which is in two weeks. Whose interested? It might be fun for the Seattle-area people to all meet up in a common location for this. I can probably be there. (IRC, not seattle.) david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: next bug squash?
On Monday 20 August 2007, William Stein wrote: Hi, I propose that the next SAGE bug squash even be Saturday, September 1, which is in two weeks. Whose interested? I am interested but it is highly unlikely I can attend: It is my moving weekend. I should be settled the weekend after. I'd prefer the September 15, though. Martin PS: I know I am away-from-keyboard quite often these days, so I'd understand if my preferences were not taken into account. -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Toward sage-2.8.2 and 2.8.3
On Aug 20, 2007, at 9:18 AM, Nicholas Alexander wrote: - A new if you work on something it should be in trac rule: Instead of submitting patches directly to William you should create tickets in Sage's trac. So write William an Email and get a track account. - I volunteered to take care of Sage's trac installation and do bug triage and attempt to coordinate fixes. We should really avoid letting bugs get stale in trac and also make sure that we close tickets for issues that have been fixed either accidentally or via some other patch. Obviously if you like to help out let me know. One thing that I think has helped sage enormously is inline doctests that are executed frequently. Well-formed trac reports more or less include doctests, i.e. the offending code, but these failtests are never executed. Would it be possible to doctest trac to find bugs that have been incidentally closed, etc? On an unrelated note, is there a way to interface to trac via email? I find that submitting bug reports via the web interface is far away from my development environment; my email client is not. We are looking into using trac for the Unv. Washington Math Dept. help system, and if no one finds a way to submit bug reports via email, I will be writing one (it doesn't look to hard) as that is an essential requirement for us. +1 for the mercial plugin as well. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: SEP: Valgrind Sage integration: Hunting memory leaks
On Aug 20, 8:10 pm, Bill Hart [EMAIL PROTECTED] wrote: Getting rid of memory leaks also speeds up code dramatically as I found out recently. When new memory is allocated by the kernel, it isn't quite ready to be used. As you begin writing to it, pages of roughly 4kb at a time initiate an interrupt which the kernel has to deal with, called a minor page fault. These take quite some time to deal with. So using more and more memory results in more and more minor page faults. So there is definite benefit in killing memory leaks, even less serious ones. Hey Bill, However, there is one error which valgrind reports on my own code from time to time which I have been unable to determine the source of. It says something like conditional jump depends on uninitialised data. I have stared at code for hours trying to determine where these errors come from. I still have code for which I have been unable to eliminate such errors. That usually happens in the following circumstance: int i; // this is initialized to zero on any sane system, i.e. anywhere but Windows :) if (i0) do something; Now valgrind assumes that conditional jump depends on uninitialised data, i.e. i. Well, but it is zero anyway would one say. And you would be correct in 99% of all cases, but I fixed a bug very similar to the above in LinBox about 4 weeks ago that caused a crash on Debian unstable's gcc but not with the other 10 compilers I tried. Lesson lerned. The assigment to zero puts i into another segment, so many people avoid it. I understand the meaning of the error as such, but couldn't determine why valgrind thought that part of my code contained such an error. Perhaps valgrind is not infallible, or perhaps I've been missing something. Bill. Cheers, Michael SNIP --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: next bug squash?
2007/8/20, William Stein [EMAIL PROTECTED]: Hi, I propose that the next SAGE bug squash even be Saturday, September 1, which is in two weeks. Whose interested? Looks like I'll miss that one too, as I'll be out of town for labor day weekend. Those are just some ideas for what would make SAGE 3.0 material. Let me know what you think. High on my wishlist is being able to run SAGE on solaris 10 (opensolaris). With all the work that has been done on porting SAGE on solaris 9, this should be easier... in theory. 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Quitting ignored worksheet vs. long computations
Nils Bruin [EMAIL PROTECTED] writes: This makes me think that a checkbox this worksheet is persistent might be better. This sounds good to me. I'm also curious what happens if I leave a browser open to a worksheet in my office, and then open the worksheet again from home. Do they somehow synchronize? Dan --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: next bug squash?
On 8/20/07, didier deshommes [EMAIL PROTECTED] wrote: 2007/8/20, William Stein [EMAIL PROTECTED]: Hi, I propose that the next SAGE bug squash even be Saturday, September 1, which is in two weeks. Whose interested? Looks like I'll miss that one too, as I'll be out of town for labor day weekend. Those are just some ideas for what would make SAGE 3.0 material. Let me know what you think. High on my wishlist is being able to run SAGE on solaris 10 (opensolaris). With all the work that has been done on porting SAGE on solaris 9, this should be easier... in theory. I would like to encourage everybody to post their top wishlist item; we'll see what's popular (and realistic), and make those the milestones for sage-3.0. I'm working on the solaris port right now, by the way. I hope to have it by the end of the week. Drop in on irc.freenode.net #sage-devel to help out. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: next bug squash?
I would like to encourage everybody to post their top wishlist item; we'll see what's popular (and realistic), and make those the milestones for sage-3.0. I'd like to see PolyBoRi integrated by then. That would be a real killer feature (for people like me). Also I want to have contributed my MPolynomialSystem generators for several crypto systems (*) by then, whenever 'then' is. 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: next bug squash?
On 8/20/07, Martin Albrecht [EMAIL PROTECTED] wrote: I would like to encourage everybody to post their top wishlist item; we'll see what's popular (and realistic), and make those the milestones for sage-3.0. I'd like to see PolyBoRi integrated by then. That would be a real killer feature (for people like me). Also I want to have contributed my MPolynomialSystem generators for several crypto systems (*) by then, whenever 'then' is. I view then as being about Jan 1, 2008. It would be great to have SAGE-3.0 available when I'm at the AMS meeting in San Diego.So 3 months is the sort of time frame I have in mind. Is that reasonable for PolyBoRi? William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: next bug squash?
On Aug 20, 10:56 pm, William Stein [EMAIL PROTECTED] wrote: On 8/20/07, Martin Albrecht [EMAIL PROTECTED] wrote: And something completely different: There are people out there with little or no coding experience. But those people can help during Bug Days too by improving the Wiki or by trawling sage-support for how do I question (and answers) and add them somewhere to the documentation. I would like to encourage everybody to post their top wishlist item; we'll see what's popular (and realistic), and make those the milestones for sage-3.0. I'd like to see PolyBoRi integrated by then. That would be a real killer feature (for people like me). Also I want to have contributed my MPolynomialSystem generators for several crypto systems (*) by then, whenever 'then' is. I view then as being about Jan 1, 2008. It would be great to have SAGE-3.0 available when I'm at the AMS meeting in San Diego.So 3 months is the sort of time frame I have in mind. Is that reasonable for PolyBoRi? William This entails getting it to build on Solaris. I am sure it runs on OSX because that Michael Brickenstein has a Mac Laptop. So Michael, does the code compile on Solaris? It seems likely because as a future part of Singular I am sure that your boss would like to see that it does. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] What you need to build SAGE
[I was going to post this on Trac as an enhancement, but Trac seems to be down at the moment] Hi, Current;y, the only official dependencies for SAGE are: gcc, g++, make, m4, perl, ranlib, and tar (in $SAGE_ROOT/README.txt). I'd like to see these specified with a little more detail in the README file, so that new users know exactly what they need to make SAGE run. These are what I've used to build SAGE on my laptop on linux (ubuntu 7.04): gcc/g++ 4.1 and above (version 3.4 OK) autoconf 2.59 and above automake 1.10 flex 2.5.33 bison 2.3 make 3.81 bunzip2 1.0.3 tar 1.6 perl 5.0 ranlib 2.17.50 m4 1.4.8 Anything I'm missing? 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: next bug squash?
I view then as being about Jan 1, 2008. It would be great to have SAGE-3.0 available when I'm at the AMS meeting in San Diego.So 3 months is the sort of time frame I have in mind. Is that reasonable for PolyBoRi? I think so. The authors want to release it to the public by the end of the year and we should be ready just in time with our wrapper because we -- well Burcin so far -- are working with a preliminary version. Starting next month I'll also have more time to spend on this. 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: next bug squash?
Hi, Hello, I propose that the next SAGE bug squash even be Saturday, September 1, which is in two weeks. Whose interested? Looks like I'll miss that one too, as I'll be out of town for labor day weekend. Those are just some ideas for what would make SAGE 3.0 material. Let me know what you think. High on my wishlist is being able to run SAGE on solaris 10 (opensolaris). With all the work that has been done on porting SAGE on solaris 9, this should be easier... in theory. I just ordered my new Opteron workstation and it will run Solaris 10 some of the time, so I will try to get it to work, too. Martin Albrecht is also interested in getting Sage to work on Solaris/ Opteron. William and I are in IRC so feel free to drop by or visit us on neron. We got a working clisp (hopefully), but are currently stuck with Maxima. Maybe it is time to build another lisp. To quote William: [22:37] was_ I talked to a guy who was heavily involved in lisp, solaris, and sysadmining. [22:37] mabshoff What did he say? [22:37] was_ He showed me his build log files -- clisp stopped working on solaris for [22:37] was_ him in 1997! We found a clisp binary from 2002 on neron, so let's see. The overall situation: Most major packets build, I believe sympow and cvxopt are the remaining holdouts. cvxopt complains about a missing complex.h. I know that there cvxopt binaries for Solaris - so any ideas? sympow might be slightly harder to crack due to the whole Sparc thing. didier Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: next bug squash?
And something completely different: There are people out there with little or no coding experience. But those people can help during Bug Days too by improving the Wiki or by trawling sage-support for how do I question (and answers) and add them somewhere to the documentation. +1 This requires all of us to fill a ton of bugreports against the Wiki and the documentation, though. So: Report more bugs! 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: What you need to build SAGE
On 8/20/07, didier deshommes [EMAIL PROTECTED] wrote: [I was going to post this on Trac as an enhancement, but Trac seems to be down at the moment] I just checked and trac isn't down. If it ever does go down though, please report immediately. Current;y, the only official dependencies for SAGE are: gcc, g++, make, m4, perl, ranlib, and tar (in $SAGE_ROOT/README.txt). I'd like to see these specified with a little more detail in the README file, so that new users know exactly what they need to make SAGE run. These are what I've used to build SAGE on my laptop on linux (ubuntu 7.04): gcc/g++ 4.1 and above (version 3.4 OK) autoconf 2.59 and above automake 1.10 You absolutely should not need autoconf and automake. If you need them to build any SAGE spkg, then it is a bug. We should not list those as requirements. flex 2.5.33 bison 2.3 make 3.81 bunzip2 1.0.3 Again, you definitely should *not* need bunzip2 to build SAGE, as SAGE includes bunzip2. It's not a dependency. If it is, then it's a bug in SAGE. tar 1.6 Yep, I didn't list that since I assumed somebody with the source tarball had tar, or they wouldn't be able to extract the source tarball. perl 5.0 ranlib 2.17.50 m4 1.4.8 William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: What you need to build SAGE
On Aug 20, 11:08 pm, didier deshommes [EMAIL PROTECTED] wrote: [I was going to post this on Trac as an enhancement, but Trac seems to be down at the moment] Hello, trac is working for me at the moment. Hi, Current;y, the only official dependencies for SAGE are: gcc, g++, make, m4, perl, ranlib, and tar (in $SAGE_ROOT/README.txt). I'd like to see these specified with a little more detail in the README file, so that new users know exactly what they need to make SAGE run. These are what I've used to build SAGE on my laptop on linux (ubuntu 7.04): gcc/g++ 4.1 and above (version 3.4 OK) autoconf 2.59 and above automake 1.10 Which packages need those? All spkgs have a prebuild configure - or at least should - especially because MacOSX has rather old autotools (last time I checked at least) flex 2.5.33 bison 2.3 That sounds about right. We had problems earlier with an older bison the Singular 3.0.3 make 3.81 bunzip2 1.0.3 tar 1.6 perl 5.0 To quote ticket #327: In sage base check of prerequisites should also check for perl 5.8. According to Kevin Buzzard, building maxima using perl 5.6 fails with this error, but upgrading to perl 5.8 resolves the problem: That seems to be a rather stringent requirement to build Maxima. Can anybody confirm the problem with perl 5.6? Especially if perl 5.0 works. ranlib 2.17.50 m4 1.4.8 There used to be the need for a gnu patch, but that was fixed due to Solaris's patch being retarded. Now we no longer need patch. Anything I'm missing? didier Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: next bug squash?
2007/8/20, mabshoff [EMAIL PROTECTED]: The overall situation: Most major packets build, I believe sympow and cvxopt are the remaining holdouts. cvxopt complains about a missing complex.h. I know that there cvxopt binaries for Solaris - so any ideas? sympow might be slightly harder to crack due to the whole Sparc thing. Hi, I had no problem building sympow after making sure that CC='gcc'. Of course, it gives me: You do not appear to have an x86 based system --- not using fpu.c and I don't know whether that's important or not (is that what the Sparc thing is about?). I should have more time to look at it in 4 hours. 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: next bug squash?
didier deshommes wrote: 2007/8/20, mabshoff [EMAIL PROTECTED]: The overall situation: Most major packets build, I believe sympow and cvxopt are the remaining holdouts. cvxopt complains about a missing complex.h. I know that there cvxopt binaries for Solaris - so any ideas? sympow might be slightly harder to crack due to the whole Sparc thing. Hi, I had no problem building sympow after making sure that CC='gcc'. Of course, it gives me: You do not appear to have an x86 based system --- not using fpu.c Okay. and I don't know whether that's important or not (is that what the Sparc thing is about?). Yeah, I think that sympow uses extended precision for doubles. I never ran properly on Cygwin on x86 cpus, so I am somewhat worried on getting this to run properly on Sparc without some freaky gcc flags or some sparc assembly. I don't think it is high on Willam's priority list because it seems to be rather specialized, I should have more time to look at it in 4 hours. Cool, I won't be around then any more (bedtime for me in an hour or two), but let us know what you find out. didier Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: What you need to build SAGE
Hi, On Mon, Aug 20, 2007 at 02:28:04PM -0700, mabshoff wrote: flex 2.5.33 bison 2.3 That sounds about right. We had problems earlier with an older bison the Singular 3.0.3 I'm not familiar with Singular, but after a quick look at the spkg I see the files generated by flex and bison are included in the package. It is my understanding that the presence of flex and bison shouldn't be required at build time. -- Juan M. Bello Rivas --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: What you need to build SAGE
On 8/20/07, mabshoff [EMAIL PROTECTED] wrote: Yes, that is true, but if the timestamp of the generated file is older than say the bison input Make will rebuild it. One just needs to update the spkg after running bison and flex manually. But since the spkg-install checks for bison and flex anyway that seems not worth it. It only broken on William's Sun because that box had some seriously outdated bison. I actually ran into this on 2 or 3 other machines last week as well. Very old bison's are common. It is my understanding that the presence of flex and bison shouldn't be required at build time. With a little magic that can be accomplished. I would very much appreciate someone fixing the singular spkg so flex and bison are never needed. Maybe we could touch the generated files in spkg-install right at the beginnig? It would be very nice to remove those two dependencies. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: What you need to build SAGE
On Mon, Aug 20, 2007 at 03:47:42PM -0700, William Stein wrote: I would very much appreciate someone fixing the singular spkg so flex and bison are never needed. Maybe we could touch the generated files in spkg-install right at the beginnig? It would be very nice to remove those two dependencies. This is now Ticket #472 and I'll take care of it. -- Juan M. Bello Rivas --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] sagelite
Hi, I want to create a SAGE lite version of SAGE. This is inspired by the following: * OLPC * Porting SAGE to run on certain architectures is very hard * Changing SAGE so it installs into a system-wide Python is hard. * Many people could benefit from the SAGE interfaces (to Gap, Maple, etc.) * It would be trivial (technically) to get SAGE lite into debian/ubuntu. The question is what should go in SAGE lite. Thoughts? I think the key constraints should be: 1. SAGE lite is pure Python 2. Dependence on twisted and pexpect 2.0 is fine. The key thing is that SAGE lite must be 100% pure Python, so it can install on anything, even a little handheld, as long as Python-2.5 is fully available on that computer. What I envision being in SAGE lite is at least the following: * The SAGE notebook * DSage * The SAGE interfaces (to Gap, Maxima, Maple, Magma, etc.) and maybe: * Maybe SAGE's current Calculus package which will work only if the user has a maxima on their system. * Sympy -- though it could be distributed separately Thoughts? Basically, the initial point of this is that if somebody wants to use SAGE just to talk with mathematica, or just for the notebook then they can trivially do so. If they need serious math functionality, they have to install something more. In the long run though, with help from Sympy, this could have a feel very much like SAGE, but without all the serious mathematical functionality -- but still enough for some users. -- William Stein Associate Professor of Mathematics University of Washington http://www.williamstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sagelite
Thoughts? Basically, the initial point of this is that if somebody wants to use SAGE just to talk with mathematica, or just for the notebook then they can trivially do so. If they need serious math functionality, they have to install something more. In the long run though, with help from Sympy, this could have a feel very much like SAGE, but without all the serious mathematical functionality -- but still enough for some users. I envision a maintenance nightmare. Does function 'xy' depend on anything outside of Python? Can you even unbundle the stuff that far without big hassles (e.g., the SINGULAR interfaces converts to SAGE MPolynomials)? I really like the comes-with-batteries-included approach of SAGE. 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sagelite
I can't imagine SAGE doing much (as it is now) in pure python--for example we wouldn't even have Integer.pyx. Even the calculus package has pyx files, and I would envision it getting more. The lite makes it seem like the core is still there, and I don't see how to extract that. The only think I could see in this direction is something called SAGE interface or something like that that would contain the tree items mentioned below, i.e. - Notebook - DSage - (Pure python) interfaces. I think if it does anything mathematical on its own, it will be a very hard to draw (and understand) line (not to mention maintenance headache). - Robert On Aug 20, 2007, at 4:24 PM, William Stein wrote: Hi, I want to create a SAGE lite version of SAGE. This is inspired by the following: * OLPC * Porting SAGE to run on certain architectures is very hard * Changing SAGE so it installs into a system-wide Python is hard. * Many people could benefit from the SAGE interfaces (to Gap, Maple, etc.) * It would be trivial (technically) to get SAGE lite into debian/ ubuntu. The question is what should go in SAGE lite. Thoughts? I think the key constraints should be: 1. SAGE lite is pure Python 2. Dependence on twisted and pexpect 2.0 is fine. The key thing is that SAGE lite must be 100% pure Python, so it can install on anything, even a little handheld, as long as Python-2.5 is fully available on that computer. What I envision being in SAGE lite is at least the following: * The SAGE notebook * DSage * The SAGE interfaces (to Gap, Maxima, Maple, Magma, etc.) and maybe: * Maybe SAGE's current Calculus package which will work only if the user has a maxima on their system. * Sympy -- though it could be distributed separately Thoughts? Basically, the initial point of this is that if somebody wants to use SAGE just to talk with mathematica, or just for the notebook then they can trivially do so. If they need serious math functionality, they have to install something more. In the long run though, with help from Sympy, this could have a feel very much like SAGE, but without all the serious mathematical functionality -- but still enough for some users. -- William Stein Associate Professor of Mathematics University of Washington http://www.williamstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sagelite
The question is what should go in SAGE lite. Thoughts? I think the key constraints should be: 1. SAGE lite is pure Python 2. Dependence on twisted and pexpect 2.0 is fine. Much of the core functionality of SAGE is written in Cython. Since it is a stated goal of Cython to be shipped with python, perhaps that would be a better place to focus, for now? --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sagelite
On 8/20/07, Robert Bradshaw [EMAIL PROTECTED] wrote:
I can't imagine SAGE doing much (as it is now) in pure python--for
example we wouldn't even have Integer.pyx.
Wrong. The notebook is fully functional in pure python, as is DSAGE,
and as is all of the interfaces to Gap, maxima, etc.
Even the calculus package
has pyx files, and I would envision it getting more.
Those are *only* to support some syntac suger, e.g., var('...') doing
namespace injection. That unecessary for the calculus package.
The lite makes
it seem like the core is still there, and I don't see how to extract
that.
It depends on what you view as the core. Maybe lite is the wrong name.
For tons of people out there the notebook and interfaces are the only
parts of SAGE they currently use. Think, e.g., of Fernando Perez -- he'd
be likely to use something simple-to-install with the interfaces to Mathematica,
etc., in it. He has no need of our algebraic functionality, since he uses
scipy for his number crunching needs.
The only think I could see in this direction is something called
SAGE interface or something like that that would contain the tree
items mentioned below, i.e.\
- Notebook
- DSage
- (Pure python) interfaces.
I think if it does anything mathematical on its own, it will be a
very hard to draw (and understand) line (not to mention maintenance
headache).
I disagree, especially because of the existence of Sympy. A
couple months ago Sympy was not serious functionality wise,
like nzmath, but Sympy is rapidly progressing (partly because Google
gave them a lot of summer of code projects). Sympy is nothing
like nzmath, and in fact I think sympy is going to improve greatly.
Also, I know the calculus stuff in SAGE very well,
and it's dependence on the rest of SAGE is fairly
minimal, so it would be easy to modify so it doesn't
depend on the serious math library part of SAGE.
It would work on any system with maxima installed.
Boothby says:
Much of the core functionality of SAGE is written in Cython. Since it is a
stated goal of Cython to be shipped with python, perhaps that would be
a better place to focus, for now?
No, since Cython requires a compiler -- it's not interpreted code. This
would violate one of the basic design constraints for SAGElite.
Anyway, I'm not surprised by the negative feedback so far, since people
have been telling me forever to create something like SAGElite and I've
been against it. But now I think it is the right thing to do.
-- William
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: sagelite
On 8/20/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: The question is what should go in SAGE lite. Thoughts? I think the key constraints should be: 1. SAGE lite is pure Python 2. Dependence on twisted and pexpect 2.0 is fine. Another very natural thing to put in sage-lite would be plotting functionality. The problem is that this depends on matplotlib, and matplotlib is hard to build and requires compiled code. But I think matplotlib binaries are available for most platforms. By the way, another possible goal for SageLite is that it should run under MS Windows. Mabshoff thinks pexpect can be made natively under Windows... -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sagelite
*unless* we actually start providing some math functionality. Isn't SAGE math functionality? :) Those who where at SAGE days 4 might remember that Dorian and I have already spent a bunch of effort working on a general notebook interface to Python and theoretically any other interpreted languages installed on the machine. We GPL'd it during sage days 4 and we are continuing to work on it, including a non-reliance on Pexpect (which does not work on Windows), see: trac.knoboo.com Obviously we want it to work perfectly with SAGE because SAGE has some much amazing functionality. Maybe combined effort would be good :) Alex --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sagelite
On 8/20/07, alex clemesha [EMAIL PROTECTED] wrote: *unless* we actually start providing some math functionality. Isn't SAGE math functionality? :) It is definitely not the case that SAGE is only math functionality. The Notebook GUI, the interfaces to other programs, and DSage all apriori have nothing to do with mathematics. Those who where at SAGE days 4 might remember that Dorian and I have already spent a bunch of effort working on a general notebook interface to Python and theoretically any other interpreted languages installed on the machine. We GPL'd it during sage days 4 and we are continuing to work on it, including a non-reliance on Pexpect (which does not work on Windows), Pexpect not working on windows is subject to debate. see: trac.knoboo.com Obviously we want it to work perfectly with SAGE because SAGE has some much amazing functionality. Maybe combined effort would be good :) Yep, certainly. SAGElite should be more than just the notebook, though. It's also the interfaces to other programs, and DSAGE, and a minimum. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sagelite
On Aug 21, 2:11 am, William Stein [EMAIL PROTECTED] wrote: On 8/20/07, alex clemesha [EMAIL PROTECTED] wrote: *unless* we actually start providing some math functionality. Isn't SAGE math functionality? :) It is definitely not the case that SAGE is only math functionality. The Notebook GUI, the interfaces to other programs, and DSage all apriori have nothing to do with mathematics. Those who where at SAGE days 4 might remember that Dorian and I have already spent a bunch of effort working on a general notebook interface to Python and theoretically any other interpreted languages installed on the machine. We GPL'd it during sage days 4 and we are continuing to work on it, including a non-reliance on Pexpect (which does not work on Windows), Pexpect not working on windows is subject to debate. pexpect works with cygwin. How well is another story, but in that case we just need to fix it. Cheers, Michael see: trac.knoboo.com Obviously we want it to work perfectly with SAGE because SAGE has some much amazing functionality. Maybe combined effort would be good :) Yep, certainly. SAGElite should be more than just the notebook, though. It's also the interfaces to other programs, and DSAGE, and a minimum. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sagelite
My first impression of this idea is mostly negative, but I'm interested to see where this goes. Will SAGElite use the preparser? That would be a problem if Integer (2) appears somewhere, and Integer is not defined. If you want calculus/plotting then presumably you want people to be able to enter x^3 + x + 2, which means they have to enter x**3 + x + 2, unless the preparser is available. So you can either (a) not let people use ^ (b) redefine Integer to be int (c) have a different preparser for SAGElite which doesn't wrap things in Integer calls david On Aug 20, 2007, at 7:24 PM, William Stein wrote: Hi, I want to create a SAGE lite version of SAGE. This is inspired by the following: * OLPC * Porting SAGE to run on certain architectures is very hard * Changing SAGE so it installs into a system-wide Python is hard. * Many people could benefit from the SAGE interfaces (to Gap, Maple, etc.) * It would be trivial (technically) to get SAGE lite into debian/ ubuntu. The question is what should go in SAGE lite. Thoughts? I think the key constraints should be: 1. SAGE lite is pure Python 2. Dependence on twisted and pexpect 2.0 is fine. The key thing is that SAGE lite must be 100% pure Python, so it can install on anything, even a little handheld, as long as Python-2.5 is fully available on that computer. What I envision being in SAGE lite is at least the following: * The SAGE notebook * DSage * The SAGE interfaces (to Gap, Maxima, Maple, Magma, etc.) and maybe: * Maybe SAGE's current Calculus package which will work only if the user has a maxima on their system. * Sympy -- though it could be distributed separately Thoughts? Basically, the initial point of this is that if somebody wants to use SAGE just to talk with mathematica, or just for the notebook then they can trivially do so. If they need serious math functionality, they have to install something more. In the long run though, with help from Sympy, this could have a feel very much like SAGE, but without all the serious mathematical functionality -- but still enough for some users. -- William Stein Associate Professor of Mathematics University of Washington http://www.williamstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sagelite
On Aug 20, 2007, at 4:53 PM, William Stein wrote:
On 8/20/07, Robert Bradshaw [EMAIL PROTECTED] wrote:
I can't imagine SAGE doing much (as it is now) in pure python--for
example we wouldn't even have Integer.pyx.
Wrong. The notebook is fully functional in pure python, as is DSAGE,
and as is all of the interfaces to Gap, maxima, etc.
I guess I should have said doing much *math* because I agree that
there is tons of non-math functionality that could be very useful to
people.
Even the calculus package
has pyx files, and I would envision it getting more.
Those are *only* to support some syntac suger, e.g., var('...') doing
namespace injection. That unecessary for the calculus package.
OK, that's not much. (I was going off memories of calculus flashing
by during sage -ba) I thought the plan was to eventually implement
some of the stuff in calculus (e.g. for fast construction/evaluation/
subs) but perhaps it is so dominated by maximal calls that it
wouldn't help much. We'll have to see how simpy fits into this too
(though I'm glad to hear it's going well).
The lite makes
it seem like the core is still there, and I don't see how to extract
that.
It depends on what you view as the core. Maybe lite is the wrong
name.
For tons of people out there the notebook and interfaces are the only
parts of SAGE they currently use. Think, e.g., of Fernando Perez
-- he'd
be likely to use something simple-to-install with the interfaces to
Mathematica,
etc., in it. He has no need of our algebraic functionality, since
he uses
scipy for his number crunching needs.
I guess I've always seen the core as a mathematical computation
engine (that includes many other open-source math packages in a
hassle-free way). I think this is a common view (others--correct me
if I'm wrong). SAGE is a lot more than its core, but to me sage-lite !
= everything but the serious mathematics.
Now I understand your goal, I think it's a worthwhile one, but the
name caught me completely off guard.
I think if it does anything mathematical on its own, it will be a
very hard to draw (and understand) line (not to mention maintenance
headache).
I disagree, especially because of the existence of Sympy. A
couple months ago Sympy was not serious functionality wise,
like nzmath, but Sympy is rapidly progressing (partly because Google
gave them a lot of summer of code projects). Sympy is nothing
like nzmath, and in fact I think sympy is going to improve greatly.
I'm still not sure that some math is better than no math. The
line should certainly not be whatever is in pure python as of now.
One problem I see is people trying to use matrices, or even factoring
a number, which can be done via maxima behind the scenes but will be
a very poor representative of what SAGE can really do. Or, at least,
there should be a way to say this is horribly inefficient compared
to the version in full SAGE.
If there is a very clear line, e.g. only calculus+plotting, maybe
that would be OK.
Also, I know the calculus stuff in SAGE very well,
and it's dependence on the rest of SAGE is fairly
minimal, so it would be easy to modify so it doesn't
depend on the serious math library part of SAGE.
It would work on any system with maxima installed.
Would that be ...the right version of maxima installed? ;-)
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: sagelite
On 8/20/07, David Harvey [EMAIL PROTECTED] wrote: My first impression of this idea is mostly negative, but I'm interested to see where this goes. Will SAGElite use the preparser? That would be a problem if Integer (2) appears somewhere, and Integer is not defined. If you want calculus/plotting then presumably you want people to be able to enter x^3 + x + 2, which means they have to enter x**3 + x + 2, unless the preparser is available. So you can either (a) not let people use ^ (b) redefine Integer to be int (c) have a different preparser for SAGElite which doesn't wrap things in Integer calls Probably there wouldn't be a preparser, but in case there were, (b) makes the most sense. The primary audiences are: 1. current python users -- people using python already for something else -- they don't want the preparser, and might very well have no interest in mathematics either. 2. people who want a GUI for Magma, GAP, or some other program. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sagelite
On 8/20/07, Robert Bradshaw [EMAIL PROTECTED] wrote:
Wrong. The notebook is fully functional in pure python, as is DSAGE,
and as is all of the interfaces to Gap, maxima, etc.
I guess I should have said doing much *math* because I agree that
there is tons of non-math functionality that could be very useful to
people.
Maybe instead of sagelite it could be called sage-nonmath. I'm not
sure what a good name is though, so I'm using sagelite for now. The
point though, is that it's a way to get a lot of people to use the non-math
functionality. The secret goal is that it's a way to get lots of
quality developers
to improve the notebook (and interfaces too maybe), who would never ever
touch them otherwise.
Even the calculus package
has pyx files, and I would envision it getting more.
Those are *only* to support some syntac suger, e.g., var('...') doing
namespace injection. That unecessary for the calculus package.
OK, that's not much. (I was going off memories of calculus flashing
by during sage -ba) I thought the plan was to eventually implement
some of the stuff in calculus (e.g. for fast construction/evaluation/
subs) but perhaps it is so dominated by maximal calls that it
wouldn't help much.
Yep. Maxima calls dominate. If SAGE had money, a possible project
would be to eliminate a lot of the depence on maxima. With the current
state of SAGE funding that isn't a good way to spend time.
We'll have to see how simpy fits into this too
(though I'm glad to hear it's going well).
The lite makes
it seem like the core is still there, and I don't see how to extract
that.
It depends on what you view as the core. Maybe lite is the wrong
name.
For tons of people out there the notebook and interfaces are the only
parts of SAGE they currently use. Think, e.g., of Fernando Perez
-- he'd
be likely to use something simple-to-install with the interfaces to
Mathematica,
etc., in it. He has no need of our algebraic functionality, since
he uses
scipy for his number crunching needs.
I guess I've always seen the core as a mathematical computation
engine (that includes many other open-source math packages in a
hassle-free way). I think this is a common view (others--correct me
if I'm wrong). SAGE is a lot more than its core, but to me sage-lite !
= everything but the serious mathematics.
Now I understand your goal, I think it's a worthwhile one, but the
name caught me completely off guard.
Basically the idea is to make the parts of SAGE that are not number crunching
math available to a *lot* more people, e.g., the millions that use Python
I think if it does anything mathematical on its own, it will be a
very hard to draw (and understand) line (not to mention maintenance
headache).
I disagree, especially because of the existence of Sympy. A
couple months ago Sympy was not serious functionality wise,
like nzmath, but Sympy is rapidly progressing (partly because Google
gave them a lot of summer of code projects). Sympy is nothing
like nzmath, and in fact I think sympy is going to improve greatly.
I'm still not sure that some math is better than no math. The
line should certainly not be whatever is in pure python as of now.
One problem I see is people trying to use matrices, or even factoring
a number, which can be done via maxima behind the scenes but will be
a very poor representative of what SAGE can really do. Or, at least,
there should be a way to say this is horribly inefficient compared
to the version in full SAGE.
If there is a very clear line, e.g. only calculus+plotting, maybe
that would be OK.
Also, I know the calculus stuff in SAGE very well,
and it's dependence on the rest of SAGE is fairly
minimal, so it would be easy to modify so it doesn't
depend on the serious math library part of SAGE.
It would work on any system with maxima installed.
Would that be ...the right version of maxima installed? ;-)
Of course :-)
William
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: sagelite
I sort of think that SAGE lite and Knoboo would be useless for OLPC because there is already an unified software interface called Sugar and a wiki environment based around Media Wiki for the project. I don't see any point in using a whole new interface inside Sugar just to do math that would be similar to the wiki system used. I would find it annoying as say a elementary school teacher if I used two wikis for my class, one for math and one for everything else. It appears that for applications the idea is to make small applications for certain tasks. See the software ideas for math at http://wiki.laptop.org/go/Software_ideas#Mathematics By being modular like this an OLPC laptop can easily be shipped with just the applications that are needed by the laptop's user. I think what OLPC needs for math is small applications that each focus some small part of math education such as a calculators of various complexity including ones that show the steps for solving/computing something. I think I would personally like this if I was in say in an accounting class and had my wiki page up with my assignment and had my speadsheet app in a small window with my calculator in another and was able to move both around as needed to easily look at my data, make calculations, and record them. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: next bug squash?
2007/8/20, mabshoff [EMAIL PROTECTED]: Yeah, I think that sympow uses extended precision for doubles. I never ran properly on Cygwin on x86 cpus, so I am somewhat worried on getting this to run properly on Sparc without some freaky gcc flags or some sparc assembly. I don't think it is high on Willam's priority list because it seems to be rather specialized, This is another linux-ism (x86-specific to boot). I would not worry about it. I can't imagine that this would be so important that it needs extended precision. Otherwise, sympow would be useless on anything not linux and not x86. 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: next bug squash?
2007/8/20, didier deshommes [EMAIL PROTECTED]: Updated spkg for sympow here: http://sage.math.washington.edu/home/dfdeshom/sympow-1.018.1.p2.spkg didier 2007/8/20, mabshoff [EMAIL PROTECTED]: Yeah, I think that sympow uses extended precision for doubles. I never ran properly on Cygwin on x86 cpus, so I am somewhat worried on getting this to run properly on Sparc without some freaky gcc flags or some sparc assembly. I don't think it is high on Willam's priority list because it seems to be rather specialized, This is another linux-ism (x86-specific to boot). I would not worry about it. I can't imagine that this would be so important that it needs extended precision. Otherwise, sympow would be useless on anything not linux and not x86. 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sagelite
On 8/20/07, William Stein [EMAIL PROTECTED] wrote: I want to create a SAGE lite version of SAGE. This is inspired by the following: * OLPC * Porting SAGE to run on certain architectures is very hard * Changing SAGE so it installs into a system-wide Python is hard. * Many people could benefit from the SAGE interfaces (to Gap, Maple, etc.) * It would be trivial (technically) to get SAGE lite into debian/ubuntu. ... Thoughts? Basically, the initial point of this is that if somebody wants to use SAGE just to talk with mathematica, or just for the notebook then they can trivially do so. ... Since Axiom currently has no worksheet-style interface of it's own your proposal for SageLite is extremely interesting to me as an Axiom developer and user. Being able to offer Axiom users an attractive notebook front-end would be worth a lot to them - even better that the same interface can be used in a number of other systems. From this point of view SageLIte be considers as a kind of browser-based TeXmacs system. I also believe (as you implied in an email later in this thread) that making it easy for users to install this lite version of Sage for purposes that are of immediate interest to them - even if those interests do not currently include the computational features of Sage itself - in the long run could be highly beneficial to Sage since SageLite might be a very good way to make a positive first impression on an entirely new class of potential Sage users. Regards, Bill Page. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Fwd: [sage-devel] Re: next bug squash?
Mark (cc: sage-devel) Do you have any comments on the remarks below about sympow? In particular, Otherwise, sympow would be useless on anything not linux and not x86. Given that you only use x86, and are perhaps the main user of sympow... ? -- Forwarded message -- From: didier deshommes [EMAIL PROTECTED] Date: Aug 20, 2007 8:43 PM Subject: [sage-devel] Re: next bug squash? To: sage-devel@googlegroups.com 2007/8/20, mabshoff [EMAIL PROTECTED]: Yeah, I think that sympow uses extended precision for doubles. I never ran properly on Cygwin on x86 cpus, so I am somewhat worried on getting this to run properly on Sparc without some freaky gcc flags or some sparc assembly. I don't think it is high on Willam's priority list because it seems to be rather specialized, This is another linux-ism (x86-specific to boot). I would not worry about it. I can't imagine that this would be so important that it needs extended precision. Otherwise, sympow would be useless on anything not linux and not x86. didier -- William Stein Associate Professor of Mathematics University of Washington http://www.williamstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
