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
Thanks. That is fixed now.
Jason
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
>
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
SyntaxError Traceback (most recent call last) SyntaxError: invalid syntax (<string>, line 57)The line number depends on the length of the code.
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
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
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
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
This is fixed now; if you have time, please test it.
Thanks,
Jason
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
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
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
Backslashes should work now. Can you test it please?
Thanks,
Jason
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
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
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
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
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
I think I've fixed it better now [1]. Can you check it again?
Thanks,
Jason
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
Missing reference [1]:
https://github.com/jasongrout/simple-python-db-compute/commit/c90fc0d8d3cecab9ec2062d8261aa9d8c3ef3656