Differences between revisions 4 and 11 (spanning 7 versions)
Revision 4 as of 2014-05-22 17:01:17
Size: 2289
Editor: tmonteil
Comment:
Revision 11 as of 2014-05-24 12:35:23
Size: 5963
Editor: jason
Comment:
Deletions are marked like this. Additions are marked like this.
Line 15: Line 15:
  * have an option to launch ipynb with Sage preparsing without having to add the {{{%load_ext sage.misc.sage_extension}}} command. (S)   * have an option to launch ipynb with Sage preparsing without having to add the {{{%load_ext sage.misc.sage_extension}}} command. (S) (William: I think they more or less had something like this in 1.x, but removed any potential to do this sort of thing with 2.x, and when users complained refused to change it. So we might have to fork or monkey patch the code slightly.)
Line 18: Line 19:
    * or directly work with what is shiped with ipynb, without adding the @interact layer (which will need to be updated at each ipython improvement) (U)     * or directly work with what is shipped with ipynb, without adding the @interact layer (which will need to be updated at each ipython improvement) (U) (William: but there is a LOT of code out there using @interact.)
    * For what it is worth, I rewrote @interact from scratch for SageMathCloud in 3 days. So it's not a huge amount of work adapting @interact to work with whatever framework.
    * Jason Grout: I helped write the IPython widget framework, and tried to build in enough flexibility so it would be fairly straightforward to get the widgets working in Sage. As a result, the Sage Cell server supports the framework and most of the widgets (though we're missing some of the client-side components some widgets assume, like bootstrap). To support widgets, basically you'd need to write a compatibility layer emulating the lower-level IPython Comm infrastructure providing 2-way communication between python and javascript, and then write a much simpler emulator for the widgets on top of that. This already is done for the Sage Cell server.
Line 20: Line 23:
    * sagenb plots .png images, while ipynb prefers .svg images which can be nicely included within .ipynb (json) files (S)
    * can we import jmol within ipynb ? is it better to use 3D libs that work out of the box within ipython (e.g. matplotlib). See also [[http://trac.sagemath.org/ticket/16004|#16004]] (S)  
  * actually, very good interact and plotting libs already work with ipython (see for example [[https://github.com/ipython/ipython/wiki/A-gallery-of-interesting-IPython-Notebooks|this list]], so maybe should we just switch to them. (S)
    * sagenb plots .png images, while ipynb prefers .svg images which can be nicely included within .ipynb (json) files (S); (William: this is a little misleading. It's equally easy to get Sage to output png or svg with both 100% supported; also IPython is very good at embedding *both* png or svg files, where they embed the png's using some ascii embedding. Sage just generates matplotlib plots behind the scenes, as does ipython.)
    * can we import jmol within ipynb ? is it better to use 3D libs that work out of the box within ipython (e.g. matplotlib). See also [[http://trac.sagemath.org/ticket/16004|#16004]] (S). (William: I'm very unimpressed with mpl3d, even after 6 years of work. Also, we have a huge amount of code to create 3d scenes, which wouldn't get rendered using mpl3d unless somebody wrote a renderer.)
   * actually, very good interact and plotting libs already work with ipython (see for example [[https://github.com/ipython/ipython/wiki/A-gallery-of-interesting-IPython-Notebooks|this list]], so maybe should we just switch to them. (S)
Line 26: Line 29:
This should be developped within ustream, it is part of their plans (U)
This should be developed within ustream, it is part of their plans (U)
Line 30: Line 34:

=== Fundamental Design Issues ===

List any fundamental design issues with IPython that people maybe don't notice at first glance, which are done much better/differently in the Sage notebook. This should be a short list.

  * If you start a calculation with output slowly appearing, then kill your browser and check back later, the output is not saved anywhere. With sagenb (and SageMathCloud) the state of notebooks is saved in the server as well as the browser, whereas in IPython it exists only in the browser.

  * IPython depends on Tornado -- we would have to include a whole new async server framework (much like twisted) in Sage. This requires a package vote, thoughts about maintainability, etc. (William: I think Tornado is the best easy-to-maintain Python option for an async web server, so I'm happy they use it.) (Thierry: tornado is now a standard spkg of Sage, the only missing packages are zeromq and pyzmq, which are optional spkgs).

  * IPython depends on ZMQ -- we would also have to include that. This is more nontrivial regarding maintenance, and build time.


----

=== Using sagenb mathjax for ipynb ===
Not completely related, but i put it here because it can be of some help.

Mathjax is not shipped with ipynb, and the way to install it locally is [[http://ipython.org/ipython-doc/stable/install/install.html|to install it on the user's config directory]], which is not an optimal place for distribution. A quick workaround is to do a symlink from sagenb mathjax to user's ipython config dir (which i use in the sagedebianlive USB key). For this, open a shell as the user and type:

{{{
IPYTHON_VERSION=$(sage -c 'from IPython import version_info ; print(".".join([str(i) for i in version_info[:-1]]))')
IPYTHON_STATIC_DIR="${HOME}/.sage/ipython-${IPYTHON_VERSION}/profile_default/static/"
mkdir -p ${IPYTHON_STATIC_DIR}
cd ${IPYTHON_STATIC_DIR}
ln -s /opt/sagemath/sage/local/lib/python2.7/site-packages/sagenb-*.egg/sagenb/data/mathjax
}}}

Missing features for ipython to work within sage

This page aims to list which features of the Sage notebook (sagenb) are missing in the ipython notebook (ipynb). For each point we should think whether it is possible to directly work upstream (U), or if it is a sage-specific task (S).

Single user

  • interoperability
    • import and export .ipynb <-> .rst (U)

    • import from .sws (or perhaps the current sws2rst is enough) (S)
    • fetch and import sage notebooks from a http link to a html webpage.
  • live documentation: the reference manual and tutorials can be accessed as if they are worksheets (S?U)
  • packages
    • zeromq, pyzmq should become standard spkg (S)
    • include a mathjax spkg (instead of bulk stuff within sagenb spkg) and let ipynb point to it. (S)
  • have a function that tells wether Sage is currently running ipython console, ipython notebook, sage notebook, sage cell. (S)
  • have an option to launch ipynb with Sage preparsing without having to add the %load_ext sage.misc.sage_extension command. (S) (William: I think they more or less had something like this in 1.x, but removed any potential to do this sort of thing with 2.x, and when users complained refused to change it. So we might have to fork or monkey patch the code slightly.)

  • interact :
    • adapt the @interact decorator to work with ipython notebook interactive widgets (S)

    • or directly work with what is shipped with ipynb, without adding the @interact layer (which will need to be updated at each ipython improvement) (U) (William: but there is a LOT of code out there using @interact.)
    • For what it is worth, I rewrote @interact from scratch for SageMathCloud in 3 days. So it's not a huge amount of work adapting @interact to work with whatever framework.

    • Jason Grout: I helped write the IPython widget framework, and tried to build in enough flexibility so it would be fairly straightforward to get the widgets working in Sage. As a result, the Sage Cell server supports the framework and most of the widgets (though we're missing some of the client-side components some widgets assume, like bootstrap). To support widgets, basically you'd need to write a compatibility layer emulating the lower-level IPython Comm infrastructure providing 2-way communication between python and javascript, and then write a much simpler emulator for the widgets on top of that. This already is done for the Sage Cell server.
  • plotting
    • sagenb plots .png images, while ipynb prefers .svg images which can be nicely included within .ipynb (json) files (S); (William: this is a little misleading. It's equally easy to get Sage to output png or svg with both 100% supported; also IPython is very good at embedding *both* png or svg files, where they embed the png's using some ascii embedding. Sage just generates matplotlib plots behind the scenes, as does ipython.)
    • can we import jmol within ipynb ? is it better to use 3D libs that work out of the box within ipython (e.g. matplotlib). See also #16004 (S). (William: I'm very unimpressed with mpl3d, even after 6 years of work. Also, we have a huge amount of code to create 3d scenes, which wouldn't get rendered using mpl3d unless somebody wrote a renderer.)

    • actually, very good interact and plotting libs already work with ipython (see for example this list, so maybe should we just switch to them. (S)

Multi user

This should be developed within ustream, it is part of their plans (U)

  • serve notebooks on the lan
  • user management, account creation
  • have all notebooks stored in a single place (per user), with possibility to manage and publish them

Fundamental Design Issues

List any fundamental design issues with IPython that people maybe don't notice at first glance, which are done much better/differently in the Sage notebook. This should be a short list.

  • If you start a calculation with output slowly appearing, then kill your browser and check back later, the output is not saved anywhere. With sagenb (and SageMathCloud) the state of notebooks is saved in the server as well as the browser, whereas in IPython it exists only in the browser.

  • IPython depends on Tornado -- we would have to include a whole new async server framework (much like twisted) in Sage. This requires a package vote, thoughts about maintainability, etc. (William: I think Tornado is the best easy-to-maintain Python option for an async web server, so I'm happy they use it.) (Thierry: tornado is now a standard spkg of Sage, the only missing packages are zeromq and pyzmq, which are optional spkgs).
  • IPython depends on ZMQ -- we would also have to include that. This is more nontrivial regarding maintenance, and build time.


Using sagenb mathjax for ipynb

Not completely related, but i put it here because it can be of some help.

Mathjax is not shipped with ipynb, and the way to install it locally is to install it on the user's config directory, which is not an optimal place for distribution. A quick workaround is to do a symlink from sagenb mathjax to user's ipython config dir (which i use in the sagedebianlive USB key). For this, open a shell as the user and type:

IPYTHON_VERSION=$(sage -c 'from IPython import version_info ; print(".".join([str(i) for i in version_info[:-1]]))')
IPYTHON_STATIC_DIR="${HOME}/.sage/ipython-${IPYTHON_VERSION}/profile_default/static/"
mkdir -p ${IPYTHON_STATIC_DIR}
cd ${IPYTHON_STATIC_DIR}
ln -s /opt/sagemath/sage/local/lib/python2.7/site-packages/sagenb-*.egg/sagenb/data/mathjax

IpythonNotebook (last edited 2023-02-23 21:51:50 by mkoeppe)