[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] 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/ -~--~~~~--~~--~--~---
