search

sagemath / cloud

*MOVED TO* https://github.com/sagemathinc/cocalc
https://cocalc.com
Other
137 stars 31 forks source link

dropdown switch for default backend in sagews #34

Open haraldschilly opened 11 years ago

haraldschilly commented 11 years ago

Add a dropdown list of possible backends which can be used for execution. That's much more discoverable than the default_mode and also lists explicitly all available options.

This setting should also be stored in the worksheet.

williamstein commented 11 years ago

I think the dropdown should simply modify the worksheet and insert a 

%default_mode

line, then evaluate it. I want everything in the worksheets to be explicit, unlike sagenb where some settings were hidden, such as typeset_mode, default mode, etc. This is something IPython notebook makes explicit usually, which is a good decision decision.

Where should that line go? The current cell? Or always at the very top? If there is already a default_mode cell somewhere in the worksheet, should it be replaced? Or only if it is at the top?

Note that any cell decorator can be given as input to "default_mode", and even several of them. And any function that takes a string as input could be a cell decorator... so we should probably make a judicious choice of the best supported modes for this. E.g., now R is well supported, due to that graphics work we did before.

Anyway, I want to do something to make this easy, but something that fits into the current explicit approach, and I'm not sure what is best. I am sure -- based on watching confused users very often -- that what I did in sagenb was a really bad design choice.

I almost think that this should be the beginnings of some sort of general menu for inserting useful code snippets, which one might not otherwise know about. We could start small just with something for inserting "%default_mode foo", and grow it from there.

haraldschilly commented 11 years ago

Yes, your point is a good one, I understand, explicit is better than implicit is also true. I think it is necessary to somehow "force" this to be one of the first cell and it feels to me, that this should be treated special. IPython places them on top as regular first cells, and they might also contain some other configurations (e.g. size of plots, fonts, css, ...).

So, after thinking about this for a minute, what about a new type of "configuration" cell, which is such a special one for all kinds of settings? To avoid the turing completeness problem, it's maybe a good idea to contain "data" instead of "code"? The given data structure sets some parameters, which do not even have to exist, and only some of them are known to SMC.

%configuration
default_mode: (sage|R|octave|...)
font_size: 14px
plot:
   figsize: (15,5)

I don't want to imply that all these settings must be implemented right now and must have their corresponding UI setting, but theoretically they could and exist in a globally accessible variable, like salvus.config. When the worksheet is loaded, the first %configuration cell is loaded and the data structure is what ends up in the settings. Any subsequent evaluation of such a %configuration cell would just change the stored settings (and update the UI).

The format is YAML because I like it, but equally well this could be JSON, or .cfg for the ConfigParser in Python. Maybe it would also make sense to include specific configurations for the backends, e.g. some sort of ini file for R or sage, or something like that? Or to break my statement about turing completeness, allow to specify init-lines that are executed like in %auto.

%configuration
default_mode: IPython
init: |
     %pylab inline
     matplotlib.rcParams['figure.figsize'] = (15,5)
     rcParams['savefig.dpi'] = 120

Well, maybe I'm overthinking this :worried:

For your last paragraph, that's #23 in my eyes, and I think that's a bit different because I was thinking about an additional "ui wizard" to discover these functionalities ...

haraldschilly commented 11 years ago

... and yes, the final problem, what do do with UI changes: load the implied settings of the first %configuration cell, change (or add) the new settings of the UI, and save the data. the formatting might change, the underlying information does not (assuming load+dump is ok). maybe it's necessary to disallow any other such cell? i'm not sure if that's possible or necessary.