[sage-devel] Re: google search for sage
On 4/25/07, William Stein [EMAIL PROTECTED] wrote: Hi, I've been doing a google search for sage every once in a while for about 2 years now. Slowly but surely sage got on the second page about a year ago. Then it battled it out with Senior Action in a Gay Environment to move up the second page. As of today, at You chose a very common name. We only had to fight with a name of a dog and several nicknames. ;) least in the United States, a Google search for sage has (our) SAGE on the front page (at the bottom).This is some measure of importance. I usualy search sage math, that works fine. Ondrej --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Number field sieve
On 4/24/07, Michel [EMAIL PROTECTED] wrote: A while ago on this list it was asked if there were open source implementations of the GNFS for possible inclusion into sage. I came accros these links http://www.math.ttu.edu/~cmonico/software/ggnfs/ https://sourceforge.net/projects/factor-by-gnfs/ I have not tested them. The first one listed above is GPL'd and looks better than the second. I've added a trac ticket/page about NFS here: http://www.sagemath.org:9002/sage_trac/ticket/356 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sage-2.5.alpha0
On 4/25/07, mabshoff [EMAIL PROTECTED] wrote: For a while we didn't support cygwin and only distributed SAGE using colinux and/or vmware. But colinux isn't really that good for various reasons (though performance wasn't bad), and vmware can be painful as well -- the download for sage in vmware is huge (500MB), and setting up appropriate networking between vmware and windows to run the notebook very often doesn't just work. Overall Cygwin seems to be the best tradeoff. If I had way way more resources I would investigate other options. I think that it might be worth investigating to compile sage and its libraries with MSVC and run all the external executables with cygwin for the time being. pyrex seems to support msvc 2003 and up, so there is a chance I guess. Is it even possible to create a pseudo-tty interface to a cygwin program from the MSVC compiled version of Python? The pexpect website says: Pexpect does not currently work on the standard Windows Python (see the pty requirement); however, it seems to work fine using Cygwin. It is possible to build something like a pty for Windows, but it would have to use a different technique that I am still investigating. I know it's possible because Libes' Expect was ported to Windows. If you have any ideas or skills to contribute in this area then I would really appreciate some tips on how to approach this problem. Providing excellent support for Windows is of course a high priority because MS Windows is by far the most popular operating system. But it's challenging because SAGE is a collection of dozens open source math software programs, and most of those programs are Windows unfriendly (their developers mostly use Linux). Fortunately Python, which is the core of SAGE, is pretty Windows friendly. Yep. The main issue I see on the horizon is cygwin's 32 bit limit. A lot of systems today (even laptops) get sold with 2G+ Ram and the way it looks cygwin will not support 64 bit binaries anytime soon now. Obviouly that doesn't hurt the casual user, but I routinely compute GBases that need 8GB+ (not on Windows, though). I always thought that most serious computer algebra people would use Linux/Unix or nowadays even MacOSX, but there is a frightening number of people out there who only like and use Windows or are forced to use it. Virtualisation will help in the future, but as you stated the technical issues of networking are somewhat of an issue, while the performance penalty will be lessened by better hardware virtualisation in the future. Such a user would likely get actually better overall performance with VMware (which supports 64-bit computing) and Linux running in it than with any sort of native windows solution. The other option for windows is to push much harder the idea of a VMware virtual machine for SAGE, which fortunately isn't so bad of an idea since at least vmware player is free. And I think windows users can't complain about running SAGE via a closed source virtualizer, given that they are running everything via a closed-source operating system. My impression though is that for certain types of work cygwin is best and for others vmware is, so one should support both. 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: sage-2.5.alpha0
On Apr 25, 4:43 pm, William Stein [EMAIL PROTECTED] wrote: Is it even possible to create a pseudo-tty interface to a cygwin program from the MSVC compiled version of Python? The pexpect website says: Pexpect does not currently work on the standard Windows Python (see the pty requirement); however, it seems to work fine using Cygwin. It is possible to build something like a pty for Windows, but it would have to use a different technique that I am still investigating. I know it's possible because Libes' Expect was ported to Windows. If you have any ideas or skills to contribute in this area then I would really appreciate some tips on how to approach this problem. Ok, this is a problem. But there is a module called altpty (see http://cheeseshop.python.org/pypi/altpty/1.0/ ) which might be useful if it is possible to use it as a drop in replacement for the pty interface used in pexpect. It should work under windows, but the build system is automake based. Still, it should be easy to write an nmake file for MSVC because we need to compile 4 C files. I am no expert on python, so feel free to correct me. Another possible tactic might be to compile a certain subset of external programs like mwrank with MSVC (provided that its dependencies can also be build with MSVC) and use that via cygwin's path, i.e. /cygdrive/c/sage-2.5.0/local/bin/mwrank.exe. There was something similar discussed a while ago when somebody had problems invoking Maple under cygwin. This is mostly spitballing at the moment, but one has to start somewhere and cygwin does have some rather unpleasant surprises - a while back on another project I ran into lots of problems with threads and sockets :(. Such a user would likely get actually better overall performance with VMware (which supports 64-bit computing) and Linux running in it than with any sort of native windows solution. On performance I am rather sceptical. The current penalty for virtulisation with hardware VT is about 30-40%. That will become less of an issue in the future as the implementation will get more efficient. The MSVC 2005 compiler also produces code nearly on par with Intel's C C++ for SPECXX, so it is certainly more efficient than gcc/g++. You will also be surprised how quick Microsoft's C++ compiler is compared to g++ and the Intel c++. Most people only remember VS 6, which was a real piece of shit (pardon my french). I am no Microsoft fanboy by any mean, but using MSVC 2005/g++/Intel C++/Sun Forte C++ and IBM's XL on a weekly basis (and some of them daily) for regression and build testing for CoCoALib I can only state: MSVC 2005 is quite pleasant to use and very close to the standard, compiles very quickly and produces fast executables. Development on Windows is just different compared to Linux/Unix and MacOSX. That MS Windows is not 100% POSIX compatible is a sad thing, I am getting OT here, so I will shut up now. VMWare and friends still leave the problem with networking and configuration in general and if you want to do the heavy lifting chances are you will be using non-Windows anyway :). But the fact that the threadlist_ix -1 issues or the test failures with Maxima for sage 2.4.2 hasn't been reported until recently means that there are either few cygwin users of sage or that people don't complain about bugs. It would be nice to see how many sage users there are and which operations systems they use. The other option for windows is to push much harder the idea of a VMware virtual machine for SAGE, which fortunately isn't so bad of an idea since at least vmware player is free. I agree. And I think windows users can't complain about running SAGE via a closed source virtualizer, given that they are running everything via a closed-source operating system. My impression though is that for certain types of work cygwin is best and for others vmware is, so one should support both. Something else worth investigating ist SFU, i.e Services for Unix from Microsoft. It contains a gcc toolchain, gnu utils and some other bits and pieces needed to compile unixy code without changes. The problem is that last time I looked the redistribution of the needed runtime bits was unclear and it also requires a passport account to get. In addition it isn't exactly small, either. William Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: dsage stats
The web user should also be able to change the format of time stamps. Creation time should not have underscore and same with monitor_id. For completed job there should be a time stamp for how long the job took. On 4/25/07, Timothy Clemans [EMAIL PROTECTED] wrote: I like it a lot. A lot of job ids are repeated. It says 449 jobs but I don't see nearly that many. You need an HTML title. I don't have access to sage.math so I can't start jobs. There should be say a WebSAGE server that this app would be apart of and admin(s) chose whether or not to enable it, the notebook, and wiki. On 4/25/07, alex clemesha [EMAIL PROTECTED] wrote: Hi all, I've been working on making a web interface to dsage, check it out: http://sage.math.washington.edu:/ made with Twisted, MochiKit and sqlite. Couple of notes: This is an Ajax app, I've only viewed it in Firefox, but I will support FF, IE6 and IE7, Safari, Opera (via the excellent js library MochiKit, http://mochikit.com ) 'SELECT STATUS OF TYPE' is not turned on yet, would that be a good addition? there could be efficiency issues with very large dynamically changing stats in browsers, right now the view is basically: jobs_you_are_seeing = [random.choice(query_result) for _ in range(20)] One feature I will be putting in is a 'user console' to manage one's personal jobs, (ie, view stats, starting, stopping, uploading new jobs). I have code that will enable this feature to be *SSL and cookie-based-session enabled* Other thoughts? Other stat views? Feature requests, styling issues? This code is alpha-ish, so be nice ;) Now start some jobs on sage.math and view their status! -Alex p.s. This server was started running this command in the dir /home/agc/dsage_stats on sage.math: $ sage td.py -oy dsage_stats_server.tac to kill the server started in this way type (in the same dir): $ kill -9 `cat twistd.pid` --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe 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: dsage stats
On Apr 25, 2007, at 13:28 , alex clemesha wrote: Hi all, I've been working on making a web interface to dsage, check it out: http://sage.math.washington.edu:/ made with Twisted, MochiKit and sqlite. Really nice! I like the fact that you can see the code that's behind the job. Having said that, might it be a good idea to allow 'locking' of this feature (perhaps with password protection)? I can foresee situations in which this would be useful. Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for the Absorption of Federal Funds Men are from Earth. Women are from Earth. Deal with it. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: dsage stats
A couple more comments: 1) Could you make the job_id column entries links to the specific job? It is a lot easier to click on it than to copy paste it into the box. 2) Could you make the default refresh time to be like 10 seconds or so? 5 seconds feels to short and was disconcerting since it jumped around so much. On Apr 25, 2007, at 1:28 PM, alex clemesha wrote: Hi all, I've been working on making a web interface to dsage, check it out: http://sage.math.washington.edu:/ made with Twisted, MochiKit and sqlite. Couple of notes: This is an Ajax app, I've only viewed it in Firefox, but I will support FF, IE6 and IE7, Safari, Opera (via the excellent js library MochiKit, http://mochikit.com) 'SELECT STATUS OF TYPE' is not turned on yet, would that be a good addition? there could be efficiency issues with very large dynamically changing stats in browsers, right now the view is basically: jobs_you_are_seeing = [random.choice(query_result) for _ in range(20)] One feature I will be putting in is a 'user console' to manage one's personal jobs, (ie, view stats, starting, stopping, uploading new jobs). I have code that will enable this feature to be *SSL and cookie-based-session enabled* Other thoughts? Other stat views? Feature requests, styling issues? This code is alpha-ish, so be nice ;) Now start some jobs on sage.math and view their status! -Alex p.s. This server was started running this command in the dir /home/agc/dsage_stats on sage.math: $ sage td.py -oy dsage_stats_server.tac to kill the server started in this way type (in the same dir): $ kill -9 `cat twistd.pid` Cheers, Yi -- http://www.yiqiang.net --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe 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: dsage stats
On Apr 25, 2007, at 18:18 , Yi Qiang wrote: On Apr 25, 2007, at 4:49 PM, Justin C. Walker wrote: On Apr 25, 2007, at 13:28 , alex clemesha wrote: Hi all, I've been working on making a web interface to dsage, check it out: http://sage.math.washington.edu:/ made with Twisted, MochiKit and sqlite. Really nice! I like the fact that you can see the code that's behind the job. Having said that, might it be a good idea to allow 'locking' of this feature (perhaps with password protection)? I can foresee situations in which this would be useful. I think a easy solution would be to be able to have 'private' jobs. I.E. the job_id column would just show 'PRIVATE'. If you knew the job id you can just put it into the the search box alex already made. That was the reason job ids were random to begin with anyways. What do you think of this solution? At first glance, it seems like a good idea. I really don't know how important it is to have 'private' jobs, though. If it is *really* important, then having *really* random job IDs would be equally important :-}. 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. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe 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: dsage stats
On Apr 25, 2007, at 6:18 PM, Yi Qiang wrote: On Apr 25, 2007, at 4:49 PM, Justin C. Walker wrote: On Apr 25, 2007, at 13:28 , alex clemesha wrote: Having said that, might it be a good idea to allow 'locking' of this feature (perhaps with password protection)? I can foresee situations in which this would be useful. I think a easy solution would be to be able to have 'private' jobs. I.E. the job_id column would just show 'PRIVATE'. If you knew the job id you can just put it into the the search box alex already made. That was the reason job ids were random to begin with anyways. What do you think of this solution? First, let me say that this dsage job page is pretty cool. About the random job ids, sounds like security through obscurity to me. There's already the concept of job ownership, and levels of trust controlling who can submit/process a job, so I think (long term at least) that infrastructure could be used to control viewing (or even showing up in the list). --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe 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: dsage stats
On Wed, 25 Apr 2007, Robert Bradshaw wrote: On Apr 25, 2007, at 6:18 PM, Yi Qiang wrote: On Apr 25, 2007, at 4:49 PM, Justin C. Walker wrote: On Apr 25, 2007, at 13:28 , alex clemesha wrote: Having said that, might it be a good idea to allow 'locking' of this feature (perhaps with password protection)? I can foresee situations in which this would be useful. I think a easy solution would be to be able to have 'private' jobs. I.E. the job_id column would just show 'PRIVATE'. If you knew the job id you can just put it into the the search box alex already made. That was the reason job ids were random to begin with anyways. What do you think of this solution? First, let me say that this dsage job page is pretty cool. About the random job ids, sounds like security through obscurity to me. There's already the concept of job ownership, and levels of trust controlling who can submit/process a job, so I think (long term at least) that infrastructure could be used to control viewing (or even showing up in the list). Gonna have to second that. If you have a web-based interface that takes as input an id #, a BASH one-liner can get all your data in a very short amount of time. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe 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] Python Access Control module?
Does anybody know of some sort of kitchen-sink type of authentication module that's commonly used in python? For the notebook, I've had to write my own, and it stinks -- any time a new feature is added, we forget to lock it down, and it isn't at all robust or configurable. It would seem that Yi is having to write his own, too (granted, it sounds like he's thought about it a lot more than I have). Can anybody suggest a pre-existing package that just works? --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe 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: dsage stats
On Apr 25, 2007, at 19:06 , Robert Bradshaw wrote: On Apr 25, 2007, at 6:18 PM, Yi Qiang wrote: On Apr 25, 2007, at 4:49 PM, Justin C. Walker wrote: On Apr 25, 2007, at 13:28 , alex clemesha wrote: Having said that, might it be a good idea to allow 'locking' of this feature (perhaps with password protection)? I can foresee situations in which this would be useful. [snip] About the random job ids, sounds like security through obscurity to me. There's already the concept of job ownership, and levels of trust controlling who can submit/process a job, so I think (long term at least) that infrastructure could be used to control viewing (or even showing up in the list). Agreed. If that can work simply and intuitively, it's a big improvement over obscurity... 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
