public single cell server
Jason Grout
I'd like to announce a trial beta run of a public single cell server:
The idea is that this is a single cell that can very easily be embedded
in any webpage. This is the start of a comprehensive Sage web service
as well, and lays a piece of the ground work for a much more scalable
model for doing computations in the normal notebook.
It's ready to be hammered by the larger community at this point. I will
be mentioning this next week at Mathfest, so please try to break it :).
I think just about any normal Sage computation should work. Please
report any errors to me.
We've also rewritten interacts, so please especially test interacts.
There are some exciting new features for interacts in this rewrite that
I can detail later. The main focus for this testing is that current
existing interacts should work unchanged, hopefully.
Thanks especially to Ira Hanson and Alex Kramer for doing much of the
design and implementation work (funded by Drake University and the NSF),
to William for an early version, and Fernando Perez and Robert Bradshaw
for many helpful conversations. I'm sure there are people I've missed
who have contributed in some way; please let me know if I've missed someone!
The repository for the code is:
https://github.com/jasongrout/simple-python-db-compute. The
instructions are not quite up to date, but I'll be working on those soon.
Thanks,
Jason
--
Jason Grout
P Purkayastha
Jason Grout
Thanks. That is fixed now.
Jason
John Cremona
visible? After a few evaluations I could no longer see the output
without scrolling down.
This looks as if it could be very useful!
John
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to
> sage-devel+...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>
Jason Grout
> Looks nice! Is it necessary to have the "Computation ID" block so
> visible? After a few evaluations I could no longer see the output
> without scrolling down.
No, it's not necessary; thanks for the suggestion. In fact, when
embedding in a page, you can turn on or off any of those things. I just
updated things to move that computation id below the results, though.
Is that better?
Thanks,
Jason
Juanlu001
SyntaxError Traceback (most recent call last) SyntaxError: invalid syntax (<string>, line 57)The line number depends on the length of the code.
leif
It would also be nice to have some indicator showing whether the
computation is still running.
(Usually I would just change the "Evaluate" button, but that is
apparently also used to restart the current computation.)
I wonder if it would make sense to have an [optional?] scroll bar for
the output as well. In that case, I would even put the output box
*above* the input / code box (like pocket calculators, phones and IRC
clients have it ;-) ). But perhaps that's also customizable when
embedding it into a page.
I observed that the output is interspersed with additional blank lines
(one or more in sequence), depending on how fast the server delivers.
-leif
Jason Grout
>
> On 30 Jul., 10:48, Jason Grout<jason-s...@creativetrax.com> wrote:
>> On 7/30/11 1:35 AM, John Cremona wrote:
>>
>>> Looks nice! Is it necessary to have the "Computation ID" block so
>>> visible? After a few evaluations I could no longer see the output
>>> without scrolling down.
>>
>> No, it's not necessary; thanks for the suggestion. In fact, when
>> embedding in a page, you can turn on or off any of those things. I just
>> updated things to move that computation id below the results, though.
>> Is that better?
>
> Yep, to me it is.
>
> It would also be nice to have some indicator showing whether the
> computation is still running.
This is https://github.com/jasongrout/simple-python-db-compute/issues/161
>
> (Usually I would just change the "Evaluate" button, but that is
> apparently also used to restart the current computation.)
>
> I wonder if it would make sense to have an [optional?] scroll bar for
> the output as well. In that case, I would even put the output box
> *above* the input / code box (like pocket calculators, phones and IRC
> clients have it ;-) ). But perhaps that's also customizable when
> embedding it into a page.
Yep; all of this is customizable when embedding into a page. Just set
the sizes, positions, and CSS however you want.
>
>
> I observed that the output is interspersed with additional blank lines
> (one or more in sequence), depending on how fast the server delivers.
>
This is now
https://github.com/jasongrout/simple-python-db-compute/issues/174
Thanks,
Jason
John Travis
A real minor problem I found was with labels in interact. No latex
for such as
def _( x0 = input_box(0,width=5,label='$x_0$'), blah
Also, %hide does not work but it would be nice to have the option when
shelling out from something like WebWork. Indeed, when using
interacts, it might be nice to be able to turn off everything else
other than the interactive output window and an evaluate button.
Maybe the addition of %hide command in this context would turn off the
code box (other than some small way to get it back), "Upload files",
and all but the latest session.
JT
On Jul 30, 5:34 am, Jason Grout <jason-s...@creativetrax.com> wrote:
> On 7/30/11 3:25 AM, leif wrote:
>
>
>
>
>
>
>
>
>
>
>
> > On 30 Jul., 10:48, Jason Grout<jason-s...@creativetrax.com> wrote:
> >> On 7/30/11 1:35 AM, John Cremona wrote:
>
> >>> Looks nice! Is it necessary to have the "Computation ID" block so
> >>> visible? After a few evaluations I could no longer see the output
> >>> without scrolling down.
>
> >> No, it's not necessary; thanks for the suggestion. In fact, when
> >> embedding in a page, you can turn on or off any of those things. I just
> >> updated things to move that computation id below the results, though.
> >> Is that better?
>
> > Yep, to me it is.
>
> > It would also be nice to have some indicator showing whether the
> > computation is still running.
>
Benjamin Jones
<jason...@creativetrax.com> wrote:
> Hi everyone,
>
> I'd like to announce a trial beta run of a public single cell server:
>
> http://sagemath.org:5467/
>
> The idea is that this is a single cell that can very easily be embedded in
> any webpage. This is the start of a comprehensive Sage web service as well,
> and lays a piece of the ground work for a much more scalable model for doing
> computations in the normal notebook.
>
> It's ready to be hammered by the larger community at this point. I will be
> mentioning this next week at Mathfest, so please try to break it :). I
> think just about any normal Sage computation should work. Please report any
> errors to me.
>
> We've also rewritten interacts, so please especially test interacts. There
> are some exciting new features for interacts in this rewrite that I can
> detail later. The main focus for this testing is that current existing
> interacts should work unchanged, hopefully.
>
This is fantastic. I've been thinking about potential uses for this
since I watched the recording of your talk about it at the recent Sage
notebook days.
One suggestion, is it possible to make the input text box resizeable
so that the user can see more than 15 lines at a time? I didn't look
into the docs closely so maybe this is already an option.
Thanks!
--
Benjamin Jones
Jason Grout
> Awesome.
>
> A real minor problem I found was with labels in interact. No latex
> for such as
>
> def _( x0 = input_box(0,width=5,label='$x_0$'), blah
I noticed this when testing one of your interacts yesterday and created
an issue for it:
https://github.com/jasongrout/simple-python-db-compute/issues/168
>
> Also, %hide does not work but it would be nice to have the option when
> shelling out from something like WebWork. Indeed, when using
> interacts, it might be nice to be able to turn off everything else
> other than the interactive output window and an evaluate button.
> Maybe the addition of %hide command in this context would turn off the
> code box (other than some small way to get it back), "Upload files",
> and all but the latest session.
You can already include code in the html of the page, which is
automatically picked up when you create the singlecell. I haven't tried
turning off the edit box after you do that (it would be easy to use CSS
to hide the edit box and/or make it non-editable). This is definitely
in the plans to make this work nicely, though. One of the major uses
will be interacts that are seamlessly embedded in webpages (i.e., just
the controls and the output).
Thanks for your testing and suggestions!
Jason
Jason Grout
I experimented with having the edit box auto-grew up to about 30 lines,
but it didn't seem to be quite as nice. It's a single-line change to
the CSS to make it autogrow (with upper and lower limits).
Would you suggest making the box auto-grow? How many lines do you think
it should have at minimum or maximum?
Thanks,
Jason
Kelvin Li
Out of laziness/incompetence to do any deeper investigation, I will
list my complaints in no particular order. :-)
The syntax highlighting is really cool, but when there is a lot of
text, scrolling through it with the arrow keys can be slow/jerky (at
least in my browser: Firefox 5.0 on Linux).
It looks like the 3D plotters "jmol" and "tachyon" work (but I don't
have a java plugin to know for sure), but "canvas3d" does not. It
gives me a link to a file that I can download (??). It works on
sagenb.org -- which hopefully rules out my browser as the issue.
For interacts, looks like "input_grid" and "color_selector" widgets
have problems. To reproduce:
@interact
def f(a = input_grid(nrows=0, ncols=0)):
pass
(throws a syntax error about an internal file)
@interact
def f(a = color_selector()):
print a
(widget mis-renders in my browser. I took screenshots, but I don't
know where to upload the images.)
The other interact widgets I tested all work.
Note that all of the above results were correct as of last night. For
some reason, none of the interacts or plots is working for me this
morning.
Anyways, that was my attempt at hammering it. :-)
Kelvin
Jason Grout
> for such as
>
> def _( x0 = input_box(0,width=5,label='$x_0$'), blah
This is fixed now; if you have time, please test it.
Thanks,
Jason
Jason Grout
> Wow, this is really neat!
>
> Out of laziness/incompetence to do any deeper investigation, I will
> list my complaints in no particular order. :-)
>
> The syntax highlighting is really cool, but when there is a lot of
> text, scrolling through it with the arrow keys can be slow/jerky (at
> least in my browser: Firefox 5.0 on Linux).
>
Soon I will make it so that you can just have a non-colored plain text
box, or toggle between the fancy and non-fancy editors.
> It looks like the 3D plotters "jmol" and "tachyon" work (but I don't
> have a java plugin to know for sure), but "canvas3d" does not. It
> gives me a link to a file that I can download (??). It works on
> sagenb.org -- which hopefully rules out my browser as the issue.
This is now being tracked at
https://github.com/jasongrout/simple-python-db-compute/issues/178.
>
> For interacts, looks like "input_grid" and "color_selector" widgets
> have problems. To reproduce:
>
> @interact
> def f(a = input_grid(nrows=0, ncols=0)):
> pass
>
> (throws a syntax error about an internal file)
This is now fixed. Can you test it please?
>
> @interact
> def f(a = color_selector()):
> print a
>
> (widget mis-renders in my browser. I took screenshots, but I don't
> know where to upload the images.)
This is now fixed. Can you test it please?
>
> The other interact widgets I tested all work.
Great!
>
> Note that all of the above results were correct as of last night. For
> some reason, none of the interacts or plots is working for me this
> morning.
That's interesting that they worked last night---they shouldn't have.
Maybe you had some things loaded in cache from a while ago, but your
cache has been cleared since then...
>
> Anyways, that was my attempt at hammering it. :-)
Thanks!
Jason
Kelvin Li
> Soon I will make it so that you can just have a non-colored plain text
> box, or toggle between the fancy and non-fancy editors.
> > For interacts, looks like "input_grid" and "color_selector" widgets
> > have problems. To reproduce:
>
> > @interact
> > def f(a = input_grid(nrows=0, ncols=0)):
> > pass
>
> > (throws a syntax error about an internal file)
>
> This is now fixed. Can you test it please?
@interact
def f(a = input_grid(nrows=1, ncols=2, to_value=lambda t:3)):
pass
(throws an error that looks very similar to the previous one)
> > @interact
> > def f(a = color_selector()):
> > print a
>
> > (widget mis-renders in my browser. I took screenshots, but I don't
> > know where to upload the images.)
>
> This is now fixed. Can you test it please?
> > Note that all of the above results were correct as of last night. For
> > some reason, none of the interacts or plots is working for me this
> > morning.
>
> That's interesting that they worked last night---they shouldn't have.
> Maybe you had some things loaded in cache from a while ago, but your
> cache has been cleared since then...
and that was my first time using the single cell server. Would there
be things left over in the cache? And for some magical reason, what
seemed broken this morning all works again this afternoon. :-)
Here are some more things I found (which might already be known
issues):
-- The "function?" help notation does not work. Using "help(function)"
returns raw HTML code in the cell along with an attached file that
does contain the docstring of "function".
-- Entering "graph_editor()" returns the text "Not Found / The
requested URL was not found on the server. / If you entered the URL
manually please check your spelling and try again" and the "save" and
"close" buttons of the non-functioning graph editor.
Kelvin
John Travis
out the spacing issue on the label rho(x,y,z) for
@interact(layout=dict(top=[['rho','a1']]))
def _(
a1 = input_box(2,label='$a_1$'),
rho=input_box(x,label='$\\rho(x,y,z)$',width=8)):
print "hello"
JT
Jason Grout
> On Jul 30, 5:25 pm, Jason Grout<jason-s...@creativetrax.com> wrote:
>
>> Soon I will make it so that you can just have a non-colored plain text
>> box, or toggle between the fancy and non-fancy editors.
>
> That would be cool!
>
>>> For interacts, looks like "input_grid" and "color_selector" widgets
>>> have problems. To reproduce:
>>
>>> @interact
>>> def f(a = input_grid(nrows=0, ncols=0)):
>>> pass
>>
>>> (throws a syntax error about an internal file)
>>
>> This is now fixed. Can you test it please?
>
> Sorry, I broke it again:
>
> @interact
> def f(a = input_grid(nrows=1, ncols=2, to_value=lambda t:3)):
> pass
>
> (throws an error that looks very similar to the previous one)
Yep, it should be the same error. Okay, I will have to fix this a
little more robustly. I think I know what to do. This is tracked here:
https://github.com/jasongrout/simple-python-db-compute/issues/179
>
> Here are some more things I found (which might already be known
> issues):
>
> -- The "function?" help notation does not work. Using "help(function)"
> returns raw HTML code in the cell along with an attached file that
> does contain the docstring of "function".
>
> -- Entering "graph_editor()" returns the text "Not Found / The
> requested URL was not found on the server. / If you entered the URL
> manually please check your spelling and try again" and the "save" and
> "close" buttons of the non-functioning graph editor.
Both of these are known issues and not considered show-stoppers for now.
Thanks for reporting these. The graph editor depends heavily on
hacking and kludges dealing with the current notebook, so it will need
to have some major changes to work. One reason I didn't pay too much
attention to the graph editor or the help is that these single-cell
instances are concentrating on a single execution and result. The graph
editor just builds a graph, but then you wouldn't be able to do anything
with it. Likewise, the help will return something, but then you'll need
to execute something again in order to do something with it. Both of
those sorts of computations lend themselves more towards a notebook with
multiple cells, rather than a single-cell system.
That said, we'll eventually get this working, since hopefully we can use
code and what we've learned here to make the current notebook better.
Thanks,
Jason
Jason Grout
> Great. I'm having to look harder for problems so that's good. Check
> out the spacing issue on the label rho(x,y,z) for
>
> @interact(layout=dict(top=[['rho','a1']]))
> def _(
> a1 = input_box(2,label='$a_1$'),
> rho=input_box(x,label='$\\rho(x,y,z)$',width=8)):
> print "hello"
What do you see as the problem with the output? I can see that the two
textboxes are a little close together (i.e., the $a_1$ is too close to
the end of the $\rho$ textbox). Is that what you mean?
Thanks,
Jason
Jason Grout
> I have tested multiple interacts of mine and some computations, and
> everything seems to work quite well except for the backslash \, which I
> tried to use to split lines. It gives a syntax error:
>
> SyntaxError Traceback (most recent call last)
> SyntaxError: invalid syntax (<string>, line 57)
Backslashes should work now. Can you test it please?
Thanks,
Jason
Juanlu001
Rob Beezer
I've tried to "hide" some of the diagnostic information, and style a
few of the remaining elements. I've done this with my own crude CSS
stylesheet and via the arguments to the singlecell creation function.
Some questions and observations.
1. Starting from the current HTML page being served from
sagemath.org, where would one add the reference to a "custom" CSS
file? I have this mostly working right, but probably not correctly.
In particular, setting many of the output parts to not display has
totally broken interacts, so in that sense what I have done is
definitely not correct.
2. Using arguments to the singlecell creation function to turn-off
the messages (three values set to false) seems to also break
interacts.
3. The default value of "outputDiv" listed in the documentation for
the dictionary of options to the single cell creation caused an error
for me, but a value of "#singlecell" does seem to work.
4. Maybe the singlecell_completion div can be not-displayed when
"messages" is false?
5. I was able to put two apparently independent single-cells on the
same page by running singlecell.makeSinglecell(alternate_config)
where alternate_config specified a different id for a second div
used to locate the cell. Maybe not news, but I did not see this
documented anywhere. In particular I was just guessing about how to
properly invoke the singlecell creation function.
6. Minor nit: CodeMirror does not handle the "F.<a> = GF(3^2)"
syntax properly.
7. Do interacts time-out after some period of inactivity? It seems
so.
Rob
Rob Beezer
> Some questions and observations.
Knew I was forgetting something.
8. Is there a way to "pre-load" the CodeMirror text area? Or more
precisely, what could I place into the HTML that would take some code
and load up the text area with the code as its content? Maybe this
should be an argument to the singlecell creation function?
Incidentally increasing list traffic,
Rob
Jason Grout
> Kudos to Jason and the students at Drake. This is very nice.
Thanks! And thanks again for testing!
>
> I've tried to "hide" some of the diagnostic information, and style a
> few of the remaining elements. I've done this with my own crude CSS
> stylesheet and via the arguments to the singlecell creation function.
Disclaimer: I haven't tested hiding elements very extensively. I
wouldn't be surprised if there was a bug or two in doing this.
> Some questions and observations.
>
> 1. Starting from the current HTML page being served from
> sagemath.org, where would one add the reference to a "custom" CSS
> file? I have this mostly working right, but probably not correctly.
> In particular, setting many of the output parts to not display has
> totally broken interacts, so in that sense what I have done is
> definitely not correct.
You should be able to add a CSS link statement at the end of the head or
the start of the body. We dynamically add CSS to the end of the head in
the embedded_singlecell.js, so there might be problems with us
overwriting your CSS rules if you have them in the head element. So
maybe try putting them at the top of the body element?
Can you post your current working/nonworking version so I can test it too?
>
> 2. Using arguments to the singlecell creation function to turn-off
> the messages (three values set to false) seems to also break
> interacts.
Can you post your current file so I can test it too?
>
> 3. The default value of "outputDiv" listed in the documentation for
> the dictionary of options to the single cell creation caused an error
> for me, but a value of "#singlecell" does seem to work.
>
Thanks; I'll take a look. The documentation likely needs to be updated.
> 4. Maybe the singlecell_completion div can be not-displayed when
> "messages" is false?
At one point, Ira implemented tab-completion, but I don't think that's
turned on now (I think we may have broken it with some extensive changes
after he implemented it). I don't think singlecell_completion serves
any purpose right now and can be removed.
>
> 5. I was able to put two apparently independent single-cells on the
> same page by running singlecell.makeSinglecell(alternate_config)
> where alternate_config specified a different id for a second div
> used to locate the cell. Maybe not news, but I did not see this
> documented anywhere. In particular I was just guessing about how to
> properly invoke the singlecell creation function.
Yes, we planned to support multiple single cells on a page, so I'm glad
it's working.
>
> 6. Minor nit: CodeMirror does not handle the "F.<a> = GF(3^2)"
> syntax properly.
Thanks for the reminder. We had to custom-hack the codemirror in Sage
to support that. I'll look at porting that hack over to codemirror2 and
the singlecell.
>
> 7. Do interacts time-out after some period of inactivity? It seems
> so.
Yes. I think 60 seconds is the timeout we currently have set up.
Computations are allowed 100 seconds of CPU time too, so that could also
cause a computation/interact to time out.
Thanks,
Jason
Jason Grout
Yes. Anything in that div should show up in the Codemirror box. In
order to get plain code, I'd suggest doing what mathjax does to wrap
code (put it in a script tag):
<div id="my_singlecell">
<script type="text/python-code">
print 'hi'
print 'even < works!'
</script>
</div>
I believe making "#my_singlecell" a singlecell will then put those two
lines in the singlecell div. I may have to turn off the current
behavior of saving what was in the singlecell div and restoring it on
refresh.
Thanks,
Jason
Ondřej Čertík
<jason...@creativetrax.com> wrote:
> On 7/29/11 5:11 PM, Jason Grout wrote:
>>
>> Hi everyone,
>>
>> I'd like to announce a trial beta run of a public single cell server:
>>
>> http://sagemath.org:5467/
>>
>> The idea is that this is a single cell that can very easily be embedded
>> in any webpage. This is the start of a comprehensive Sage web service as
>> well, and lays a piece of the ground work for a much more scalable model
>> for doing computations in the normal notebook.
>>
>> It's ready to be hammered by the larger community at this point. I will
>> be mentioning this next week at Mathfest, so please try to break it :).
>
>
>
> http://sage.math.washington.edu/home/jason/commands.html
>
> Of particular note are the commands around 2011-07-31 03:03:07.436000
> (search for that string), where someone is apparently testing the security
> of the setup. Whoever did it, how did the security and infinite loop tests
> go?
I would be interested in that too. How do you handle such infinite
loops on the server? Do you have some limit on the CPU time allowed
per evaluation?
Ondrej
Jason Grout
We setrlimit a CPU time limit (currently 100 seconds) for the process
before we execute the user code. We also set a memory limit of 2500M.
These are passed in the configuration for launching user code, and the
setrlimit happens here:
https://github.com/jasongrout/simple-python-db-compute/blob/master/device_process.py#L518
Jason
Jason Grout
> per evaluation?
The CPU time limit is for all user code evaluated in a single "session",
which for interacts may actually be multiple roundtrips to the server.
Jason
Jason Grout
>
> @interact
> def f(a = input_grid(nrows=1, ncols=2, to_value=lambda t:3)):
> pass
>
> (throws an error that looks very similar to the previous one)
I think I've fixed it better now [1]. Can you check it again?
Thanks,
Jason
Jason Grout
> precisely, what could I place into the HTML that would take some code
> and load up the text area with the code as its content? Maybe this
> should be an argument to the singlecell creation function?
I just made it [1] so that if you put some code in the div before making
it a singlecell, maybe something like:
<div id="singlecell"><script type="text/code">print 'hi'</script></div>
then it won't try to restore the user's last code. However, if the
initial div is empty:
<div id="singlecell"><script type="text/code"></script></div>
then it should try to restore whatever the user last had in the cell.
Thanks,
Jason
Jason Grout
> On 7/31/11 3:05 PM, Rob Beezer wrote:
>> 8. Is there a way to "pre-load" the CodeMirror text area? Or more
>> precisely, what could I place into the HTML that would take some code
>> and load up the text area with the code as its content? Maybe this
>> should be an argument to the singlecell creation function?
>
> I just made it [1] so that if you put some code in the div before making
> it a singlecell, maybe something like:
>
Missing reference [1]:
https://github.com/jasongrout/simple-python-db-compute/commit/c90fc0d8d3cecab9ec2062d8261aa9d8c3ef3656