From ehmatthes at gmail.com  Tue Oct  1 19:53:14 2013
From: ehmatthes at gmail.com (Eric Matthes)
Date: Tue, 1 Oct 2013 15:53:14 -0800
Subject: [IPython-dev] Appropriate use of notebook viewer?
Message-ID: <CAH-3OQ4y_-JWq6d4eDezrNnxknpAxEnW45P95kaOPm8r+cu6KQ@mail.gmail.com>

Hello everyone,

I just wanted to say thank you to everyone who replied the other day to my
question about whether to keep using notebook viewer or to find another
hosting solution. I originally subscribed to the digest version of the
mailing list, and couldn't figure out quickly how to reply to individual
responses.

I appreciate hearing about the different ways people are using the Notebook
Viewer, and using nbconvert to come up with other solutions. The responses
were quite helpful in figuring out how to best share the projects I am
working on, and collaborating on.

I will lurk for a bit, but I will definitely share a bit more about where
this project goes.

Eric Matthes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131001/f3754acc/attachment.html>

From fperez.net at gmail.com  Wed Oct  2 01:48:16 2013
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 1 Oct 2013 22:48:16 -0700
Subject: [IPython-dev] Mathjax topics for Thursday's meetings
Message-ID: <CAHAreOod0jE-egCkGVAvThgE1uW9ifws3BWRBJ5sHk2Y2dxjWg@mail.gmail.com>

Hi folks,

Peter Krautzberger, the Mathjax project lead, is likely to join us for
Thursday's dev meeting. I'm not sure exactly for how long he's avaiable,
but it should be a great opportunity to make contact with mathjax and ask
questions.  If you have any mathjax-related ideas/questions, please jot
them down in the hackpad agenda so we don't forget.

Cheers,


f

-- 
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131001/62a734b6/attachment.html>

From doc at doconnel.f9.co.uk  Wed Oct  2 12:31:09 2013
From: doc at doconnel.f9.co.uk (Derek O'Connell)
Date: Wed, 02 Oct 2013 17:31:09 +0100
Subject: [IPython-dev] IPEP 22: Notebook, new cell type "Comment"
Message-ID: <524C4A4D.3030804@doconnel.f9.co.uk>

New IPEP added to propose "Comment" type cell.

https://github.com/ipython/ipython/wiki/IPEP-22:-Notebook,-new-cell-type-%22Comment%22
https://github.com/ipython/ipython/issues/4330


From aron at ahmadia.net  Wed Oct  2 14:38:35 2013
From: aron at ahmadia.net (Aron Ahmadia)
Date: Wed, 2 Oct 2013 14:38:35 -0400
Subject: [IPython-dev] Fixing silent failures with IPython Notebook /
	uuid on Cygwin64
In-Reply-To: <CAPhiW4jGSb8K8r1zNKS1iUDOTocLP1Jh5D1RVMqa4QUDiLouqg@mail.gmail.com>
References: <CAPhiW4jGSb8K8r1zNKS1iUDOTocLP1Jh5D1RVMqa4QUDiLouqg@mail.gmail.com>
Message-ID: <CAPhiW4jz-Wxhv=5DW8QFvP7LJf+wMn_fpqecrRyW+9wm=QFkzA@mail.gmail.com>

A better fix that I missed is this patch from Evgeny Sologubov

diff -r 4a318a45c4c3 Lib/uuid.py
--- a/Lib/uuid.py   Mon Aug 19 13:07:18 2013 -0400
+++ b/Lib/uuid.py   Mon Aug 19 21:41:08 2013 +0400
@@ -429,6 +429,8 @@
             _uuid_generate_random = lib.uuid_generate_random
         if hasattr(lib, 'uuid_generate_time'):
             _uuid_generate_time = lib.uuid_generate_time
+            if _uuid_generate_random is not None:
+                break  # found everything we were looking for

     # The uuid_generate_* functions are broken on MacOS X 10.5, as noted
     # in issue #8621 the function generates the same sequence of values

Happy computing,
Aron

On Mon, Sep 30, 2013 at 2:26 PM, Aron Ahmadia <aron at ahmadia.net> wrote:
> Just a heads up for anybody who is trying to do development in Cygwin64.
>
> First off, you will need to follow the instructions here for getting
> ZMQ/PYZMQ:
>
> https://github.com/zeromq/pyzmq/issues/113
>
> If you are trying to run the notebook, you may encounter silent failures
> when running IPython Notebook from the command line:
>
> $ ipython notebook
>
> (Simply exits with no messages/errors)
>
> This is coming from a segfault in the Cygwin64 Python uuid module.  I tried
> to follow the instructions here:
> http://stackoverflow.com/questions/18947163/uuid-python-import-fails-on-cygwin-64bits
> and here: http://bugs.python.org/file20685/issue11063.patch but this didn't
> fix the crash.
>
> My stop-gap solution is to disable the call to _uuid_generate in uuid4
> post-patch.  This is reasonably safe, and just uses a different random
> number generator instead of the system-provided uuid function.
>
> def uuid4():
>     """Generate a random UUID."""
>
>     # When the system provides a version-4 UUID generator, use it.
>
> +    # AA disabling _uuid_generate
> +    uuid_generate_random = None
> -    uuid_generate_random = _uuid_generate("uuid_generate_random")
>
> The CPython and Cygwin folks appear to be aware of this issue, but since it
> took some of my time to debug, I'm hoping this will help others encountering
> similar problems in the future.
>
> After switching away from a GitHub release build, I've got IPython Notebook
> and the majority of its dependencies building from source using HashDist on
> Cygwin64 with a few things coming from the system, such as the broken Python
> patched above.
>
> Happy coding.
>
> A
>
>
>
>


From takowl at gmail.com  Wed Oct  2 19:13:08 2013
From: takowl at gmail.com (Thomas Kluyver)
Date: Wed, 2 Oct 2013 16:13:08 -0700
Subject: [IPython-dev] IPython user survey 2 - last chance to respond
Message-ID: <CAOvn4qgJ_xFyEUq9K7yLWTcwMS8ktfYgjskPPyzfwNw=PirDzw@mail.gmail.com>

We'll be closing the second IPython user survey in a couple of days to
summarise the results. If you haven't already filled it in, please go and
do so now:

https://docs.google.com/spreadsheet/viewform?formkey=dHF2WmlKdTZTRlZVRGFGTDgtUXFBVUE6MQ#gid=0

Thanks,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131002/0879e625/attachment.html>

From fperez.net at gmail.com  Wed Oct  2 20:32:43 2013
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 2 Oct 2013 17:32:43 -0700
Subject: [IPython-dev] Fixing silent failures with IPython Notebook /
 uuid on Cygwin64
In-Reply-To: <CAPhiW4jz-Wxhv=5DW8QFvP7LJf+wMn_fpqecrRyW+9wm=QFkzA@mail.gmail.com>
References: <CAPhiW4jGSb8K8r1zNKS1iUDOTocLP1Jh5D1RVMqa4QUDiLouqg@mail.gmail.com>
	<CAPhiW4jz-Wxhv=5DW8QFvP7LJf+wMn_fpqecrRyW+9wm=QFkzA@mail.gmail.com>
Message-ID: <CAHAreOod40JTYz-fL-bzOsGj4XY-UzjychVAmzMj=Qf=GC17ZQ@mail.gmail.com>

nasty! Thanks for these instructions Aron, I'm sure they'll save some other
poor soul quite a few hours...

f


On Wed, Oct 2, 2013 at 11:38 AM, Aron Ahmadia <aron at ahmadia.net> wrote:

> A better fix that I missed is this patch from Evgeny Sologubov
>
> diff -r 4a318a45c4c3 Lib/uuid.py
> --- a/Lib/uuid.py   Mon Aug 19 13:07:18 2013 -0400
> +++ b/Lib/uuid.py   Mon Aug 19 21:41:08 2013 +0400
> @@ -429,6 +429,8 @@
>              _uuid_generate_random = lib.uuid_generate_random
>          if hasattr(lib, 'uuid_generate_time'):
>              _uuid_generate_time = lib.uuid_generate_time
> +            if _uuid_generate_random is not None:
> +                break  # found everything we were looking for
>
>      # The uuid_generate_* functions are broken on MacOS X 10.5, as noted
>      # in issue #8621 the function generates the same sequence of values
>
> Happy computing,
> Aron
>
> On Mon, Sep 30, 2013 at 2:26 PM, Aron Ahmadia <aron at ahmadia.net> wrote:
> > Just a heads up for anybody who is trying to do development in Cygwin64.
> >
> > First off, you will need to follow the instructions here for getting
> > ZMQ/PYZMQ:
> >
> > https://github.com/zeromq/pyzmq/issues/113
> >
> > If you are trying to run the notebook, you may encounter silent failures
> > when running IPython Notebook from the command line:
> >
> > $ ipython notebook
> >
> > (Simply exits with no messages/errors)
> >
> > This is coming from a segfault in the Cygwin64 Python uuid module.  I
> tried
> > to follow the instructions here:
> >
> http://stackoverflow.com/questions/18947163/uuid-python-import-fails-on-cygwin-64bits
> > and here: http://bugs.python.org/file20685/issue11063.patch but this
> didn't
> > fix the crash.
> >
> > My stop-gap solution is to disable the call to _uuid_generate in uuid4
> > post-patch.  This is reasonably safe, and just uses a different random
> > number generator instead of the system-provided uuid function.
> >
> > def uuid4():
> >     """Generate a random UUID."""
> >
> >     # When the system provides a version-4 UUID generator, use it.
> >
> > +    # AA disabling _uuid_generate
> > +    uuid_generate_random = None
> > -    uuid_generate_random = _uuid_generate("uuid_generate_random")
> >
> > The CPython and Cygwin folks appear to be aware of this issue, but since
> it
> > took some of my time to debug, I'm hoping this will help others
> encountering
> > similar problems in the future.
> >
> > After switching away from a GitHub release build, I've got IPython
> Notebook
> > and the majority of its dependencies building from source using HashDist
> on
> > Cygwin64 with a few things coming from the system, such as the broken
> Python
> > patched above.
> >
> > Happy coding.
> >
> > A
> >
> >
> >
> >
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131002/3a5fd932/attachment.html>

From dpsanders at ciencias.unam.mx  Thu Oct  3 02:12:49 2013
From: dpsanders at ciencias.unam.mx (David P. Sanders)
Date: Thu, 3 Oct 2013 01:12:49 -0500
Subject: [IPython-dev] Abbreviated LaTeX in Markdown cells in the IPython
	Notebook
Message-ID: <CAFT+uJknRLA+OF7cNJVC+ix5WJ+3bBJOiDNQTAEnLvaRnBpuGw@mail.gmail.com>

Hi:

The following is possibly relevant for tomorrow's meeting with the MathJax
lead developer.

I have been playing with the idea of abbreviating LaTeX environments within
Markdown. This is a direct result of live note-taking with the IPython
Notebook in a course that I am co-teaching while the other professor gives
a blackboard class with equations, and finding myself slowed down by
writing verbose LaTeX.

(This is a common problem, which can be (partially) solved in other TeX
editors by judicious use of macro completion.)

It seems to me that the full-blown LaTeX environments, in particular
`\begin{equation}...\end{equation}, and particularly `align` [`equation` is
easily replaced by $$...$$, since no equation numbering is yet available],
are unnecessarily wordy for the IPython Notebook.

These full versions are necessary (?) when the relevant equation(s) are
embedded in a full LaTeX document, but in the IPython Notebook, they are
restricted to snippets of mathematics inside a Markdown cell. Thus, in the
spirit of Markdown, we should (in my opinion) search for a more lightweight
syntax for LaTeX snippets.

I have a branch `short_latex` at
https://github.com/dpsanders/ipython/tree/short_latex
which allows the following syntax inside Markdown cells:

# equation:
$eq y = 3x$

# align:
$al
y &= 3x\\
z &= 4x
$

That is, it uses `$...$` as the delimiters for the environment, and fills
out the environment based on the first word found after the first `$`.
The main benefit is to obviate the redundant \end{...} construction, and in
general save typing. `$...$` is a natural way to separate LaTeX snippets
from surrounding text (and, in particular, one which is already supported
by the current code).

The implementation currently intercepts the blocks of mathematics after
they are found (in the text-cell rendering function in `textcell.js`),
checks if they are of this form, and if so, replaces them by the full LaTeX
environment so that they are correctly rendered by MathJax.
[Health warning: my JavaScript is still rather shaky...]

The `cases` environment is also supported, but currently has the limitation
that it must come at the start of a LaTeX snippet:

$y = $ $ca 1 & \text{if } x>0\\
0 & \text{if } x \le 0
$

This could be fixed e.g. using
$y = ca{...}$
or some similar notation.

Maybe a better solution would be to simply treat these as some kind of
macro that would expand directly in the text stored in the text cell
itself, so that it would be correctly rendered even in a version of IPython
without this modification. (Though I am not sure how to go about doing
this.)

Is this something that people are interested in pursuing?
(Or does it just look too artificial and weird?) If so, might it be
possible to do something at the level of MathJax itself?

Best wishes,
David.


-- 
Dr. David P. Sanders

Profesor Titular "A" / Associate Professor
Departamento de F?sica, Facultad de Ciencias
Universidad Nacional Aut?noma de M?xico (UNAM)

dpsanders at ciencias.unam.mx
http://sistemas.fciencias.unam.mx/~dsanders

Cub?culo / office: #414, 4o. piso del Depto. de F?sica

Tel.: +52 55 5622 4965
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131003/63570ef0/attachment.html>

From asmeurer at gmail.com  Thu Oct  3 12:47:49 2013
From: asmeurer at gmail.com (Aaron Meurer)
Date: Thu, 3 Oct 2013 10:47:49 -0600
Subject: [IPython-dev] Abbreviated LaTeX in Markdown cells in the
	IPython Notebook
In-Reply-To: <CAFT+uJknRLA+OF7cNJVC+ix5WJ+3bBJOiDNQTAEnLvaRnBpuGw@mail.gmail.com>
References: <CAFT+uJknRLA+OF7cNJVC+ix5WJ+3bBJOiDNQTAEnLvaRnBpuGw@mail.gmail.com>
Message-ID: <3163135886901756712@unknownmsgid>

Wouldn't it be better to use full LaTeX compatible syntax, like newcommand?

Aaron Meurer

On Oct 3, 2013, at 12:13 AM, "David P. Sanders" <dpsanders at ciencias.unam.mx>
wrote:

Hi:

The following is possibly relevant for tomorrow's meeting with the MathJax
lead developer.

I have been playing with the idea of abbreviating LaTeX environments within
Markdown. This is a direct result of live note-taking with the IPython
Notebook in a course that I am co-teaching while the other professor gives
a blackboard class with equations, and finding myself slowed down by
writing verbose LaTeX.

(This is a common problem, which can be (partially) solved in other TeX
editors by judicious use of macro completion.)

It seems to me that the full-blown LaTeX environments, in particular
`\begin{equation}...\end{equation}, and particularly `align` [`equation` is
easily replaced by $$...$$, since no equation numbering is yet available],
are unnecessarily wordy for the IPython Notebook.

These full versions are necessary (?) when the relevant equation(s) are
embedded in a full LaTeX document, but in the IPython Notebook, they are
restricted to snippets of mathematics inside a Markdown cell. Thus, in the
spirit of Markdown, we should (in my opinion) search for a more lightweight
syntax for LaTeX snippets.

I have a branch `short_latex` at
https://github.com/dpsanders/ipython/tree/short_latex
which allows the following syntax inside Markdown cells:

# equation:
$eq y = 3x$

# align:
$al
y &= 3x\\
z &= 4x
$

That is, it uses `$...$` as the delimiters for the environment, and fills
out the environment based on the first word found after the first `$`.
The main benefit is to obviate the redundant \end{...} construction, and in
general save typing. `$...$` is a natural way to separate LaTeX snippets
from surrounding text (and, in particular, one which is already supported
by the current code).

The implementation currently intercepts the blocks of mathematics after
they are found (in the text-cell rendering function in `textcell.js`),
checks if they are of this form, and if so, replaces them by the full LaTeX
environment so that they are correctly rendered by MathJax.
[Health warning: my JavaScript is still rather shaky...]

The `cases` environment is also supported, but currently has the limitation
that it must come at the start of a LaTeX snippet:

$y = $ $ca 1 & \text{if } x>0\\
0 & \text{if } x \le 0
$

This could be fixed e.g. using
$y = ca{...}$
or some similar notation.

Maybe a better solution would be to simply treat these as some kind of
macro that would expand directly in the text stored in the text cell
itself, so that it would be correctly rendered even in a version of IPython
without this modification. (Though I am not sure how to go about doing
this.)

Is this something that people are interested in pursuing?
(Or does it just look too artificial and weird?) If so, might it be
possible to do something at the level of MathJax itself?

Best wishes,
David.


-- 
Dr. David P. Sanders

Profesor Titular "A" / Associate Professor
Departamento de F?sica, Facultad de Ciencias
Universidad Nacional Aut?noma de M?xico (UNAM)

dpsanders at ciencias.unam.mx
http://sistemas.fciencias.unam.mx/~dsanders

Cub?culo / office: #414, 4o. piso del Depto. de F?sica

Tel.: +52 55 5622 4965

_______________________________________________
IPython-dev mailing list
IPython-dev at scipy.org
http://mail.scipy.org/mailman/listinfo/ipython-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131003/854974b3/attachment.html>

From michael.walter at gmail.com  Thu Oct  3 14:01:21 2013
From: michael.walter at gmail.com (Michael Walter)
Date: Thu, 3 Oct 2013 19:01:21 +0100
Subject: [IPython-dev] Abbreviated LaTeX in Markdown cells in the
	IPython Notebook
In-Reply-To: <3163135886901756712@unknownmsgid>
References: <CAFT+uJknRLA+OF7cNJVC+ix5WJ+3bBJOiDNQTAEnLvaRnBpuGw@mail.gmail.com>
	<3163135886901756712@unknownmsgid>
Message-ID: <CAANtc+B4Auih8tZ+fMFbtnJefCmR6+m=gUaLBksrXvj__sMiwg@mail.gmail.com>

I think mathjax should already be able to handle this (e.g. in its
configuration, but also via \newcommand).

Best,
Michael



On Thu, Oct 3, 2013 at 5:47 PM, Aaron Meurer <asmeurer at gmail.com> wrote:

> Wouldn't it be better to use full LaTeX compatible syntax, like newcommand?
>
> Aaron Meurer
>
> On Oct 3, 2013, at 12:13 AM, "David P. Sanders" <
> dpsanders at ciencias.unam.mx> wrote:
>
> Hi:
>
> The following is possibly relevant for tomorrow's meeting with the MathJax
> lead developer.
>
> I have been playing with the idea of abbreviating LaTeX environments
> within Markdown. This is a direct result of live note-taking with the
> IPython Notebook in a course that I am co-teaching while the other
> professor gives a blackboard class with equations, and finding myself
> slowed down by writing verbose LaTeX.
>
> (This is a common problem, which can be (partially) solved in other TeX
> editors by judicious use of macro completion.)
>
> It seems to me that the full-blown LaTeX environments, in particular
> `\begin{equation}...\end{equation}, and particularly `align` [`equation` is
> easily replaced by $$...$$, since no equation numbering is yet available],
> are unnecessarily wordy for the IPython Notebook.
>
> These full versions are necessary (?) when the relevant equation(s) are
> embedded in a full LaTeX document, but in the IPython Notebook, they are
> restricted to snippets of mathematics inside a Markdown cell. Thus, in the
> spirit of Markdown, we should (in my opinion) search for a more lightweight
> syntax for LaTeX snippets.
>
> I have a branch `short_latex` at
> https://github.com/dpsanders/ipython/tree/short_latex
> which allows the following syntax inside Markdown cells:
>
> # equation:
> $eq y = 3x$
>
> # align:
> $al
> y &= 3x\\
> z &= 4x
> $
>
> That is, it uses `$...$` as the delimiters for the environment, and fills
> out the environment based on the first word found after the first `$`.
> The main benefit is to obviate the redundant \end{...} construction, and
> in general save typing. `$...$` is a natural way to separate LaTeX snippets
> from surrounding text (and, in particular, one which is already supported
> by the current code).
>
> The implementation currently intercepts the blocks of mathematics after
> they are found (in the text-cell rendering function in `textcell.js`),
> checks if they are of this form, and if so, replaces them by the full LaTeX
> environment so that they are correctly rendered by MathJax.
> [Health warning: my JavaScript is still rather shaky...]
>
> The `cases` environment is also supported, but currently has the
> limitation that it must come at the start of a LaTeX snippet:
>
> $y = $ $ca 1 & \text{if } x>0\\
> 0 & \text{if } x \le 0
> $
>
> This could be fixed e.g. using
> $y = ca{...}$
> or some similar notation.
>
> Maybe a better solution would be to simply treat these as some kind of
> macro that would expand directly in the text stored in the text cell
> itself, so that it would be correctly rendered even in a version of IPython
> without this modification. (Though I am not sure how to go about doing
> this.)
>
> Is this something that people are interested in pursuing?
> (Or does it just look too artificial and weird?) If so, might it be
> possible to do something at the level of MathJax itself?
>
> Best wishes,
> David.
>
>
> --
> Dr. David P. Sanders
>
> Profesor Titular "A" / Associate Professor
> Departamento de F?sica, Facultad de Ciencias
> Universidad Nacional Aut?noma de M?xico (UNAM)
>
> dpsanders at ciencias.unam.mx
> http://sistemas.fciencias.unam.mx/~dsanders
>
> Cub?culo / office: #414, 4o. piso del Depto. de F?sica
>
> Tel.: +52 55 5622 4965
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131003/5b5ad2ea/attachment.html>

From maidos93 at laposte.net  Sat Oct  5 08:38:15 2013
From: maidos93 at laposte.net (thwiouz)
Date: Sat, 5 Oct 2013 05:38:15 -0700 (PDT)
Subject: [IPython-dev] Displaying javascript from kernel
Message-ID: <1380976694937-5034831.post@n6.nabble.com>

Hi all,

I'm new in using the notebook and I'm currently trying yo add a button un
the interface to call the nbtoc magic. I based my function over the one
given in custom.js .
The loading of the magic works but executing it is not. I found something on
y the web saying that "display_" functions couldn't work because the code
was not attached to a specific cell. 
Could someone help me?
Thank you very much.




--
View this message in context: http://python.6.x6.nabble.com/Displaying-javascript-from-kernel-tp5034831.html
Sent from the IPython - Development mailing list archive at Nabble.com.


From bussonniermatthias at gmail.com  Sat Oct  5 13:48:29 2013
From: bussonniermatthias at gmail.com (Matthias BUSSONNIER)
Date: Sat, 5 Oct 2013 19:48:29 +0200
Subject: [IPython-dev] Displaying javascript from kernel
In-Reply-To: <1380976694937-5034831.post@n6.nabble.com>
References: <1380976694937-5034831.post@n6.nabble.com>
Message-ID: <05D82FEF-507D-4862-935C-B2116D24511A@gmail.com>


Le 5 oct. 2013 ? 14:38, thwiouz a ?crit :

> Hi all,
> 
> I'm new in using the notebook and I'm currently trying yo add a button un
> the interface to call the nbtoc magic. I based my function over the one
> given in custom.js .

I don't think what you want is to execute the magic. 
You should probably try to convert nbtoc as a pure
js extension that get the js/html using require.js

you can probably find example here :
https://github.com/ipython-contrib/IPython-notebook-extensions

in particular, here:
https://github.com/ipython-contrib/IPython-notebook-extensions/blob/master/slidemode/main.js#L14
you can see how to get other files using require.


> The loading of the magic works but executing it is not. I found something on
> y the web saying that "display_" functions couldn't work because the code
> was not attached to a specific cell. 

Yes, because the cell is the thing that handle the display of js and html, 
otherwise you have to define your own callback that will get what is 
returned by the kernel and append it to the DOM.

> Could someone help me?

For nbtoc the files are usually static, so there is no need to go through the kernel. 
I guess it was written like that as a convenience, and because @MinRK prefers magics
That pure js extension. 

Making nbtoc a pure-js extension will also allow it to work on non-python notebook.

-- 
M

From gmbecker at ucdavis.edu  Sun Oct  6 19:39:59 2013
From: gmbecker at ucdavis.edu (Gabriel Becker)
Date: Sun, 6 Oct 2013 16:39:59 -0700
Subject: [IPython-dev] Some new cell types for describing data analyses
 in IPy. Notebook
In-Reply-To: <CADwqtCPzJUTjYSkLQq-UGX+_CBZYvRr=1_0psgZE_yw0=eDWQQ@mail.gmail.com>
References: <CADwqtCNRb3EK7g6E80XXMSoY+QLrF1BaAdCm2yMhjWbr-Y-KzQ@mail.gmail.com>
	<CAHNn8BUZy5+0sMFiT9sFwnD4gUPKhZ-Mfv4W_6Q9jaOOHGBhwQ@mail.gmail.com>
	<CADwqtCN_NyjPBmny511LC8LkTTfo5cpAbBFQR5y_-wC9s6M=xw@mail.gmail.com>
	<CAHNn8BVP_0_o98ryMCeNEHjdPdq009zDu9majmrpXAbfhBrZgQ@mail.gmail.com>
	<F33ADD32-33D0-456A-9436-5FAE915FCA81@gmail.com>
	<CADwqtCM11DurMQFNd1PB+h_n_wMWHy1kR_d25V7VeJsQrY4LXw@mail.gmail.com>
	<CAH4pYpST2b81nVz5WJWMt6PpfqoGhRuOmw_wyKUDZFqGh=+7=Q@mail.gmail.com>
	<CADwqtCPQNrT95oZcTfXp=XG=avhWsj=fgjyzhHuc36w3nFESDA@mail.gmail.com>
	<CAH4pYpQjs_tTNLxD1c6fO7aYHgTYmgUpFPkGinQ8jOufHDzhYQ@mail.gmail.com>
	<CADwqtCP-cJxFqde_9YwsvzdOSRfx_tkrVcTxaE69VxU+Ni43Rw@mail.gmail.com>
	<CAH4pYpT4TBgHgqgZXLEN48+GWBk3Lk-_y+NY-QboFC+LH0t=rg@mail.gmail.com>
	<CADwqtCPzJUTjYSkLQq-UGX+_CBZYvRr=1_0psgZE_yw0=eDWQQ@mail.gmail.com>
Message-ID: <CADwqtCPHzp0MrK1MPSFbQ0jvp+1k=fmKV4dt87Yfsruc__nFTA@mail.gmail.com>

Hey Brian et al,

Just checking in to see if you and/or other team members are still
interested in meeting in person and chatting about some of the ideas we had
been discussing in this thread.

Happy to also continue the conversation here in the meantime.

~G


On Tue, Sep 10, 2013 at 6:32 PM, Gabriel Becker <gmbecker at ucdavis.edu>wrote:

> Brian et al,
>
> Brian I hope your move/travel/etc was as pleasant as such things can be.
>
>
> On Fri, Jul 12, 2013 at 9:21 AM, Brian Granger <ellisonbg at gmail.com>wrote:
>
>>  Gabriel,
>> <snip>
>>
>>
>> Great, let's talk in Sept. to figure out a time that would work.
>>
>
> I'm still quite interested in meeting with you guys. Somewhere near the
> end of the month would be best for me, but I'm pretty flexible.
>
>
>> <snip>
>>
>>  > Branching/DAG notebooks allow a single document to encompass the
>> research
>> > you did, while providing easy access to various views corresponding to
>> the
>> > generation of intermediate, alternative, and final results.
>> >
>> > These more complex notebooks allow the viewer to ask and answer
>> important
>> > questions such as "What else did (s)he try here?" and potentially even
>> "Why
>> > did (s)he choose this particular analysis strategy?". These questions
>> can be
>> > answered in the text or external supplementary materials in a linear
>> > notebook, but this is a significant barrier to reproducibility of the
>> > research process (as opposed to the analysis results).
>>
>> I can see that, however, I think the pure alt cells lack a critical
>> feature.  They treat all branches as being equally important.  In
>> reality, the branch that is chosen as the "best" one will likely
>> require further analysis and discussion that that other branches
>> don't.  Putting the different branches side by side makes it a little
>> like "choose your own adventure" - when in reality, the author of the
>> research want to steer the reader along a very particular path.  The
>> alternative paths maybe useful to have around, but they should be be
>> given equal weight as the "best" one.  But, maybe it is just
>> presentation and can be accounted for in descriptive text.
>>
>
> This is very true. My current thinking calls for both a "default"
> designation and a "most recently selected/run" designation, which I believe
> deals with the valid concern you raise above.
>
> There are also other important designations for "branch types". The most
> notable/easily explained of these is the concept of a "terminal" branch,
> which is a branch that records important computations (and prose), and
> which a viewer of the notebook  (be it the original author, a reviewer, a
> student, or someone looking to extend the work) may want to look at or run,
> but whose output is not compatible with the subsequent computations. This
> arises most commonly when one analysis strategy is implemented and pursued,
> but ultimately abandoned  (hopefully for good reasons, and with this we can
> check!) in favor of a different final strategy which produces incompatible
> output. The subsequent code then makes assumptions about the output which
> are compatible with the final strategy computations, but not the original
> strategy ones. A way to gracefully deal with this case is important for any
> document/processing/rendering system attempting to pursue these concepts.
>
> There are other cases that arise with these documents, but I will omit a
> detailed discussion of them and what I think should be done to support them
> here, as that would make this mail burdensomely long and it is not my
> primary message.
>
> I will note, though, that while I agree that the final/core/whathaveyou
> and secondary/informative/archival branches should not be
> indistinguishable, it is important for my usecase that they be easily
> accessible when the reader wants to in both interactive (notebook) and
> headless (nbconvert) modes.
>
>
>> <snip>
>>
>>
>> > As a practical/UI standpoint unselected branches can be hidden almost
>> > entirely (in theory, not currently in my PoC :p), resulting in a view
>> > equivalent to (any) the only view offered by a linear notebook. This
>> means
>> > that from a viewer (and author since a straight line IS a DAG and
>> nesting
>> > isn't forced) standpoint, what I'm describing is in essense a strict
>> > extension of what the notebook does now, rather than a change.
>>
>> I would be *more* interested in alt-cell approaches that present the
>> notebook as a linear entity in all cases, but that has the alt-cell
>> logic underneath.  For example, what about the following:
>>
>> * A user writes the different N alt cells in linear sequence
>> * The result is a purely linear notebook where one of the N cells should
>> be run.
>> * We write a JavaScript plugin for the notebook that does a couple of
>> things:
>>
>> 1. It provides a cell toolbar for marking those cells as members of an
>> alt-set.  This would simple modify the cell level metadata and allow
>> the author to provide titles of each alt-member.
>>
>
> What about branching that is 2 or more levels deep? That happens naturally
> with my approach but sounds difficult/annoying to keep track of in the one
> you are describing.
>
>
>> 2. It provides the logic for building a UI for viewing one of the
>> alt-set members at a time.  It could be as simple as injecting a drop
>> down menu that shows one and hides the rest.
>>
>
> I have an ugly but functional version of this now in my implementation.
>
>
>>
>> * This plugin could simple walk the notebook cells and find all the
>> alt-cell sets and build this supplementary UI.
>> * This plugin could also have settings that allow the author to select
>> the "best" member of the alt-set.
>> * nbconvert Transformers could use the cell level metadata to export
>> the notebook in different formats.
>>
>> As I write about this - I think this would be extremely nice, and it
>> would not be difficult to write at all.  Because of how our JavaScript
>> plugins work, it could be developed outside IPython initially.  The
>> question of inclusion in the official code base could be handled
>> later.  Honestly, this approach should be much easier than the work
>> you have already done.
>>
>
> Well, editing the notebook once it exists in this form seems like it would
> be much less fun, in terms of adding new cells.
>
> What you're describing is also much more onerous for the author. With what
> I have now, you declare a cell to be an altset or task and everything just
> sort of works. New cells are inserted in the right places, cells trivially
> know who their parents are, etc.
>
> If I understand you correctly, the author would have to write all the
> alternatives in a big linear document (not fun or easy to test, see
> discussion below) and then click a bunch of buttons to manually select what
> cells go in which alternate. That is a much larger cognitive burden on the
> author (as well as probably being really annoying...).
>
>
>>
>> Best of all the resulting notebooks would remain standard linear
>> notebooks that could be shared today on nbviewer, etc.  It would just
>> work.
>>
>
> Respectfully, this is actually the fatal flaw of this approach IMO, both
> in this case and in other cases where a JS plugin/extension uses the
> metadata approach to fundamentally modify *behavior* (as opposed to
> aestethics/UI) of the IPython Notebook.
>
> The issue, stated in the context of the nesting/alts/etc cells extension,
> is that a notebook that has branching/alternates *requires* that they be
> understood as such, rather than simply benefiting from it.
>
> The ability to distribute notebooks I write and have them work properly is
> entirely core to my usecase for IPython. If I can't do so, what I
> personally can get IPython or IPython notebooks to do on my own machine is
> not something I have any real interest in. Now you may be thinking to
> yourself "But Gabe, no one is using your fork so you can't do that now with
> your implementation anyway". That is true, but if someone without my fork
> installed manages to get their hands on a notebook which uses the nesting
> features, it will break when they try to load it.
>
> If I create an extension as you are describing, create a complex notebook
> using it, and someone without the plugin installed finds it, downloads it,
> and runs it, it will *run fine and happily give them incorrect results
> without even noticing the extra bits I stuck in the metadata*.
>
> The core issue here is that running a notebook with branching as a linear
> notebook by executing each of the branches in sequence is actually
> erroneous and will produce undefined, untrustworthy, and likely incorrect,
> behavior and output. The reason for this is that branches/alternatives are
> assumed to be mutually exclusive by the computational model, and can alter
> objects in-place in manners that can have unintended cumulative effects.
>
> As a very simple example consider branches which handle outliers in a
> certain variable by modifying the variable in-place and trimming its
> values  by .1, 1, 5, and 10%, respectively,  using quantiles and then
> consider what would happen if these branches were all run in an arbitrary
> order.
>
> It is easy to see that the outcome from running all the branches (which is
> what will silently happen if the notebook is treated as a standard linear
> notebook because the plugin is not being used) does not reflect any of the
> choices intended by the author and more complex situations could be
> difficult to predict at all without sitting down and thinking about it.
>
> As such, I would not be comfortable distributing branching notebooks using
> the extension mechanism as I understand it to exist now because a) I feel
> it indirectly damages the type of scientific reprodicibility and result
> trustworthiness I seek to advance, and b) I don't want to spend all my time
> fielding angry emails/bugreports from notebook authors who sent their
> notebooks to collaborators who didn't have the plugin installed.
>
>
>
>>
>> <snip>
>>
>> > Consider the example of classifying new data based on a training set via
>> > KNN, SVM, and GLM approaches. These approaches all need different sets
>> of
>> > parameters, return different types of objects as the output of the
>> fitting
>> > function, may have subtley different behaviour when being used for
>> > prediction, etc.
>>
>> Yep, that is the big challenge with the branching idea in general.  It
>> is not always true that the members of the alt sets can be swapped
>> out.
>>
>
> And under the model I am envisioning, that is actually an informative  and
> queriable feature, rather than a drawback. See my discussion above
> regarding terminal branches.
>
>
>>
>> <snip>
>>
>> I hope you can see that I really like the general idea and think the
>> usage cases you are describing are really important.  I think I can
>> speak for the project in saying that we want the notebook to be useful
>> for things like this.  But I think our abstractions are important
>> enough that we make every attempt to see how we can do these while
>> leveraging our existing abstractions.  This is partially a question
>> about implementation, but also partly a question about how the new
>> features are thought about.  The reason we don't like to break
>> abstractions for new features is that we have found an interesting
>> relationship between abstraction breaking and new features.  We have
>> found that when a new feature/idea breaks a core abstraction that we
>> have thought about very carefully, it is usually because the feature
>> has not been fully understood.  Time and time again, we have found
>> that when we take the time to fully understand the feature, it usually
>> fits within our abstractions beautifully and is even much better that
>> we ever imagined it could be.
>>
>> The plugin idea above is a perfect example of this.  By preserving the
>> abstractions the new feature itself a multiplication of even new
>> functionality:
>>
>> * The resulting notebooks can still be version controlled.  This means
>> that the different alt-cell can be thrown into git and when we develop
>> a visual diff tool for notebooks, they will *just work*.
>>
>
> I don't really understand this point. I have numerous fork-based
> non-linear notebooks under version control.
>
> Also, when you have a visual diff tool, it will successfully do *something
> * when given a linear+metadata branching notebook, but whether that
> something would be to deliver the information required to understand
> changes to non-linear notebooks  is less clear (and seems somewhat
> unlikely).
>
>
>> * The notebooks can immediately leverage the abstractions we have put
>> into place for converting notebooks to different formats.  You could
>> write custom transformers to present the notebook in a reveal.js
>> giving alt-cells special treatment.
>>
>
>
> I could write custom transformers, this is true, but the default behavior
> would treat the notebook as if it actually were linear (instead of just
> being stored that way) which is problematic.
>
>
>
>> * All of this can be done, and into the hands of user, without going
>> through those overly conservative IPython developers ;-)
>> * It will just work with nbviewer as well.
>>
>
> Again, I disagree. It would *display* in nbviewer, but not work, in that
> the display would be actively misleading regarding what the notebook would
> do when executed properly.
>
>
>>  * It provides a cleanly abstracted foundation for other people to build
>> upon
>>
>
> I agree that this is important, but it is not clear to me that it would be
> more true in the case that I created the extension via custom JS than it
> would if nesting were supported in the actual ipynb format and core
> notebook mechanisms.
>
>
>>
>> In summary, we are trying to build an architecture that allows a few
>> simple abstractions (we actually don't have that many!) to combine in
>> boundless ways to create features we never planned on, but that "just
>> work".
>>
>
> I agree that the customjs + metadata extensions approach is very powerful
> and almost infinitely versatile. I think it is great for extensions which
> change appearance/rendering/UI details of how the notebook behaves.
>
> As far as I can see, however,  it has some signficant problems with regard
> to extensions which fundamentally change non-rendering behavior of
> notebooks (please correct me if I'm wrong), namely:
>
>    - There is no guarantee that notebooks authored using an extension
>    which alters fundamental behaviors will work or visibly fail in the absence
>    of that extension
>    - There is no way for an individual notebook to require a particular
>    extension
>    - There is no way to ensure that two extensions are compatible with
>    each-other
>    - There is no standard/unified way for end-users to install extensions
>    - There is no way for users to determine which extensions they have
>
> The first point is not true of extensions which exclusively affect
> rendering and UI, making the rest of the points minor nuisances rather than
> critical issues.
> Looking forward to hearing your (further) thoughts about this stuff and
> hopefully meeting you in person soon.
>
> ~G
>
> --
> Gabriel Becker
> Graduate Student
> Statistics Department
> University of California, Davis
>



-- 
Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131006/83b89e9e/attachment.html>

From fperez.net at gmail.com  Sun Oct  6 20:51:52 2013
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 6 Oct 2013 17:51:52 -0700
Subject: [IPython-dev] Some new cell types for describing data analyses
 in IPy. Notebook
In-Reply-To: <CADwqtCPHzp0MrK1MPSFbQ0jvp+1k=fmKV4dt87Yfsruc__nFTA@mail.gmail.com>
References: <CADwqtCNRb3EK7g6E80XXMSoY+QLrF1BaAdCm2yMhjWbr-Y-KzQ@mail.gmail.com>
	<CAHNn8BUZy5+0sMFiT9sFwnD4gUPKhZ-Mfv4W_6Q9jaOOHGBhwQ@mail.gmail.com>
	<CADwqtCN_NyjPBmny511LC8LkTTfo5cpAbBFQR5y_-wC9s6M=xw@mail.gmail.com>
	<CAHNn8BVP_0_o98ryMCeNEHjdPdq009zDu9majmrpXAbfhBrZgQ@mail.gmail.com>
	<F33ADD32-33D0-456A-9436-5FAE915FCA81@gmail.com>
	<CADwqtCM11DurMQFNd1PB+h_n_wMWHy1kR_d25V7VeJsQrY4LXw@mail.gmail.com>
	<CAH4pYpST2b81nVz5WJWMt6PpfqoGhRuOmw_wyKUDZFqGh=+7=Q@mail.gmail.com>
	<CADwqtCPQNrT95oZcTfXp=XG=avhWsj=fgjyzhHuc36w3nFESDA@mail.gmail.com>
	<CAH4pYpQjs_tTNLxD1c6fO7aYHgTYmgUpFPkGinQ8jOufHDzhYQ@mail.gmail.com>
	<CADwqtCP-cJxFqde_9YwsvzdOSRfx_tkrVcTxaE69VxU+Ni43Rw@mail.gmail.com>
	<CAH4pYpT4TBgHgqgZXLEN48+GWBk3Lk-_y+NY-QboFC+LH0t=rg@mail.gmail.com>
	<CADwqtCPzJUTjYSkLQq-UGX+_CBZYvRr=1_0psgZE_yw0=eDWQQ@mail.gmail.com>
	<CADwqtCPHzp0MrK1MPSFbQ0jvp+1k=fmKV4dt87Yfsruc__nFTA@mail.gmail.com>
Message-ID: <CAHAreOq9DRJ5_bNn2ZEPsNv3ADRidFY6G_=8UWsFtW0+cYjzXg@mail.gmail.com>

Hi Gabriel,

sorry to have been silent, but everyone else is doing a great job on this
discussion...

I just wanted to say that we'd love to talk to you at Berkeley, but I'm
leaving town tonight for a couple weeks, so it won't work until late
October or more likely November.  But in Nov. I'm giving a talk at Davis,
in J. Eisen's group. Perhaps at least you and I could meet for coffee while
I'm there and cover some ground.

Another alternative for a higher-bandwidth technical discussion is to
schedule a slot into one of our public dev meetings on Thursdays. This week
we had Peter Krautzberger, from MathJax, join us and it was very useful.
 That will decouple us from finding a time when everyone can meet in
Berkeley, and more importantly, will allow others who can't make it in
person to also follow the discussion.

Cheers,

f


On Sun, Oct 6, 2013 at 4:39 PM, Gabriel Becker <gmbecker at ucdavis.edu> wrote:

> Hey Brian et al,
>
> Just checking in to see if you and/or other team members are still
> interested in meeting in person and chatting about some of the ideas we had
> been discussing in this thread.
>
> Happy to also continue the conversation here in the meantime.
>
> ~G
>
>
> On Tue, Sep 10, 2013 at 6:32 PM, Gabriel Becker <gmbecker at ucdavis.edu>wrote:
>
>> Brian et al,
>>
>> Brian I hope your move/travel/etc was as pleasant as such things can be.
>>
>>
>> On Fri, Jul 12, 2013 at 9:21 AM, Brian Granger <ellisonbg at gmail.com>wrote:
>>
>>>  Gabriel,
>>> <snip>
>>>
>>>
>>> Great, let's talk in Sept. to figure out a time that would work.
>>>
>>
>> I'm still quite interested in meeting with you guys. Somewhere near the
>> end of the month would be best for me, but I'm pretty flexible.
>>
>>
>>> <snip>
>>>
>>>  > Branching/DAG notebooks allow a single document to encompass the
>>> research
>>> > you did, while providing easy access to various views corresponding to
>>> the
>>> > generation of intermediate, alternative, and final results.
>>> >
>>> > These more complex notebooks allow the viewer to ask and answer
>>> important
>>> > questions such as "What else did (s)he try here?" and potentially even
>>> "Why
>>> > did (s)he choose this particular analysis strategy?". These questions
>>> can be
>>> > answered in the text or external supplementary materials in a linear
>>> > notebook, but this is a significant barrier to reproducibility of the
>>> > research process (as opposed to the analysis results).
>>>
>>> I can see that, however, I think the pure alt cells lack a critical
>>> feature.  They treat all branches as being equally important.  In
>>> reality, the branch that is chosen as the "best" one will likely
>>> require further analysis and discussion that that other branches
>>> don't.  Putting the different branches side by side makes it a little
>>> like "choose your own adventure" - when in reality, the author of the
>>> research want to steer the reader along a very particular path.  The
>>> alternative paths maybe useful to have around, but they should be be
>>> given equal weight as the "best" one.  But, maybe it is just
>>> presentation and can be accounted for in descriptive text.
>>>
>>
>> This is very true. My current thinking calls for both a "default"
>> designation and a "most recently selected/run" designation, which I believe
>> deals with the valid concern you raise above.
>>
>> There are also other important designations for "branch types". The most
>> notable/easily explained of these is the concept of a "terminal" branch,
>> which is a branch that records important computations (and prose), and
>> which a viewer of the notebook  (be it the original author, a reviewer, a
>> student, or someone looking to extend the work) may want to look at or run,
>> but whose output is not compatible with the subsequent computations. This
>> arises most commonly when one analysis strategy is implemented and pursued,
>> but ultimately abandoned  (hopefully for good reasons, and with this we can
>> check!) in favor of a different final strategy which produces incompatible
>> output. The subsequent code then makes assumptions about the output which
>> are compatible with the final strategy computations, but not the original
>> strategy ones. A way to gracefully deal with this case is important for any
>> document/processing/rendering system attempting to pursue these concepts.
>>
>> There are other cases that arise with these documents, but I will omit a
>> detailed discussion of them and what I think should be done to support them
>> here, as that would make this mail burdensomely long and it is not my
>> primary message.
>>
>> I will note, though, that while I agree that the final/core/whathaveyou
>> and secondary/informative/archival branches should not be
>> indistinguishable, it is important for my usecase that they be easily
>> accessible when the reader wants to in both interactive (notebook) and
>> headless (nbconvert) modes.
>>
>>
>>> <snip>
>>>
>>>
>>> > As a practical/UI standpoint unselected branches can be hidden almost
>>> > entirely (in theory, not currently in my PoC :p), resulting in a view
>>> > equivalent to (any) the only view offered by a linear notebook. This
>>> means
>>> > that from a viewer (and author since a straight line IS a DAG and
>>> nesting
>>> > isn't forced) standpoint, what I'm describing is in essense a strict
>>> > extension of what the notebook does now, rather than a change.
>>>
>>> I would be *more* interested in alt-cell approaches that present the
>>> notebook as a linear entity in all cases, but that has the alt-cell
>>> logic underneath.  For example, what about the following:
>>>
>>> * A user writes the different N alt cells in linear sequence
>>> * The result is a purely linear notebook where one of the N cells should
>>> be run.
>>> * We write a JavaScript plugin for the notebook that does a couple of
>>> things:
>>>
>>> 1. It provides a cell toolbar for marking those cells as members of an
>>> alt-set.  This would simple modify the cell level metadata and allow
>>> the author to provide titles of each alt-member.
>>>
>>
>> What about branching that is 2 or more levels deep? That happens
>> naturally with my approach but sounds difficult/annoying to keep track of
>> in the one you are describing.
>>
>>
>>> 2. It provides the logic for building a UI for viewing one of the
>>> alt-set members at a time.  It could be as simple as injecting a drop
>>> down menu that shows one and hides the rest.
>>>
>>
>> I have an ugly but functional version of this now in my implementation.
>>
>>
>>>
>>> * This plugin could simple walk the notebook cells and find all the
>>> alt-cell sets and build this supplementary UI.
>>> * This plugin could also have settings that allow the author to select
>>> the "best" member of the alt-set.
>>> * nbconvert Transformers could use the cell level metadata to export
>>> the notebook in different formats.
>>>
>>> As I write about this - I think this would be extremely nice, and it
>>> would not be difficult to write at all.  Because of how our JavaScript
>>> plugins work, it could be developed outside IPython initially.  The
>>> question of inclusion in the official code base could be handled
>>> later.  Honestly, this approach should be much easier than the work
>>> you have already done.
>>>
>>
>> Well, editing the notebook once it exists in this form seems like it
>> would be much less fun, in terms of adding new cells.
>>
>> What you're describing is also much more onerous for the author. With
>> what I have now, you declare a cell to be an altset or task and everything
>> just sort of works. New cells are inserted in the right places, cells
>> trivially know who their parents are, etc.
>>
>> If I understand you correctly, the author would have to write all the
>> alternatives in a big linear document (not fun or easy to test, see
>> discussion below) and then click a bunch of buttons to manually select what
>> cells go in which alternate. That is a much larger cognitive burden on the
>> author (as well as probably being really annoying...).
>>
>>
>>>
>>> Best of all the resulting notebooks would remain standard linear
>>> notebooks that could be shared today on nbviewer, etc.  It would just
>>> work.
>>>
>>
>> Respectfully, this is actually the fatal flaw of this approach IMO, both
>> in this case and in other cases where a JS plugin/extension uses the
>> metadata approach to fundamentally modify *behavior* (as opposed to
>> aestethics/UI) of the IPython Notebook.
>>
>> The issue, stated in the context of the nesting/alts/etc cells extension,
>> is that a notebook that has branching/alternates *requires* that they be
>> understood as such, rather than simply benefiting from it.
>>
>> The ability to distribute notebooks I write and have them work properly
>> is entirely core to my usecase for IPython. If I can't do so, what I
>> personally can get IPython or IPython notebooks to do on my own machine is
>> not something I have any real interest in. Now you may be thinking to
>> yourself "But Gabe, no one is using your fork so you can't do that now with
>> your implementation anyway". That is true, but if someone without my fork
>> installed manages to get their hands on a notebook which uses the nesting
>> features, it will break when they try to load it.
>>
>> If I create an extension as you are describing, create a complex notebook
>> using it, and someone without the plugin installed finds it, downloads it,
>> and runs it, it will *run fine and happily give them incorrect results
>> without even noticing the extra bits I stuck in the metadata*.
>>
>> The core issue here is that running a notebook with branching as a linear
>> notebook by executing each of the branches in sequence is actually
>> erroneous and will produce undefined, untrustworthy, and likely incorrect,
>> behavior and output. The reason for this is that branches/alternatives are
>> assumed to be mutually exclusive by the computational model, and can alter
>> objects in-place in manners that can have unintended cumulative effects.
>>
>> As a very simple example consider branches which handle outliers in a
>> certain variable by modifying the variable in-place and trimming its
>> values  by .1, 1, 5, and 10%, respectively,  using quantiles and then
>> consider what would happen if these branches were all run in an arbitrary
>> order.
>>
>> It is easy to see that the outcome from running all the branches (which
>> is what will silently happen if the notebook is treated as a standard
>> linear notebook because the plugin is not being used) does not reflect any
>> of the choices intended by the author and more complex situations could be
>> difficult to predict at all without sitting down and thinking about it.
>>
>> As such, I would not be comfortable distributing branching notebooks
>> using the extension mechanism as I understand it to exist now because a) I
>> feel it indirectly damages the type of scientific reprodicibility and
>> result trustworthiness I seek to advance, and b) I don't want to spend all
>> my time fielding angry emails/bugreports from notebook authors who sent
>> their notebooks to collaborators who didn't have the plugin installed.
>>
>>
>>
>>>
>>> <snip>
>>>
>>> > Consider the example of classifying new data based on a training set
>>> via
>>> > KNN, SVM, and GLM approaches. These approaches all need different sets
>>> of
>>> > parameters, return different types of objects as the output of the
>>> fitting
>>> > function, may have subtley different behaviour when being used for
>>> > prediction, etc.
>>>
>>> Yep, that is the big challenge with the branching idea in general.  It
>>> is not always true that the members of the alt sets can be swapped
>>> out.
>>>
>>
>> And under the model I am envisioning, that is actually an informative
>> and queriable feature, rather than a drawback. See my discussion above
>> regarding terminal branches.
>>
>>
>>>
>>> <snip>
>>>
>>> I hope you can see that I really like the general idea and think the
>>> usage cases you are describing are really important.  I think I can
>>> speak for the project in saying that we want the notebook to be useful
>>> for things like this.  But I think our abstractions are important
>>> enough that we make every attempt to see how we can do these while
>>> leveraging our existing abstractions.  This is partially a question
>>> about implementation, but also partly a question about how the new
>>> features are thought about.  The reason we don't like to break
>>> abstractions for new features is that we have found an interesting
>>> relationship between abstraction breaking and new features.  We have
>>> found that when a new feature/idea breaks a core abstraction that we
>>> have thought about very carefully, it is usually because the feature
>>> has not been fully understood.  Time and time again, we have found
>>> that when we take the time to fully understand the feature, it usually
>>> fits within our abstractions beautifully and is even much better that
>>> we ever imagined it could be.
>>>
>>> The plugin idea above is a perfect example of this.  By preserving the
>>> abstractions the new feature itself a multiplication of even new
>>> functionality:
>>>
>>> * The resulting notebooks can still be version controlled.  This means
>>> that the different alt-cell can be thrown into git and when we develop
>>> a visual diff tool for notebooks, they will *just work*.
>>>
>>
>> I don't really understand this point. I have numerous fork-based
>> non-linear notebooks under version control.
>>
>> Also, when you have a visual diff tool, it will successfully do *
>> something* when given a linear+metadata branching notebook, but whether
>> that something would be to deliver the information required to understand
>> changes to non-linear notebooks  is less clear (and seems somewhat
>> unlikely).
>>
>>
>>> * The notebooks can immediately leverage the abstractions we have put
>>> into place for converting notebooks to different formats.  You could
>>> write custom transformers to present the notebook in a reveal.js
>>> giving alt-cells special treatment.
>>>
>>
>>
>> I could write custom transformers, this is true, but the default behavior
>> would treat the notebook as if it actually were linear (instead of just
>> being stored that way) which is problematic.
>>
>>
>>
>>> * All of this can be done, and into the hands of user, without going
>>> through those overly conservative IPython developers ;-)
>>> * It will just work with nbviewer as well.
>>>
>>
>> Again, I disagree. It would *display* in nbviewer, but not work, in that
>> the display would be actively misleading regarding what the notebook would
>> do when executed properly.
>>
>>
>>>  * It provides a cleanly abstracted foundation for other people to build
>>> upon
>>>
>>
>> I agree that this is important, but it is not clear to me that it would
>> be more true in the case that I created the extension via custom JS than it
>> would if nesting were supported in the actual ipynb format and core
>> notebook mechanisms.
>>
>>
>>>
>>> In summary, we are trying to build an architecture that allows a few
>>> simple abstractions (we actually don't have that many!) to combine in
>>> boundless ways to create features we never planned on, but that "just
>>> work".
>>>
>>
>> I agree that the customjs + metadata extensions approach is very powerful
>> and almost infinitely versatile. I think it is great for extensions which
>> change appearance/rendering/UI details of how the notebook behaves.
>>
>> As far as I can see, however,  it has some signficant problems with
>> regard to extensions which fundamentally change non-rendering behavior of
>> notebooks (please correct me if I'm wrong), namely:
>>
>>    - There is no guarantee that notebooks authored using an extension
>>    which alters fundamental behaviors will work or visibly fail in the absence
>>    of that extension
>>    - There is no way for an individual notebook to require a particular
>>    extension
>>    - There is no way to ensure that two extensions are compatible with
>>    each-other
>>    - There is no standard/unified way for end-users to install extensions
>>    - There is no way for users to determine which extensions they have
>>
>> The first point is not true of extensions which exclusively affect
>> rendering and UI, making the rest of the points minor nuisances rather than
>> critical issues.
>> Looking forward to hearing your (further) thoughts about this stuff and
>> hopefully meeting you in person soon.
>>
>> ~G
>>
>> --
>> Gabriel Becker
>> Graduate Student
>> Statistics Department
>> University of California, Davis
>>
>
>
>
> --
> Gabriel Becker
> Graduate Student
> Statistics Department
> University of California, Davis
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>


-- 
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131006/3cc7f88c/attachment.html>

From maidos93 at laposte.net  Mon Oct  7 03:55:26 2013
From: maidos93 at laposte.net (thwiouz)
Date: Mon, 7 Oct 2013 00:55:26 -0700 (PDT)
Subject: [IPython-dev] Displaying javascript from kernel
In-Reply-To: <05D82FEF-507D-4862-935C-B2116D24511A@gmail.com>
References: <1380976694937-5034831.post@n6.nabble.com>
	<05D82FEF-507D-4862-935C-B2116D24511A@gmail.com>
Message-ID: <1381132526788-5034925.post@n6.nabble.com>

Thank you very much Matthias, I'll try to do that.
Thanks a lot.



--
View this message in context: http://python.6.x6.nabble.com/Displaying-javascript-from-kernel-tp5034831p5034925.html
Sent from the IPython - Development mailing list archive at Nabble.com.


From ellisonbg at gmail.com  Mon Oct  7 14:36:15 2013
From: ellisonbg at gmail.com (Brian Granger)
Date: Mon, 7 Oct 2013 11:36:15 -0700
Subject: [IPython-dev] Some new cell types for describing data analyses
 in IPy. Notebook
In-Reply-To: <CAHAreOq9DRJ5_bNn2ZEPsNv3ADRidFY6G_=8UWsFtW0+cYjzXg@mail.gmail.com>
References: <CADwqtCNRb3EK7g6E80XXMSoY+QLrF1BaAdCm2yMhjWbr-Y-KzQ@mail.gmail.com>
	<CAHNn8BUZy5+0sMFiT9sFwnD4gUPKhZ-Mfv4W_6Q9jaOOHGBhwQ@mail.gmail.com>
	<CADwqtCN_NyjPBmny511LC8LkTTfo5cpAbBFQR5y_-wC9s6M=xw@mail.gmail.com>
	<CAHNn8BVP_0_o98ryMCeNEHjdPdq009zDu9majmrpXAbfhBrZgQ@mail.gmail.com>
	<F33ADD32-33D0-456A-9436-5FAE915FCA81@gmail.com>
	<CADwqtCM11DurMQFNd1PB+h_n_wMWHy1kR_d25V7VeJsQrY4LXw@mail.gmail.com>
	<CAH4pYpST2b81nVz5WJWMt6PpfqoGhRuOmw_wyKUDZFqGh=+7=Q@mail.gmail.com>
	<CADwqtCPQNrT95oZcTfXp=XG=avhWsj=fgjyzhHuc36w3nFESDA@mail.gmail.com>
	<CAH4pYpQjs_tTNLxD1c6fO7aYHgTYmgUpFPkGinQ8jOufHDzhYQ@mail.gmail.com>
	<CADwqtCP-cJxFqde_9YwsvzdOSRfx_tkrVcTxaE69VxU+Ni43Rw@mail.gmail.com>
	<CAH4pYpT4TBgHgqgZXLEN48+GWBk3Lk-_y+NY-QboFC+LH0t=rg@mail.gmail.com>
	<CADwqtCPzJUTjYSkLQq-UGX+_CBZYvRr=1_0psgZE_yw0=eDWQQ@mail.gmail.com>
	<CADwqtCPHzp0MrK1MPSFbQ0jvp+1k=fmKV4dt87Yfsruc__nFTA@mail.gmail.com>
	<CAHAreOq9DRJ5_bNn2ZEPsNv3ADRidFY6G_=8UWsFtW0+cYjzXg@mail.gmail.com>
Message-ID: <CAH4pYpS_z8Pwmp-Rmk5b6VW=YYx0mAH-uAjELC1raocUbjxAPA@mail.gmail.com>

Gabriel,

I think we are pushing the limits of email on this discussion.  I
think it would be great to continue the discussion in person or our
Google Hangouts as Fernando mentions below.

> sorry to have been silent, but everyone else is doing a great job on this
> discussion...
>
> I just wanted to say that we'd love to talk to you at Berkeley, but I'm
> leaving town tonight for a couple weeks, so it won't work until late October
> or more likely November.  But in Nov. I'm giving a talk at Davis, in J.
> Eisen's group. Perhaps at least you and I could meet for coffee while I'm
> there and cover some ground.

That would be a great start to the in person discussions...

> Another alternative for a higher-bandwidth technical discussion is to
> schedule a slot into one of our public dev meetings on Thursdays. This week
> we had Peter Krautzberger, from MathJax, join us and it was very useful.
> That will decouple us from finding a time when everyone can meet in
> Berkeley, and more importantly, will allow others who can't make it in
> person to also follow the discussion.

Let us know if/when you can join us on this.

Cheers,

Brian

> Cheers,
>
> f
>
>
> On Sun, Oct 6, 2013 at 4:39 PM, Gabriel Becker <gmbecker at ucdavis.edu> wrote:
>>
>> Hey Brian et al,
>>
>> Just checking in to see if you and/or other team members are still
>> interested in meeting in person and chatting about some of the ideas we had
>> been discussing in this thread.
>>
>> Happy to also continue the conversation here in the meantime.
>>
>> ~G
>>
>>
>> On Tue, Sep 10, 2013 at 6:32 PM, Gabriel Becker <gmbecker at ucdavis.edu>
>> wrote:
>>>
>>> Brian et al,
>>>
>>> Brian I hope your move/travel/etc was as pleasant as such things can be.
>>>
>>>
>>> On Fri, Jul 12, 2013 at 9:21 AM, Brian Granger <ellisonbg at gmail.com>
>>> wrote:
>>>>
>>>> Gabriel,
>>>> <snip>
>>>>
>>>>
>>>> Great, let's talk in Sept. to figure out a time that would work.
>>>
>>>
>>> I'm still quite interested in meeting with you guys. Somewhere near the
>>> end of the month would be best for me, but I'm pretty flexible.
>>>
>>>>
>>>> <snip>
>>>>
>>>> > Branching/DAG notebooks allow a single document to encompass the
>>>> > research
>>>> > you did, while providing easy access to various views corresponding to
>>>> > the
>>>> > generation of intermediate, alternative, and final results.
>>>> >
>>>> > These more complex notebooks allow the viewer to ask and answer
>>>> > important
>>>> > questions such as "What else did (s)he try here?" and potentially even
>>>> > "Why
>>>> > did (s)he choose this particular analysis strategy?". These questions
>>>> > can be
>>>> > answered in the text or external supplementary materials in a linear
>>>> > notebook, but this is a significant barrier to reproducibility of the
>>>> > research process (as opposed to the analysis results).
>>>>
>>>> I can see that, however, I think the pure alt cells lack a critical
>>>> feature.  They treat all branches as being equally important.  In
>>>> reality, the branch that is chosen as the "best" one will likely
>>>> require further analysis and discussion that that other branches
>>>> don't.  Putting the different branches side by side makes it a little
>>>> like "choose your own adventure" - when in reality, the author of the
>>>> research want to steer the reader along a very particular path.  The
>>>> alternative paths maybe useful to have around, but they should be be
>>>> given equal weight as the "best" one.  But, maybe it is just
>>>> presentation and can be accounted for in descriptive text.
>>>
>>>
>>> This is very true. My current thinking calls for both a "default"
>>> designation and a "most recently selected/run" designation, which I believe
>>> deals with the valid concern you raise above.
>>>
>>> There are also other important designations for "branch types". The most
>>> notable/easily explained of these is the concept of a "terminal" branch,
>>> which is a branch that records important computations (and prose), and which
>>> a viewer of the notebook  (be it the original author, a reviewer, a student,
>>> or someone looking to extend the work) may want to look at or run, but whose
>>> output is not compatible with the subsequent computations. This arises most
>>> commonly when one analysis strategy is implemented and pursued, but
>>> ultimately abandoned  (hopefully for good reasons, and with this we can
>>> check!) in favor of a different final strategy which produces incompatible
>>> output. The subsequent code then makes assumptions about the output which
>>> are compatible with the final strategy computations, but not the original
>>> strategy ones. A way to gracefully deal with this case is important for any
>>> document/processing/rendering system attempting to pursue these concepts.
>>>
>>> There are other cases that arise with these documents, but I will omit a
>>> detailed discussion of them and what I think should be done to support them
>>> here, as that would make this mail burdensomely long and it is not my
>>> primary message.
>>>
>>> I will note, though, that while I agree that the final/core/whathaveyou
>>> and secondary/informative/archival branches should not be indistinguishable,
>>> it is important for my usecase that they be easily accessible when the
>>> reader wants to in both interactive (notebook) and headless (nbconvert)
>>> modes.
>>>
>>>>
>>>> <snip>
>>>>
>>>>
>>>> > As a practical/UI standpoint unselected branches can be hidden almost
>>>> > entirely (in theory, not currently in my PoC :p), resulting in a view
>>>> > equivalent to (any) the only view offered by a linear notebook. This
>>>> > means
>>>> > that from a viewer (and author since a straight line IS a DAG and
>>>> > nesting
>>>> > isn't forced) standpoint, what I'm describing is in essense a strict
>>>> > extension of what the notebook does now, rather than a change.
>>>>
>>>> I would be *more* interested in alt-cell approaches that present the
>>>> notebook as a linear entity in all cases, but that has the alt-cell
>>>> logic underneath.  For example, what about the following:
>>>>
>>>> * A user writes the different N alt cells in linear sequence
>>>> * The result is a purely linear notebook where one of the N cells should
>>>> be run.
>>>> * We write a JavaScript plugin for the notebook that does a couple of
>>>> things:
>>>>
>>>> 1. It provides a cell toolbar for marking those cells as members of an
>>>> alt-set.  This would simple modify the cell level metadata and allow
>>>> the author to provide titles of each alt-member.
>>>
>>>
>>> What about branching that is 2 or more levels deep? That happens
>>> naturally with my approach but sounds difficult/annoying to keep track of in
>>> the one you are describing.
>>>
>>>>
>>>> 2. It provides the logic for building a UI for viewing one of the
>>>> alt-set members at a time.  It could be as simple as injecting a drop
>>>> down menu that shows one and hides the rest.
>>>
>>>
>>> I have an ugly but functional version of this now in my implementation.
>>>
>>>>
>>>>
>>>> * This plugin could simple walk the notebook cells and find all the
>>>> alt-cell sets and build this supplementary UI.
>>>> * This plugin could also have settings that allow the author to select
>>>> the "best" member of the alt-set.
>>>> * nbconvert Transformers could use the cell level metadata to export
>>>> the notebook in different formats.
>>>>
>>>> As I write about this - I think this would be extremely nice, and it
>>>> would not be difficult to write at all.  Because of how our JavaScript
>>>> plugins work, it could be developed outside IPython initially.  The
>>>> question of inclusion in the official code base could be handled
>>>> later.  Honestly, this approach should be much easier than the work
>>>> you have already done.
>>>
>>>
>>> Well, editing the notebook once it exists in this form seems like it
>>> would be much less fun, in terms of adding new cells.
>>>
>>> What you're describing is also much more onerous for the author. With
>>> what I have now, you declare a cell to be an altset or task and everything
>>> just sort of works. New cells are inserted in the right places, cells
>>> trivially know who their parents are, etc.
>>>
>>> If I understand you correctly, the author would have to write all the
>>> alternatives in a big linear document (not fun or easy to test, see
>>> discussion below) and then click a bunch of buttons to manually select what
>>> cells go in which alternate. That is a much larger cognitive burden on the
>>> author (as well as probably being really annoying...).
>>>
>>>>
>>>>
>>>> Best of all the resulting notebooks would remain standard linear
>>>> notebooks that could be shared today on nbviewer, etc.  It would just
>>>> work.
>>>
>>>
>>> Respectfully, this is actually the fatal flaw of this approach IMO, both
>>> in this case and in other cases where a JS plugin/extension uses the
>>> metadata approach to fundamentally modify behavior (as opposed to
>>> aestethics/UI) of the IPython Notebook.
>>>
>>> The issue, stated in the context of the nesting/alts/etc cells extension,
>>> is that a notebook that has branching/alternates *requires* that they be
>>> understood as such, rather than simply benefiting from it.
>>>
>>> The ability to distribute notebooks I write and have them work properly
>>> is entirely core to my usecase for IPython. If I can't do so, what I
>>> personally can get IPython or IPython notebooks to do on my own machine is
>>> not something I have any real interest in. Now you may be thinking to
>>> yourself "But Gabe, no one is using your fork so you can't do that now with
>>> your implementation anyway". That is true, but if someone without my fork
>>> installed manages to get their hands on a notebook which uses the nesting
>>> features, it will break when they try to load it.
>>>
>>> If I create an extension as you are describing, create a complex notebook
>>> using it, and someone without the plugin installed finds it, downloads it,
>>> and runs it, it will run fine and happily give them incorrect results
>>> without even noticing the extra bits I stuck in the metadata.
>>>
>>> The core issue here is that running a notebook with branching as a linear
>>> notebook by executing each of the branches in sequence is actually erroneous
>>> and will produce undefined, untrustworthy, and likely incorrect, behavior
>>> and output. The reason for this is that branches/alternatives are assumed to
>>> be mutually exclusive by the computational model, and can alter objects
>>> in-place in manners that can have unintended cumulative effects.
>>>
>>> As a very simple example consider branches which handle outliers in a
>>> certain variable by modifying the variable in-place and trimming its values
>>> by .1, 1, 5, and 10%, respectively,  using quantiles and then consider what
>>> would happen if these branches were all run in an arbitrary order.
>>>
>>> It is easy to see that the outcome from running all the branches (which
>>> is what will silently happen if the notebook is treated as a standard linear
>>> notebook because the plugin is not being used) does not reflect any of the
>>> choices intended by the author and more complex situations could be
>>> difficult to predict at all without sitting down and thinking about it.
>>>
>>> As such, I would not be comfortable distributing branching notebooks
>>> using the extension mechanism as I understand it to exist now because a) I
>>> feel it indirectly damages the type of scientific reprodicibility and result
>>> trustworthiness I seek to advance, and b) I don't want to spend all my time
>>> fielding angry emails/bugreports from notebook authors who sent their
>>> notebooks to collaborators who didn't have the plugin installed.
>>>
>>>
>>>>
>>>>
>>>> <snip>
>>>>
>>>> > Consider the example of classifying new data based on a training set
>>>> > via
>>>> > KNN, SVM, and GLM approaches. These approaches all need different sets
>>>> > of
>>>> > parameters, return different types of objects as the output of the
>>>> > fitting
>>>> > function, may have subtley different behaviour when being used for
>>>> > prediction, etc.
>>>>
>>>> Yep, that is the big challenge with the branching idea in general.  It
>>>> is not always true that the members of the alt sets can be swapped
>>>> out.
>>>
>>>
>>> And under the model I am envisioning, that is actually an informative
>>> and queriable feature, rather than a drawback. See my discussion above
>>> regarding terminal branches.
>>>
>>>>
>>>>
>>>> <snip>
>>>>
>>>> I hope you can see that I really like the general idea and think the
>>>> usage cases you are describing are really important.  I think I can
>>>> speak for the project in saying that we want the notebook to be useful
>>>> for things like this.  But I think our abstractions are important
>>>> enough that we make every attempt to see how we can do these while
>>>> leveraging our existing abstractions.  This is partially a question
>>>> about implementation, but also partly a question about how the new
>>>> features are thought about.  The reason we don't like to break
>>>> abstractions for new features is that we have found an interesting
>>>> relationship between abstraction breaking and new features.  We have
>>>> found that when a new feature/idea breaks a core abstraction that we
>>>> have thought about very carefully, it is usually because the feature
>>>> has not been fully understood.  Time and time again, we have found
>>>> that when we take the time to fully understand the feature, it usually
>>>> fits within our abstractions beautifully and is even much better that
>>>> we ever imagined it could be.
>>>>
>>>> The plugin idea above is a perfect example of this.  By preserving the
>>>> abstractions the new feature itself a multiplication of even new
>>>> functionality:
>>>>
>>>> * The resulting notebooks can still be version controlled.  This means
>>>> that the different alt-cell can be thrown into git and when we develop
>>>> a visual diff tool for notebooks, they will *just work*.
>>>
>>>
>>> I don't really understand this point. I have numerous fork-based
>>> non-linear notebooks under version control.
>>>
>>> Also, when you have a visual diff tool, it will successfully do something
>>> when given a linear+metadata branching notebook, but whether that something
>>> would be to deliver the information required to understand changes to
>>> non-linear notebooks  is less clear (and seems somewhat unlikely).
>>>
>>>>
>>>> * The notebooks can immediately leverage the abstractions we have put
>>>> into place for converting notebooks to different formats.  You could
>>>> write custom transformers to present the notebook in a reveal.js
>>>> giving alt-cells special treatment.
>>>
>>>
>>>
>>> I could write custom transformers, this is true, but the default behavior
>>> would treat the notebook as if it actually were linear (instead of just
>>> being stored that way) which is problematic.
>>>
>>>
>>>>
>>>> * All of this can be done, and into the hands of user, without going
>>>> through those overly conservative IPython developers ;-)
>>>> * It will just work with nbviewer as well.
>>>
>>>
>>> Again, I disagree. It would *display* in nbviewer, but not work, in that
>>> the display would be actively misleading regarding what the notebook would
>>> do when executed properly.
>>>
>>>>
>>>> * It provides a cleanly abstracted foundation for other people to build
>>>> upon
>>>
>>>
>>> I agree that this is important, but it is not clear to me that it would
>>> be more true in the case that I created the extension via custom JS than it
>>> would if nesting were supported in the actual ipynb format and core notebook
>>> mechanisms.
>>>
>>>>
>>>>
>>>> In summary, we are trying to build an architecture that allows a few
>>>> simple abstractions (we actually don't have that many!) to combine in
>>>> boundless ways to create features we never planned on, but that "just
>>>> work".
>>>
>>>
>>> I agree that the customjs + metadata extensions approach is very powerful
>>> and almost infinitely versatile. I think it is great for extensions which
>>> change appearance/rendering/UI details of how the notebook behaves.
>>>
>>> As far as I can see, however,  it has some signficant problems with
>>> regard to extensions which fundamentally change non-rendering behavior of
>>> notebooks (please correct me if I'm wrong), namely:
>>>
>>> There is no guarantee that notebooks authored using an extension which
>>> alters fundamental behaviors will work or visibly fail in the absence of
>>> that extension
>>> There is no way for an individual notebook to require a particular
>>> extension
>>> There is no way to ensure that two extensions are compatible with
>>> each-other
>>> There is no standard/unified way for end-users to install extensions
>>> There is no way for users to determine which extensions they have
>>>
>>> The first point is not true of extensions which exclusively affect
>>> rendering and UI, making the rest of the points minor nuisances rather than
>>> critical issues.
>>>
>>> Looking forward to hearing your (further) thoughts about this stuff and
>>> hopefully meeting you in person soon.
>>>
>>> ~G
>>>
>>> --
>>> Gabriel Becker
>>> Graduate Student
>>> Statistics Department
>>> University of California, Davis
>>
>>
>>
>>
>> --
>> Gabriel Becker
>> Graduate Student
>> Statistics Department
>> University of California, Davis
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
>
>
> --
> Fernando Perez (@fperez_org; http://fperez.org)
> fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
> fernando.perez-at-berkeley: contact me here for any direct mail
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com


From gmbecker at ucdavis.edu  Mon Oct  7 17:33:14 2013
From: gmbecker at ucdavis.edu (Gabriel Becker)
Date: Mon, 7 Oct 2013 14:33:14 -0700
Subject: [IPython-dev] Some new cell types for describing data analyses
 in IPy. Notebook
In-Reply-To: <CAH4pYpS_z8Pwmp-Rmk5b6VW=YYx0mAH-uAjELC1raocUbjxAPA@mail.gmail.com>
References: <CADwqtCNRb3EK7g6E80XXMSoY+QLrF1BaAdCm2yMhjWbr-Y-KzQ@mail.gmail.com>
	<CAHNn8BUZy5+0sMFiT9sFwnD4gUPKhZ-Mfv4W_6Q9jaOOHGBhwQ@mail.gmail.com>
	<CADwqtCN_NyjPBmny511LC8LkTTfo5cpAbBFQR5y_-wC9s6M=xw@mail.gmail.com>
	<CAHNn8BVP_0_o98ryMCeNEHjdPdq009zDu9majmrpXAbfhBrZgQ@mail.gmail.com>
	<F33ADD32-33D0-456A-9436-5FAE915FCA81@gmail.com>
	<CADwqtCM11DurMQFNd1PB+h_n_wMWHy1kR_d25V7VeJsQrY4LXw@mail.gmail.com>
	<CAH4pYpST2b81nVz5WJWMt6PpfqoGhRuOmw_wyKUDZFqGh=+7=Q@mail.gmail.com>
	<CADwqtCPQNrT95oZcTfXp=XG=avhWsj=fgjyzhHuc36w3nFESDA@mail.gmail.com>
	<CAH4pYpQjs_tTNLxD1c6fO7aYHgTYmgUpFPkGinQ8jOufHDzhYQ@mail.gmail.com>
	<CADwqtCP-cJxFqde_9YwsvzdOSRfx_tkrVcTxaE69VxU+Ni43Rw@mail.gmail.com>
	<CAH4pYpT4TBgHgqgZXLEN48+GWBk3Lk-_y+NY-QboFC+LH0t=rg@mail.gmail.com>
	<CADwqtCPzJUTjYSkLQq-UGX+_CBZYvRr=1_0psgZE_yw0=eDWQQ@mail.gmail.com>
	<CADwqtCPHzp0MrK1MPSFbQ0jvp+1k=fmKV4dt87Yfsruc__nFTA@mail.gmail.com>
	<CAHAreOq9DRJ5_bNn2ZEPsNv3ADRidFY6G_=8UWsFtW0+cYjzXg@mail.gmail.com>
	<CAH4pYpS_z8Pwmp-Rmk5b6VW=YYx0mAH-uAjELC1raocUbjxAPA@mail.gmail.com>
Message-ID: <CADwqtCOAe-DOy45a7zxbAdHDQVOvyuB7=-fi0Zjhbm1m2mFAJw@mail.gmail.com>

I'm happy to jump in on one of the hangouts to discuss these ideas. I could
probably manage this thursday but next thursday might be better. I do agree
that the discrete post/respond cycle of emails does prove a bit cumbersome
for large detailed discussions like this. I still hope to meet the
local(ish) portions of the team in person at some point, but it sounds like
the logistics of that are tough and it is of course important to include
and engage the non-local people as well.

What format would this and my participation be in? Would I be presenting
something to get people up to speed or assuming that they have read the
novel that this thread has turned into?

Also, @fperez, I'd love to grab coffee and sit down with you when you're in
Davis.

~G


On Mon, Oct 7, 2013 at 11:36 AM, Brian Granger <ellisonbg at gmail.com> wrote:

> Gabriel,
>
> I think we are pushing the limits of email on this discussion.  I
> think it would be great to continue the discussion in person or our
> Google Hangouts as Fernando mentions below.
>
> > sorry to have been silent, but everyone else is doing a great job on this
> > discussion...
> >
> > I just wanted to say that we'd love to talk to you at Berkeley, but I'm
> > leaving town tonight for a couple weeks, so it won't work until late
> October
> > or more likely November.  But in Nov. I'm giving a talk at Davis, in J.
> > Eisen's group. Perhaps at least you and I could meet for coffee while I'm
> > there and cover some ground.
>
> That would be a great start to the in person discussions...
>
> > Another alternative for a higher-bandwidth technical discussion is to
> > schedule a slot into one of our public dev meetings on Thursdays. This
> week
> > we had Peter Krautzberger, from MathJax, join us and it was very useful.
> > That will decouple us from finding a time when everyone can meet in
> > Berkeley, and more importantly, will allow others who can't make it in
> > person to also follow the discussion.
>
> Let us know if/when you can join us on this.
>
> Cheers,
>
> Brian
>
> > Cheers,
> >
> > f
> >
> >
> > On Sun, Oct 6, 2013 at 4:39 PM, Gabriel Becker <gmbecker at ucdavis.edu>
> wrote:
> >>
> >> Hey Brian et al,
> >>
> >> Just checking in to see if you and/or other team members are still
> >> interested in meeting in person and chatting about some of the ideas we
> had
> >> been discussing in this thread.
> >>
> >> Happy to also continue the conversation here in the meantime.
> >>
> >> ~G
> >>
> >>
> >> On Tue, Sep 10, 2013 at 6:32 PM, Gabriel Becker <gmbecker at ucdavis.edu>
> >> wrote:
> >>>
> >>> Brian et al,
> >>>
> >>> Brian I hope your move/travel/etc was as pleasant as such things can
> be.
> >>>
> >>>
> >>> On Fri, Jul 12, 2013 at 9:21 AM, Brian Granger <ellisonbg at gmail.com>
> >>> wrote:
> >>>>
> >>>> Gabriel,
> >>>> <snip>
> >>>>
> >>>>
> >>>> Great, let's talk in Sept. to figure out a time that would work.
> >>>
> >>>
> >>> I'm still quite interested in meeting with you guys. Somewhere near the
> >>> end of the month would be best for me, but I'm pretty flexible.
> >>>
> >>>>
> >>>> <snip>
> >>>>
> >>>> > Branching/DAG notebooks allow a single document to encompass the
> >>>> > research
> >>>> > you did, while providing easy access to various views corresponding
> to
> >>>> > the
> >>>> > generation of intermediate, alternative, and final results.
> >>>> >
> >>>> > These more complex notebooks allow the viewer to ask and answer
> >>>> > important
> >>>> > questions such as "What else did (s)he try here?" and potentially
> even
> >>>> > "Why
> >>>> > did (s)he choose this particular analysis strategy?". These
> questions
> >>>> > can be
> >>>> > answered in the text or external supplementary materials in a linear
> >>>> > notebook, but this is a significant barrier to reproducibility of
> the
> >>>> > research process (as opposed to the analysis results).
> >>>>
> >>>> I can see that, however, I think the pure alt cells lack a critical
> >>>> feature.  They treat all branches as being equally important.  In
> >>>> reality, the branch that is chosen as the "best" one will likely
> >>>> require further analysis and discussion that that other branches
> >>>> don't.  Putting the different branches side by side makes it a little
> >>>> like "choose your own adventure" - when in reality, the author of the
> >>>> research want to steer the reader along a very particular path.  The
> >>>> alternative paths maybe useful to have around, but they should be be
> >>>> given equal weight as the "best" one.  But, maybe it is just
> >>>> presentation and can be accounted for in descriptive text.
> >>>
> >>>
> >>> This is very true. My current thinking calls for both a "default"
> >>> designation and a "most recently selected/run" designation, which I
> believe
> >>> deals with the valid concern you raise above.
> >>>
> >>> There are also other important designations for "branch types". The
> most
> >>> notable/easily explained of these is the concept of a "terminal"
> branch,
> >>> which is a branch that records important computations (and prose), and
> which
> >>> a viewer of the notebook  (be it the original author, a reviewer, a
> student,
> >>> or someone looking to extend the work) may want to look at or run, but
> whose
> >>> output is not compatible with the subsequent computations. This arises
> most
> >>> commonly when one analysis strategy is implemented and pursued, but
> >>> ultimately abandoned  (hopefully for good reasons, and with this we can
> >>> check!) in favor of a different final strategy which produces
> incompatible
> >>> output. The subsequent code then makes assumptions about the output
> which
> >>> are compatible with the final strategy computations, but not the
> original
> >>> strategy ones. A way to gracefully deal with this case is important
> for any
> >>> document/processing/rendering system attempting to pursue these
> concepts.
> >>>
> >>> There are other cases that arise with these documents, but I will omit
> a
> >>> detailed discussion of them and what I think should be done to support
> them
> >>> here, as that would make this mail burdensomely long and it is not my
> >>> primary message.
> >>>
> >>> I will note, though, that while I agree that the final/core/whathaveyou
> >>> and secondary/informative/archival branches should not be
> indistinguishable,
> >>> it is important for my usecase that they be easily accessible when the
> >>> reader wants to in both interactive (notebook) and headless (nbconvert)
> >>> modes.
> >>>
> >>>>
> >>>> <snip>
> >>>>
> >>>>
> >>>> > As a practical/UI standpoint unselected branches can be hidden
> almost
> >>>> > entirely (in theory, not currently in my PoC :p), resulting in a
> view
> >>>> > equivalent to (any) the only view offered by a linear notebook. This
> >>>> > means
> >>>> > that from a viewer (and author since a straight line IS a DAG and
> >>>> > nesting
> >>>> > isn't forced) standpoint, what I'm describing is in essense a strict
> >>>> > extension of what the notebook does now, rather than a change.
> >>>>
> >>>> I would be *more* interested in alt-cell approaches that present the
> >>>> notebook as a linear entity in all cases, but that has the alt-cell
> >>>> logic underneath.  For example, what about the following:
> >>>>
> >>>> * A user writes the different N alt cells in linear sequence
> >>>> * The result is a purely linear notebook where one of the N cells
> should
> >>>> be run.
> >>>> * We write a JavaScript plugin for the notebook that does a couple of
> >>>> things:
> >>>>
> >>>> 1. It provides a cell toolbar for marking those cells as members of an
> >>>> alt-set.  This would simple modify the cell level metadata and allow
> >>>> the author to provide titles of each alt-member.
> >>>
> >>>
> >>> What about branching that is 2 or more levels deep? That happens
> >>> naturally with my approach but sounds difficult/annoying to keep track
> of in
> >>> the one you are describing.
> >>>
> >>>>
> >>>> 2. It provides the logic for building a UI for viewing one of the
> >>>> alt-set members at a time.  It could be as simple as injecting a drop
> >>>> down menu that shows one and hides the rest.
> >>>
> >>>
> >>> I have an ugly but functional version of this now in my implementation.
> >>>
> >>>>
> >>>>
> >>>> * This plugin could simple walk the notebook cells and find all the
> >>>> alt-cell sets and build this supplementary UI.
> >>>> * This plugin could also have settings that allow the author to select
> >>>> the "best" member of the alt-set.
> >>>> * nbconvert Transformers could use the cell level metadata to export
> >>>> the notebook in different formats.
> >>>>
> >>>> As I write about this - I think this would be extremely nice, and it
> >>>> would not be difficult to write at all.  Because of how our JavaScript
> >>>> plugins work, it could be developed outside IPython initially.  The
> >>>> question of inclusion in the official code base could be handled
> >>>> later.  Honestly, this approach should be much easier than the work
> >>>> you have already done.
> >>>
> >>>
> >>> Well, editing the notebook once it exists in this form seems like it
> >>> would be much less fun, in terms of adding new cells.
> >>>
> >>> What you're describing is also much more onerous for the author. With
> >>> what I have now, you declare a cell to be an altset or task and
> everything
> >>> just sort of works. New cells are inserted in the right places, cells
> >>> trivially know who their parents are, etc.
> >>>
> >>> If I understand you correctly, the author would have to write all the
> >>> alternatives in a big linear document (not fun or easy to test, see
> >>> discussion below) and then click a bunch of buttons to manually select
> what
> >>> cells go in which alternate. That is a much larger cognitive burden on
> the
> >>> author (as well as probably being really annoying...).
> >>>
> >>>>
> >>>>
> >>>> Best of all the resulting notebooks would remain standard linear
> >>>> notebooks that could be shared today on nbviewer, etc.  It would just
> >>>> work.
> >>>
> >>>
> >>> Respectfully, this is actually the fatal flaw of this approach IMO,
> both
> >>> in this case and in other cases where a JS plugin/extension uses the
> >>> metadata approach to fundamentally modify behavior (as opposed to
> >>> aestethics/UI) of the IPython Notebook.
> >>>
> >>> The issue, stated in the context of the nesting/alts/etc cells
> extension,
> >>> is that a notebook that has branching/alternates *requires* that they
> be
> >>> understood as such, rather than simply benefiting from it.
> >>>
> >>> The ability to distribute notebooks I write and have them work properly
> >>> is entirely core to my usecase for IPython. If I can't do so, what I
> >>> personally can get IPython or IPython notebooks to do on my own
> machine is
> >>> not something I have any real interest in. Now you may be thinking to
> >>> yourself "But Gabe, no one is using your fork so you can't do that now
> with
> >>> your implementation anyway". That is true, but if someone without my
> fork
> >>> installed manages to get their hands on a notebook which uses the
> nesting
> >>> features, it will break when they try to load it.
> >>>
> >>> If I create an extension as you are describing, create a complex
> notebook
> >>> using it, and someone without the plugin installed finds it, downloads
> it,
> >>> and runs it, it will run fine and happily give them incorrect results
> >>> without even noticing the extra bits I stuck in the metadata.
> >>>
> >>> The core issue here is that running a notebook with branching as a
> linear
> >>> notebook by executing each of the branches in sequence is actually
> erroneous
> >>> and will produce undefined, untrustworthy, and likely incorrect,
> behavior
> >>> and output. The reason for this is that branches/alternatives are
> assumed to
> >>> be mutually exclusive by the computational model, and can alter objects
> >>> in-place in manners that can have unintended cumulative effects.
> >>>
> >>> As a very simple example consider branches which handle outliers in a
> >>> certain variable by modifying the variable in-place and trimming its
> values
> >>> by .1, 1, 5, and 10%, respectively,  using quantiles and then consider
> what
> >>> would happen if these branches were all run in an arbitrary order.
> >>>
> >>> It is easy to see that the outcome from running all the branches (which
> >>> is what will silently happen if the notebook is treated as a standard
> linear
> >>> notebook because the plugin is not being used) does not reflect any of
> the
> >>> choices intended by the author and more complex situations could be
> >>> difficult to predict at all without sitting down and thinking about it.
> >>>
> >>> As such, I would not be comfortable distributing branching notebooks
> >>> using the extension mechanism as I understand it to exist now because
> a) I
> >>> feel it indirectly damages the type of scientific reprodicibility and
> result
> >>> trustworthiness I seek to advance, and b) I don't want to spend all my
> time
> >>> fielding angry emails/bugreports from notebook authors who sent their
> >>> notebooks to collaborators who didn't have the plugin installed.
> >>>
> >>>
> >>>>
> >>>>
> >>>> <snip>
> >>>>
> >>>> > Consider the example of classifying new data based on a training set
> >>>> > via
> >>>> > KNN, SVM, and GLM approaches. These approaches all need different
> sets
> >>>> > of
> >>>> > parameters, return different types of objects as the output of the
> >>>> > fitting
> >>>> > function, may have subtley different behaviour when being used for
> >>>> > prediction, etc.
> >>>>
> >>>> Yep, that is the big challenge with the branching idea in general.  It
> >>>> is not always true that the members of the alt sets can be swapped
> >>>> out.
> >>>
> >>>
> >>> And under the model I am envisioning, that is actually an informative
> >>> and queriable feature, rather than a drawback. See my discussion above
> >>> regarding terminal branches.
> >>>
> >>>>
> >>>>
> >>>> <snip>
> >>>>
> >>>> I hope you can see that I really like the general idea and think the
> >>>> usage cases you are describing are really important.  I think I can
> >>>> speak for the project in saying that we want the notebook to be useful
> >>>> for things like this.  But I think our abstractions are important
> >>>> enough that we make every attempt to see how we can do these while
> >>>> leveraging our existing abstractions.  This is partially a question
> >>>> about implementation, but also partly a question about how the new
> >>>> features are thought about.  The reason we don't like to break
> >>>> abstractions for new features is that we have found an interesting
> >>>> relationship between abstraction breaking and new features.  We have
> >>>> found that when a new feature/idea breaks a core abstraction that we
> >>>> have thought about very carefully, it is usually because the feature
> >>>> has not been fully understood.  Time and time again, we have found
> >>>> that when we take the time to fully understand the feature, it usually
> >>>> fits within our abstractions beautifully and is even much better that
> >>>> we ever imagined it could be.
> >>>>
> >>>> The plugin idea above is a perfect example of this.  By preserving the
> >>>> abstractions the new feature itself a multiplication of even new
> >>>> functionality:
> >>>>
> >>>> * The resulting notebooks can still be version controlled.  This means
> >>>> that the different alt-cell can be thrown into git and when we develop
> >>>> a visual diff tool for notebooks, they will *just work*.
> >>>
> >>>
> >>> I don't really understand this point. I have numerous fork-based
> >>> non-linear notebooks under version control.
> >>>
> >>> Also, when you have a visual diff tool, it will successfully do
> something
> >>> when given a linear+metadata branching notebook, but whether that
> something
> >>> would be to deliver the information required to understand changes to
> >>> non-linear notebooks  is less clear (and seems somewhat unlikely).
> >>>
> >>>>
> >>>> * The notebooks can immediately leverage the abstractions we have put
> >>>> into place for converting notebooks to different formats.  You could
> >>>> write custom transformers to present the notebook in a reveal.js
> >>>> giving alt-cells special treatment.
> >>>
> >>>
> >>>
> >>> I could write custom transformers, this is true, but the default
> behavior
> >>> would treat the notebook as if it actually were linear (instead of just
> >>> being stored that way) which is problematic.
> >>>
> >>>
> >>>>
> >>>> * All of this can be done, and into the hands of user, without going
> >>>> through those overly conservative IPython developers ;-)
> >>>> * It will just work with nbviewer as well.
> >>>
> >>>
> >>> Again, I disagree. It would *display* in nbviewer, but not work, in
> that
> >>> the display would be actively misleading regarding what the notebook
> would
> >>> do when executed properly.
> >>>
> >>>>
> >>>> * It provides a cleanly abstracted foundation for other people to
> build
> >>>> upon
> >>>
> >>>
> >>> I agree that this is important, but it is not clear to me that it would
> >>> be more true in the case that I created the extension via custom JS
> than it
> >>> would if nesting were supported in the actual ipynb format and core
> notebook
> >>> mechanisms.
> >>>
> >>>>
> >>>>
> >>>> In summary, we are trying to build an architecture that allows a few
> >>>> simple abstractions (we actually don't have that many!) to combine in
> >>>> boundless ways to create features we never planned on, but that "just
> >>>> work".
> >>>
> >>>
> >>> I agree that the customjs + metadata extensions approach is very
> powerful
> >>> and almost infinitely versatile. I think it is great for extensions
> which
> >>> change appearance/rendering/UI details of how the notebook behaves.
> >>>
> >>> As far as I can see, however,  it has some signficant problems with
> >>> regard to extensions which fundamentally change non-rendering behavior
> of
> >>> notebooks (please correct me if I'm wrong), namely:
> >>>
> >>> There is no guarantee that notebooks authored using an extension which
> >>> alters fundamental behaviors will work or visibly fail in the absence
> of
> >>> that extension
> >>> There is no way for an individual notebook to require a particular
> >>> extension
> >>> There is no way to ensure that two extensions are compatible with
> >>> each-other
> >>> There is no standard/unified way for end-users to install extensions
> >>> There is no way for users to determine which extensions they have
> >>>
> >>> The first point is not true of extensions which exclusively affect
> >>> rendering and UI, making the rest of the points minor nuisances rather
> than
> >>> critical issues.
> >>>
> >>> Looking forward to hearing your (further) thoughts about this stuff and
> >>> hopefully meeting you in person soon.
> >>>
> >>> ~G
> >>>
> >>> --
> >>> Gabriel Becker
> >>> Graduate Student
> >>> Statistics Department
> >>> University of California, Davis
> >>
> >>
> >>
> >>
> >> --
> >> Gabriel Becker
> >> Graduate Student
> >> Statistics Department
> >> University of California, Davis
> >>
> >> _______________________________________________
> >> IPython-dev mailing list
> >> IPython-dev at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>
> >
> >
> >
> > --
> > Fernando Perez (@fperez_org; http://fperez.org)
> > fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
> > fernando.perez-at-berkeley: contact me here for any direct mail
> >
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> >
>
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu and ellisonbg at gmail.com
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131007/d5d879cb/attachment.html>

From damianavila at gmail.com  Mon Oct  7 18:54:05 2013
From: damianavila at gmail.com (=?ISO-8859-1?Q?Dami=E1n_Avila?=)
Date: Mon, 7 Oct 2013 19:54:05 -0300
Subject: [IPython-dev] Some new cell types for describing data analyses
 in IPy. Notebook
In-Reply-To: <CADwqtCOAe-DOy45a7zxbAdHDQVOvyuB7=-fi0Zjhbm1m2mFAJw@mail.gmail.com>
References: <CADwqtCNRb3EK7g6E80XXMSoY+QLrF1BaAdCm2yMhjWbr-Y-KzQ@mail.gmail.com>
	<CAHNn8BUZy5+0sMFiT9sFwnD4gUPKhZ-Mfv4W_6Q9jaOOHGBhwQ@mail.gmail.com>
	<CADwqtCN_NyjPBmny511LC8LkTTfo5cpAbBFQR5y_-wC9s6M=xw@mail.gmail.com>
	<CAHNn8BVP_0_o98ryMCeNEHjdPdq009zDu9majmrpXAbfhBrZgQ@mail.gmail.com>
	<F33ADD32-33D0-456A-9436-5FAE915FCA81@gmail.com>
	<CADwqtCM11DurMQFNd1PB+h_n_wMWHy1kR_d25V7VeJsQrY4LXw@mail.gmail.com>
	<CAH4pYpST2b81nVz5WJWMt6PpfqoGhRuOmw_wyKUDZFqGh=+7=Q@mail.gmail.com>
	<CADwqtCPQNrT95oZcTfXp=XG=avhWsj=fgjyzhHuc36w3nFESDA@mail.gmail.com>
	<CAH4pYpQjs_tTNLxD1c6fO7aYHgTYmgUpFPkGinQ8jOufHDzhYQ@mail.gmail.com>
	<CADwqtCP-cJxFqde_9YwsvzdOSRfx_tkrVcTxaE69VxU+Ni43Rw@mail.gmail.com>
	<CAH4pYpT4TBgHgqgZXLEN48+GWBk3Lk-_y+NY-QboFC+LH0t=rg@mail.gmail.com>
	<CADwqtCPzJUTjYSkLQq-UGX+_CBZYvRr=1_0psgZE_yw0=eDWQQ@mail.gmail.com>
	<CADwqtCPHzp0MrK1MPSFbQ0jvp+1k=fmKV4dt87Yfsruc__nFTA@mail.gmail.com>
	<CAHAreOq9DRJ5_bNn2ZEPsNv3ADRidFY6G_=8UWsFtW0+cYjzXg@mail.gmail.com>
	<CAH4pYpS_z8Pwmp-Rmk5b6VW=YYx0mAH-uAjELC1raocUbjxAPA@mail.gmail.com>
	<CADwqtCOAe-DOy45a7zxbAdHDQVOvyuB7=-fi0Zjhbm1m2mFAJw@mail.gmail.com>
Message-ID: <CAH+mRR0NcsGLszb9W-vbbXRBZV0eVSPM_77YmmGnY7HyX+CBkg@mail.gmail.com>

>What format would this and my participation be in? Would I be presenting
something to get people up to speed or assuming that they have read the
novel that this thread has turned into?

Probably most of the core developers have read this one, but is long
thread... and the beginning was some months ago.
I think that a quick summary covering the main issues and a little demo can
be a nice way to present this "novel" ;-)


2013/10/7 Gabriel Becker <gmbecker at ucdavis.edu>

> I'm happy to jump in on one of the hangouts to discuss these ideas. I
> could probably manage this thursday but next thursday might be better. I do
> agree that the discrete post/respond cycle of emails does prove a bit
> cumbersome for large detailed discussions like this. I still hope to meet
> the local(ish) portions of the team in person at some point, but it sounds
> like the logistics of that are tough and it is of course important to
> include and engage the non-local people as well.
>
> What format would this and my participation be in? Would I be presenting
> something to get people up to speed or assuming that they have read the
> novel that this thread has turned into?
>
> Also, @fperez, I'd love to grab coffee and sit down with you when you're
> in Davis.
>
> ~G
>
>
> On Mon, Oct 7, 2013 at 11:36 AM, Brian Granger <ellisonbg at gmail.com>wrote:
>
>> Gabriel,
>>
>> I think we are pushing the limits of email on this discussion.  I
>> think it would be great to continue the discussion in person or our
>> Google Hangouts as Fernando mentions below.
>>
>> > sorry to have been silent, but everyone else is doing a great job on
>> this
>> > discussion...
>> >
>> > I just wanted to say that we'd love to talk to you at Berkeley, but I'm
>> > leaving town tonight for a couple weeks, so it won't work until late
>> October
>> > or more likely November.  But in Nov. I'm giving a talk at Davis, in J.
>> > Eisen's group. Perhaps at least you and I could meet for coffee while
>> I'm
>> > there and cover some ground.
>>
>> That would be a great start to the in person discussions...
>>
>> > Another alternative for a higher-bandwidth technical discussion is to
>> > schedule a slot into one of our public dev meetings on Thursdays. This
>> week
>> > we had Peter Krautzberger, from MathJax, join us and it was very useful.
>> > That will decouple us from finding a time when everyone can meet in
>> > Berkeley, and more importantly, will allow others who can't make it in
>> > person to also follow the discussion.
>>
>> Let us know if/when you can join us on this.
>>
>> Cheers,
>>
>> Brian
>>
>> > Cheers,
>> >
>> > f
>> >
>> >
>> > On Sun, Oct 6, 2013 at 4:39 PM, Gabriel Becker <gmbecker at ucdavis.edu>
>> wrote:
>> >>
>> >> Hey Brian et al,
>> >>
>> >> Just checking in to see if you and/or other team members are still
>> >> interested in meeting in person and chatting about some of the ideas
>> we had
>> >> been discussing in this thread.
>> >>
>> >> Happy to also continue the conversation here in the meantime.
>> >>
>> >> ~G
>> >>
>> >>
>> >> On Tue, Sep 10, 2013 at 6:32 PM, Gabriel Becker <gmbecker at ucdavis.edu>
>> >> wrote:
>> >>>
>> >>> Brian et al,
>> >>>
>> >>> Brian I hope your move/travel/etc was as pleasant as such things can
>> be.
>> >>>
>> >>>
>> >>> On Fri, Jul 12, 2013 at 9:21 AM, Brian Granger <ellisonbg at gmail.com>
>> >>> wrote:
>> >>>>
>> >>>> Gabriel,
>> >>>> <snip>
>> >>>>
>> >>>>
>> >>>> Great, let's talk in Sept. to figure out a time that would work.
>> >>>
>> >>>
>> >>> I'm still quite interested in meeting with you guys. Somewhere near
>> the
>> >>> end of the month would be best for me, but I'm pretty flexible.
>> >>>
>> >>>>
>> >>>> <snip>
>> >>>>
>> >>>> > Branching/DAG notebooks allow a single document to encompass the
>> >>>> > research
>> >>>> > you did, while providing easy access to various views
>> corresponding to
>> >>>> > the
>> >>>> > generation of intermediate, alternative, and final results.
>> >>>> >
>> >>>> > These more complex notebooks allow the viewer to ask and answer
>> >>>> > important
>> >>>> > questions such as "What else did (s)he try here?" and potentially
>> even
>> >>>> > "Why
>> >>>> > did (s)he choose this particular analysis strategy?". These
>> questions
>> >>>> > can be
>> >>>> > answered in the text or external supplementary materials in a
>> linear
>> >>>> > notebook, but this is a significant barrier to reproducibility of
>> the
>> >>>> > research process (as opposed to the analysis results).
>> >>>>
>> >>>> I can see that, however, I think the pure alt cells lack a critical
>> >>>> feature.  They treat all branches as being equally important.  In
>> >>>> reality, the branch that is chosen as the "best" one will likely
>> >>>> require further analysis and discussion that that other branches
>> >>>> don't.  Putting the different branches side by side makes it a little
>> >>>> like "choose your own adventure" - when in reality, the author of the
>> >>>> research want to steer the reader along a very particular path.  The
>> >>>> alternative paths maybe useful to have around, but they should be be
>> >>>> given equal weight as the "best" one.  But, maybe it is just
>> >>>> presentation and can be accounted for in descriptive text.
>> >>>
>> >>>
>> >>> This is very true. My current thinking calls for both a "default"
>> >>> designation and a "most recently selected/run" designation, which I
>> believe
>> >>> deals with the valid concern you raise above.
>> >>>
>> >>> There are also other important designations for "branch types". The
>> most
>> >>> notable/easily explained of these is the concept of a "terminal"
>> branch,
>> >>> which is a branch that records important computations (and prose),
>> and which
>> >>> a viewer of the notebook  (be it the original author, a reviewer, a
>> student,
>> >>> or someone looking to extend the work) may want to look at or run,
>> but whose
>> >>> output is not compatible with the subsequent computations. This
>> arises most
>> >>> commonly when one analysis strategy is implemented and pursued, but
>> >>> ultimately abandoned  (hopefully for good reasons, and with this we
>> can
>> >>> check!) in favor of a different final strategy which produces
>> incompatible
>> >>> output. The subsequent code then makes assumptions about the output
>> which
>> >>> are compatible with the final strategy computations, but not the
>> original
>> >>> strategy ones. A way to gracefully deal with this case is important
>> for any
>> >>> document/processing/rendering system attempting to pursue these
>> concepts.
>> >>>
>> >>> There are other cases that arise with these documents, but I will
>> omit a
>> >>> detailed discussion of them and what I think should be done to
>> support them
>> >>> here, as that would make this mail burdensomely long and it is not my
>> >>> primary message.
>> >>>
>> >>> I will note, though, that while I agree that the
>> final/core/whathaveyou
>> >>> and secondary/informative/archival branches should not be
>> indistinguishable,
>> >>> it is important for my usecase that they be easily accessible when the
>> >>> reader wants to in both interactive (notebook) and headless
>> (nbconvert)
>> >>> modes.
>> >>>
>> >>>>
>> >>>> <snip>
>> >>>>
>> >>>>
>> >>>> > As a practical/UI standpoint unselected branches can be hidden
>> almost
>> >>>> > entirely (in theory, not currently in my PoC :p), resulting in a
>> view
>> >>>> > equivalent to (any) the only view offered by a linear notebook.
>> This
>> >>>> > means
>> >>>> > that from a viewer (and author since a straight line IS a DAG and
>> >>>> > nesting
>> >>>> > isn't forced) standpoint, what I'm describing is in essense a
>> strict
>> >>>> > extension of what the notebook does now, rather than a change.
>> >>>>
>> >>>> I would be *more* interested in alt-cell approaches that present the
>> >>>> notebook as a linear entity in all cases, but that has the alt-cell
>> >>>> logic underneath.  For example, what about the following:
>> >>>>
>> >>>> * A user writes the different N alt cells in linear sequence
>> >>>> * The result is a purely linear notebook where one of the N cells
>> should
>> >>>> be run.
>> >>>> * We write a JavaScript plugin for the notebook that does a couple of
>> >>>> things:
>> >>>>
>> >>>> 1. It provides a cell toolbar for marking those cells as members of
>> an
>> >>>> alt-set.  This would simple modify the cell level metadata and allow
>> >>>> the author to provide titles of each alt-member.
>> >>>
>> >>>
>> >>> What about branching that is 2 or more levels deep? That happens
>> >>> naturally with my approach but sounds difficult/annoying to keep
>> track of in
>> >>> the one you are describing.
>> >>>
>> >>>>
>> >>>> 2. It provides the logic for building a UI for viewing one of the
>> >>>> alt-set members at a time.  It could be as simple as injecting a drop
>> >>>> down menu that shows one and hides the rest.
>> >>>
>> >>>
>> >>> I have an ugly but functional version of this now in my
>> implementation.
>> >>>
>> >>>>
>> >>>>
>> >>>> * This plugin could simple walk the notebook cells and find all the
>> >>>> alt-cell sets and build this supplementary UI.
>> >>>> * This plugin could also have settings that allow the author to
>> select
>> >>>> the "best" member of the alt-set.
>> >>>> * nbconvert Transformers could use the cell level metadata to export
>> >>>> the notebook in different formats.
>> >>>>
>> >>>> As I write about this - I think this would be extremely nice, and it
>> >>>> would not be difficult to write at all.  Because of how our
>> JavaScript
>> >>>> plugins work, it could be developed outside IPython initially.  The
>> >>>> question of inclusion in the official code base could be handled
>> >>>> later.  Honestly, this approach should be much easier than the work
>> >>>> you have already done.
>> >>>
>> >>>
>> >>> Well, editing the notebook once it exists in this form seems like it
>> >>> would be much less fun, in terms of adding new cells.
>> >>>
>> >>> What you're describing is also much more onerous for the author. With
>> >>> what I have now, you declare a cell to be an altset or task and
>> everything
>> >>> just sort of works. New cells are inserted in the right places, cells
>> >>> trivially know who their parents are, etc.
>> >>>
>> >>> If I understand you correctly, the author would have to write all the
>> >>> alternatives in a big linear document (not fun or easy to test, see
>> >>> discussion below) and then click a bunch of buttons to manually
>> select what
>> >>> cells go in which alternate. That is a much larger cognitive burden
>> on the
>> >>> author (as well as probably being really annoying...).
>> >>>
>> >>>>
>> >>>>
>> >>>> Best of all the resulting notebooks would remain standard linear
>> >>>> notebooks that could be shared today on nbviewer, etc.  It would just
>> >>>> work.
>> >>>
>> >>>
>> >>> Respectfully, this is actually the fatal flaw of this approach IMO,
>> both
>> >>> in this case and in other cases where a JS plugin/extension uses the
>> >>> metadata approach to fundamentally modify behavior (as opposed to
>> >>> aestethics/UI) of the IPython Notebook.
>> >>>
>> >>> The issue, stated in the context of the nesting/alts/etc cells
>> extension,
>> >>> is that a notebook that has branching/alternates *requires* that they
>> be
>> >>> understood as such, rather than simply benefiting from it.
>> >>>
>> >>> The ability to distribute notebooks I write and have them work
>> properly
>> >>> is entirely core to my usecase for IPython. If I can't do so, what I
>> >>> personally can get IPython or IPython notebooks to do on my own
>> machine is
>> >>> not something I have any real interest in. Now you may be thinking to
>> >>> yourself "But Gabe, no one is using your fork so you can't do that
>> now with
>> >>> your implementation anyway". That is true, but if someone without my
>> fork
>> >>> installed manages to get their hands on a notebook which uses the
>> nesting
>> >>> features, it will break when they try to load it.
>> >>>
>> >>> If I create an extension as you are describing, create a complex
>> notebook
>> >>> using it, and someone without the plugin installed finds it,
>> downloads it,
>> >>> and runs it, it will run fine and happily give them incorrect results
>> >>> without even noticing the extra bits I stuck in the metadata.
>> >>>
>> >>> The core issue here is that running a notebook with branching as a
>> linear
>> >>> notebook by executing each of the branches in sequence is actually
>> erroneous
>> >>> and will produce undefined, untrustworthy, and likely incorrect,
>> behavior
>> >>> and output. The reason for this is that branches/alternatives are
>> assumed to
>> >>> be mutually exclusive by the computational model, and can alter
>> objects
>> >>> in-place in manners that can have unintended cumulative effects.
>> >>>
>> >>> As a very simple example consider branches which handle outliers in a
>> >>> certain variable by modifying the variable in-place and trimming its
>> values
>> >>> by .1, 1, 5, and 10%, respectively,  using quantiles and then
>> consider what
>> >>> would happen if these branches were all run in an arbitrary order.
>> >>>
>> >>> It is easy to see that the outcome from running all the branches
>> (which
>> >>> is what will silently happen if the notebook is treated as a standard
>> linear
>> >>> notebook because the plugin is not being used) does not reflect any
>> of the
>> >>> choices intended by the author and more complex situations could be
>> >>> difficult to predict at all without sitting down and thinking about
>> it.
>> >>>
>> >>> As such, I would not be comfortable distributing branching notebooks
>> >>> using the extension mechanism as I understand it to exist now because
>> a) I
>> >>> feel it indirectly damages the type of scientific reprodicibility and
>> result
>> >>> trustworthiness I seek to advance, and b) I don't want to spend all
>> my time
>> >>> fielding angry emails/bugreports from notebook authors who sent their
>> >>> notebooks to collaborators who didn't have the plugin installed.
>> >>>
>> >>>
>> >>>>
>> >>>>
>> >>>> <snip>
>> >>>>
>> >>>> > Consider the example of classifying new data based on a training
>> set
>> >>>> > via
>> >>>> > KNN, SVM, and GLM approaches. These approaches all need different
>> sets
>> >>>> > of
>> >>>> > parameters, return different types of objects as the output of the
>> >>>> > fitting
>> >>>> > function, may have subtley different behaviour when being used for
>> >>>> > prediction, etc.
>> >>>>
>> >>>> Yep, that is the big challenge with the branching idea in general.
>>  It
>> >>>> is not always true that the members of the alt sets can be swapped
>> >>>> out.
>> >>>
>> >>>
>> >>> And under the model I am envisioning, that is actually an informative
>> >>> and queriable feature, rather than a drawback. See my discussion above
>> >>> regarding terminal branches.
>> >>>
>> >>>>
>> >>>>
>> >>>> <snip>
>> >>>>
>> >>>> I hope you can see that I really like the general idea and think the
>> >>>> usage cases you are describing are really important.  I think I can
>> >>>> speak for the project in saying that we want the notebook to be
>> useful
>> >>>> for things like this.  But I think our abstractions are important
>> >>>> enough that we make every attempt to see how we can do these while
>> >>>> leveraging our existing abstractions.  This is partially a question
>> >>>> about implementation, but also partly a question about how the new
>> >>>> features are thought about.  The reason we don't like to break
>> >>>> abstractions for new features is that we have found an interesting
>> >>>> relationship between abstraction breaking and new features.  We have
>> >>>> found that when a new feature/idea breaks a core abstraction that we
>> >>>> have thought about very carefully, it is usually because the feature
>> >>>> has not been fully understood.  Time and time again, we have found
>> >>>> that when we take the time to fully understand the feature, it
>> usually
>> >>>> fits within our abstractions beautifully and is even much better that
>> >>>> we ever imagined it could be.
>> >>>>
>> >>>> The plugin idea above is a perfect example of this.  By preserving
>> the
>> >>>> abstractions the new feature itself a multiplication of even new
>> >>>> functionality:
>> >>>>
>> >>>> * The resulting notebooks can still be version controlled.  This
>> means
>> >>>> that the different alt-cell can be thrown into git and when we
>> develop
>> >>>> a visual diff tool for notebooks, they will *just work*.
>> >>>
>> >>>
>> >>> I don't really understand this point. I have numerous fork-based
>> >>> non-linear notebooks under version control.
>> >>>
>> >>> Also, when you have a visual diff tool, it will successfully do
>> something
>> >>> when given a linear+metadata branching notebook, but whether that
>> something
>> >>> would be to deliver the information required to understand changes to
>> >>> non-linear notebooks  is less clear (and seems somewhat unlikely).
>> >>>
>> >>>>
>> >>>> * The notebooks can immediately leverage the abstractions we have put
>> >>>> into place for converting notebooks to different formats.  You could
>> >>>> write custom transformers to present the notebook in a reveal.js
>> >>>> giving alt-cells special treatment.
>> >>>
>> >>>
>> >>>
>> >>> I could write custom transformers, this is true, but the default
>> behavior
>> >>> would treat the notebook as if it actually were linear (instead of
>> just
>> >>> being stored that way) which is problematic.
>> >>>
>> >>>
>> >>>>
>> >>>> * All of this can be done, and into the hands of user, without going
>> >>>> through those overly conservative IPython developers ;-)
>> >>>> * It will just work with nbviewer as well.
>> >>>
>> >>>
>> >>> Again, I disagree. It would *display* in nbviewer, but not work, in
>> that
>> >>> the display would be actively misleading regarding what the notebook
>> would
>> >>> do when executed properly.
>> >>>
>> >>>>
>> >>>> * It provides a cleanly abstracted foundation for other people to
>> build
>> >>>> upon
>> >>>
>> >>>
>> >>> I agree that this is important, but it is not clear to me that it
>> would
>> >>> be more true in the case that I created the extension via custom JS
>> than it
>> >>> would if nesting were supported in the actual ipynb format and core
>> notebook
>> >>> mechanisms.
>> >>>
>> >>>>
>> >>>>
>> >>>> In summary, we are trying to build an architecture that allows a few
>> >>>> simple abstractions (we actually don't have that many!) to combine in
>> >>>> boundless ways to create features we never planned on, but that "just
>> >>>> work".
>> >>>
>> >>>
>> >>> I agree that the customjs + metadata extensions approach is very
>> powerful
>> >>> and almost infinitely versatile. I think it is great for extensions
>> which
>> >>> change appearance/rendering/UI details of how the notebook behaves.
>> >>>
>> >>> As far as I can see, however,  it has some signficant problems with
>> >>> regard to extensions which fundamentally change non-rendering
>> behavior of
>> >>> notebooks (please correct me if I'm wrong), namely:
>> >>>
>> >>> There is no guarantee that notebooks authored using an extension which
>> >>> alters fundamental behaviors will work or visibly fail in the absence
>> of
>> >>> that extension
>> >>> There is no way for an individual notebook to require a particular
>> >>> extension
>> >>> There is no way to ensure that two extensions are compatible with
>> >>> each-other
>> >>> There is no standard/unified way for end-users to install extensions
>> >>> There is no way for users to determine which extensions they have
>> >>>
>> >>> The first point is not true of extensions which exclusively affect
>> >>> rendering and UI, making the rest of the points minor nuisances
>> rather than
>> >>> critical issues.
>> >>>
>> >>> Looking forward to hearing your (further) thoughts about this stuff
>> and
>> >>> hopefully meeting you in person soon.
>> >>>
>> >>> ~G
>> >>>
>> >>> --
>> >>> Gabriel Becker
>> >>> Graduate Student
>> >>> Statistics Department
>> >>> University of California, Davis
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Gabriel Becker
>> >> Graduate Student
>> >> Statistics Department
>> >> University of California, Davis
>> >>
>> >> _______________________________________________
>> >> IPython-dev mailing list
>> >> IPython-dev at scipy.org
>> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >>
>> >
>> >
>> >
>> > --
>> > Fernando Perez (@fperez_org; http://fperez.org)
>> > fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
>> > fernando.perez-at-berkeley: contact me here for any direct mail
>> >
>> > _______________________________________________
>> > IPython-dev mailing list
>> > IPython-dev at scipy.org
>> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >
>>
>>
>>
>> --
>> Brian E. Granger
>> Cal Poly State University, San Luis Obispo
>> bgranger at calpoly.edu and ellisonbg at gmail.com
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
>
>
> --
> Gabriel Becker
> Graduate Student
> Statistics Department
> University of California, Davis
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>


-- 
Dami?n Avila
Scientific Python Developer
Quantitative Finance Analyst
Statistics, Biostatistics and Econometrics Consultant
Biochemist
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131007/d54c3f57/attachment.html>

From jla65 at pitt.edu  Thu Oct 10 15:05:04 2013
From: jla65 at pitt.edu (Joshua Adelman)
Date: Thu, 10 Oct 2013 15:05:04 -0400
Subject: [IPython-dev] Embedding/Integrating IPython into an application
Message-ID: <B101BDD6-DF78-4475-8FCC-82B9E08FBCE0@pitt.edu>

Hi IPython devs and community,

I was hoping to get some feedback/suggestions on potentially embedding/integrating IPython into a Qt (PySide) application. The basic use case is that I have a large dataset stored as a numpy array that fits in memory but takes a non-negligble amount of time to load and large enough that I want to avoid making copies of it.  I want that data to be persistent in memory and then execute analysis code against that data without modifying it. I thought that IPython might be well suited to this sort of scheme as I could embed or integrate a kernel and then execute code in the same namespace as the data. I guess it's sort of a multiple-program single data type scheme. The Qt application is just providing an interface for setting up the methods to run on the data and the different parameter sets, where the code is prepared externally, but is discoverable by the application. The output of the code is a set of .npy or .npz files that might be loaded subsequently to perform further analysis, although it would be desirable to optionally load those arrays into the namespace. The analysis is an iterative and interactive process in which analysis scripts might be modified subsequently and then re-run, so the data should remain loaded in a long-running app. 

I coded a simple prototype of such a scheme that launched an IPython instance and then attached another client to the kernel and then used the send_channel to execute an analysis script using the %run magic akin to what is done in vim-ipython. Looking through the code base and the Scipy conference - IPython in Depth kernel embedding examples, it looks like there are several levels at which one might approach integrating IPython into an app though (e.g. using kernel_embed, integration with a GUI event loop, etc). 

I'd be particularly interested in feedback about whether (1) using IPython in this manner seems reasonable given the use case (and if not, are there other recommended alternative approaches), and if so (2) what level of the API might be best suited for integrating IPython in this case?

Any suggestions/insight would be most appreciated.

Best wishes,
Josh 

--
Dr. Joshua L. Adelman
Department of Biological Sciences
University of Pittsburgh, Pittsburgh, PA

From martijn at vermaat.name  Thu Oct 10 18:04:30 2013
From: martijn at vermaat.name (Martijn Vermaat)
Date: Fri, 11 Oct 2013 00:04:30 +0200
Subject: [IPython-dev] Viewing IPython notebooks in GitLab
Message-ID: <CAG7wmXwQSxRrMNau3XuOo5UL8SZCrnVgT6gCUU8vAuxrbLefOA@mail.gmail.com>

Hi all,

At my institute we run a private instance of the GitLab software (a
GitHub clone). We're also big fans of the IPython notebook, so the
obivous result is many repositories in GitLab containing IPython
notebooks.

Unfortunately, clicking a notebook file in GitLab shows just the JSON
source and because the raw files are not available anonymously, it's
non-trivial to use the Notebook Viewer. (And many repositories are
private on purpose anyway.)

So I made a very simple hack that embeds an HTML view of a notebook
directly in the GitLab page (of course by calling nbconvert).

In case anyone is interested, I wrote some documentation here:

  https://gist.github.com/martijnvermaat/6926070

Direct link to the patched GitLab master branch:

  https://github.com/martijnvermaat/gitlabhq/tree/blob-ipython-notebook

cheers,
Martijn


From ellisonbg at gmail.com  Fri Oct 11 13:15:24 2013
From: ellisonbg at gmail.com (Brian Granger)
Date: Fri, 11 Oct 2013 10:15:24 -0700
Subject: [IPython-dev] Viewing IPython notebooks in GitLab
In-Reply-To: <CAG7wmXwQSxRrMNau3XuOo5UL8SZCrnVgT6gCUU8vAuxrbLefOA@mail.gmail.com>
References: <CAG7wmXwQSxRrMNau3XuOo5UL8SZCrnVgT6gCUU8vAuxrbLefOA@mail.gmail.com>
Message-ID: <CAH4pYpTf11xc689z9u02r3hz3kSL02khCz7Ut=GQmAUwDS-3UQ@mail.gmail.com>

Martijn,

Thanks for letting us know about this.  This is a perfect usage of
nbconvert and I am sure the users of GitLab will appreciate this.

Cheers,

Brian

On Thu, Oct 10, 2013 at 3:04 PM, Martijn Vermaat <martijn at vermaat.name> wrote:
> Hi all,
>
> At my institute we run a private instance of the GitLab software (a
> GitHub clone). We're also big fans of the IPython notebook, so the
> obivous result is many repositories in GitLab containing IPython
> notebooks.
>
> Unfortunately, clicking a notebook file in GitLab shows just the JSON
> source and because the raw files are not available anonymously, it's
> non-trivial to use the Notebook Viewer. (And many repositories are
> private on purpose anyway.)
>
> So I made a very simple hack that embeds an HTML view of a notebook
> directly in the GitLab page (of course by calling nbconvert).
>
> In case anyone is interested, I wrote some documentation here:
>
>   https://gist.github.com/martijnvermaat/6926070
>
> Direct link to the patched GitLab master branch:
>
>   https://github.com/martijnvermaat/gitlabhq/tree/blob-ipython-notebook
>
> cheers,
> Martijn
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com


From wstein at gmail.com  Sat Oct 12 18:22:50 2013
From: wstein at gmail.com (William Stein)
Date: Sat, 12 Oct 2013 15:22:50 -0700
Subject: [IPython-dev] ipython with sync
In-Reply-To: <CAH4pYpQSKj83qi7Td7Z8xbpT5nBLqcfWch-9gVZ_gjggy5DgEQ@mail.gmail.com>
References: <CACLE5GDoXVOeEbEKZOJBzVbHAS=71RwhXbLfAkgfw0+U3rtC-w@mail.gmail.com>
	<CAH4pYpS0rEychGGcmu_zmdM-xtpJPqU+DmFtyc_8QP7938SjAw@mail.gmail.com>
	<CACLE5GCM4LAdnGXGXhnE=ssSfU6_4ZNeQ+y0scBYB0gbZrT=Tg@mail.gmail.com>
	<CAH4pYpQSKj83qi7Td7Z8xbpT5nBLqcfWch-9gVZ_gjggy5DgEQ@mail.gmail.com>
Message-ID: <CACLE5GC5PAnXxw99PJPr_HYAP3KWYdZCmWf=ZpNtK0vZa6yzvw@mail.gmail.com>

On Fri, Sep 13, 2013 at 10:44 AM, Brian Granger <ellisonbg at gmail.com> wrote:
> Thanks for this link, that is helpful.

Prompted by your message, I just also BSD licensed the IPython
integration code I wrote for https://cloud.sagemath.com

It's here:

https://gist.github.com/williamstein/6955561

This has all the monkey patching, setting things up in an iframe, the
other in-memory document format I use that is diff friendly (instead
of json).  It's everything I used to integrate into my sync framework.

William

>
> Cheers,
>
> Brian
>
> On Thu, Sep 12, 2013 at 4:04 PM, William Stein <wstein at gmail.com> wrote:
>> On Thu, Sep 12, 2013 at 2:53 PM, Brian Granger <ellisonbg at gmail.com> wrote:
>>> William,
>>>
>>> Thanks for notes.  This is really exciting and we are very interested
>>> in getting live sync to work with IPython itself.  I am traveling this
>>> week, but will try to have a look soon.  Is the code available
>>> somewhere to look at?
>>
>> Unfortunately, this implementation is very entangled as part of
>> something I'm building as part of a startup company with UW's Center
>> for commercialization, and I can't just open source everything.  But
>> the algorithm is here:
>>
>>   https://neil.fraser.name/writing/sync/
>>
>> and the author of that paper has an open source Python implementation,
>> I think...
>>
>>
>>>
>>> Cheers,
>>>
>>> Brian
>>>
>>> On Tue, Sep 10, 2013 at 9:11 AM, William Stein <wstein at gmail.com> wrote:
>>>> Hi,
>>>>
>>>> Somewhat by accident I spent the last two weeks implementing hosted
>>>> IPython notebooks with sync for https://cloud.sagemath.com.
>>>> Initially I had just plan to simplify the port forwarding setup, since
>>>> what Ondrej Certik was doing with multiple forward and reverse port
>>>> forwards seemed complicated.  But then I became concerned about
>>>> multiple users (or users with multiple browsers) overwriting each
>>>> other's notebooks, because cloud.sagemath projects are frequently
>>>> shared between multiple people, and everything else does realtime
>>>> sync.    I had planned just to add some very minimal merge-on-save
>>>> functionality to avoid major issues, but somehow got sucked into
>>>> realtime sync (even with the other person's cursor showing).
>>>>
>>>> It would be enormously helpful to me if a couple of expert IPython
>>>> users were to try out what I implemented and just ask a bunch of
>>>> questions.
>>>>
>>>> 1. Go to https://cloud.sagemath.com and make an account; this is
>>>> completely free, and is hosted on computers at University of
>>>> Washington.
>>>>
>>>> 2. Create a new project.
>>>>
>>>> 3. Click +New, then click "IPython" (or paste in a link to an ipython
>>>> notebook, or upload a file).
>>>>
>>>> 4. An IPython notebook server will start, the given .ipynb file should
>>>> load in a same-domain iframe, and then some of the ipython notebook
>>>> code is and iframe contents are monkey patched, in order to support
>>>> sync and better integration with https://cloud.sagemath.com.
>>>>
>>>> 5. Open the ipynb file in multiple browsers, and see that changes in
>>>> one appear in the other, including moving cells around, creating new
>>>> cells, editing markdown (the rendered version appears elsewhere), etc.
>>>>   Anything that sets the notebook.dirty flag in IPython causes a sync
>>>> (evaluating a cell that creates no output doesn't set this flag, at
>>>> least in 1.0.0, which is a bug in IPython, I guess).
>>>>
>>>> Since this is all very new and the first (I guess) realtime sync
>>>> implementation on top of IPython, there are probably a lot of issues.
>>>>  Note that if you click the "i" info button to the right, you'll get a
>>>> link to the standard IPython
>>>>
>>>> The other thing of interest is a little Python script called
>>>> "ipython-notebook", which I wrote.  It basically makes it easy to run
>>>> an IPython notebook server as a daemon, get the port it is running on,
>>>> etc.  It's pretty simple but satisfies my use case, and has
>>>> JSON-output, to make it web friendly.    As I've written it, my script
>>>> passes several base_url options through by default, which are needed
>>>> for cloud.sagemath.  Anyway, I've attached it to this email (with a
>>>> BSD license) in case there is any interest.
>>>>
>>>> Regarding the monkey patching in 4 above, the right thing to do would
>>>> be to explain exactly what hooks/changes in the IPython html client I
>>>> need in order to do sync, etc., make sure these makes sense to the
>>>> IPython devs, and send a pull request (or have a coding sprint in
>>>> Seattle or Berkeley?).  As an example, in order to do sync
>>>> *efficiently*, I have to be able to set a given cell from JSON -- it's
>>>> critical to do this in place when possible, since the overhead of
>>>> creating a new cell is huge (due probably to the overhead of creating
>>>> CodeMirror editors); however, the fromJSON method in IPython assumes
>>>> that the cell is brand new -- it would be nice to add an option to
>>>> make a cell fromJSON without assuming it is empty.
>>>>
>>>> The ultimate outcome of this could be a clean well-defined way of
>>>> doing sync for IPython notebooks using any third-party sync
>>>> implementation.  IPython might provide their own sync service and
>>>> there are starting to be others available these days -- e.g., Google
>>>> has one: https://developers.google.com/drive/realtime/, and maybe
>>>> Guido van Rosum helped write one for Dropbox recently?
>>>>
>>>> Subdirectories:   I noticed, incidentally, that the wakari version of
>>>> the IPython notebook server allows one to load ipynb files that are in
>>>> any subdirectory, whereas the standard IPython notebook server
>>>> doesn't.  For cloud.sagemath, I just spawn a new IPython notebook
>>>> server for each directory that a user accesses files in right now.
>>>> This seems cludgy, so I'm interested in the situation regarding adding
>>>> support for subdirectories.
>>>>
>>>> -- William
>>>>
>>>>
>>>>
>>>> --
>>>> William Stein
>>>> Professor of Mathematics
>>>> University of Washington
>>>> http://wstein.org
>>>>
>>>> _______________________________________________
>>>> IPython-dev mailing list
>>>> IPython-dev at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>
>>>
>>>
>>>
>>> --
>>> Brian E. Granger
>>> Cal Poly State University, San Luis Obispo
>>> bgranger at calpoly.edu and ellisonbg at gmail.com
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>>
>>
>> --
>> William Stein
>> Professor of Mathematics
>> University of Washington
>> http://wstein.org
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu and ellisonbg at gmail.com
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



-- 
William Stein
Professor of Mathematics
University of Washington
http://wstein.org


From benjaminrk at gmail.com  Sun Oct 13 03:49:10 2013
From: benjaminrk at gmail.com (MinRK)
Date: Sun, 13 Oct 2013 09:49:10 +0200
Subject: [IPython-dev] ipython with sync
In-Reply-To: <CACLE5GC5PAnXxw99PJPr_HYAP3KWYdZCmWf=ZpNtK0vZa6yzvw@mail.gmail.com>
References: <CACLE5GDoXVOeEbEKZOJBzVbHAS=71RwhXbLfAkgfw0+U3rtC-w@mail.gmail.com>
	<CAH4pYpS0rEychGGcmu_zmdM-xtpJPqU+DmFtyc_8QP7938SjAw@mail.gmail.com>
	<CACLE5GCM4LAdnGXGXhnE=ssSfU6_4ZNeQ+y0scBYB0gbZrT=Tg@mail.gmail.com>
	<CAH4pYpQSKj83qi7Td7Z8xbpT5nBLqcfWch-9gVZ_gjggy5DgEQ@mail.gmail.com>
	<CACLE5GC5PAnXxw99PJPr_HYAP3KWYdZCmWf=ZpNtK0vZa6yzvw@mail.gmail.com>
Message-ID: <CAHNn8BUQr3ydfyVUmsc3M1PpWc5u190gUubYH=uBBoes7z90EQ@mail.gmail.com>

Very cool, thanks William!


On Sun, Oct 13, 2013 at 12:22 AM, William Stein <wstein at gmail.com> wrote:

> On Fri, Sep 13, 2013 at 10:44 AM, Brian Granger <ellisonbg at gmail.com>
> wrote:
> > Thanks for this link, that is helpful.
>
> Prompted by your message, I just also BSD licensed the IPython
> integration code I wrote for https://cloud.sagemath.com
>
> It's here:
>
> https://gist.github.com/williamstein/6955561
>
> This has all the monkey patching, setting things up in an iframe, the
> other in-memory document format I use that is diff friendly (instead
> of json).  It's everything I used to integrate into my sync framework.
>
> William
>
> >
> > Cheers,
> >
> > Brian
> >
> > On Thu, Sep 12, 2013 at 4:04 PM, William Stein <wstein at gmail.com> wrote:
> >> On Thu, Sep 12, 2013 at 2:53 PM, Brian Granger <ellisonbg at gmail.com>
> wrote:
> >>> William,
> >>>
> >>> Thanks for notes.  This is really exciting and we are very interested
> >>> in getting live sync to work with IPython itself.  I am traveling this
> >>> week, but will try to have a look soon.  Is the code available
> >>> somewhere to look at?
> >>
> >> Unfortunately, this implementation is very entangled as part of
> >> something I'm building as part of a startup company with UW's Center
> >> for commercialization, and I can't just open source everything.  But
> >> the algorithm is here:
> >>
> >>   https://neil.fraser.name/writing/sync/
> >>
> >> and the author of that paper has an open source Python implementation,
> >> I think...
> >>
> >>
> >>>
> >>> Cheers,
> >>>
> >>> Brian
> >>>
> >>> On Tue, Sep 10, 2013 at 9:11 AM, William Stein <wstein at gmail.com>
> wrote:
> >>>> Hi,
> >>>>
> >>>> Somewhat by accident I spent the last two weeks implementing hosted
> >>>> IPython notebooks with sync for https://cloud.sagemath.com.
> >>>> Initially I had just plan to simplify the port forwarding setup, since
> >>>> what Ondrej Certik was doing with multiple forward and reverse port
> >>>> forwards seemed complicated.  But then I became concerned about
> >>>> multiple users (or users with multiple browsers) overwriting each
> >>>> other's notebooks, because cloud.sagemath projects are frequently
> >>>> shared between multiple people, and everything else does realtime
> >>>> sync.    I had planned just to add some very minimal merge-on-save
> >>>> functionality to avoid major issues, but somehow got sucked into
> >>>> realtime sync (even with the other person's cursor showing).
> >>>>
> >>>> It would be enormously helpful to me if a couple of expert IPython
> >>>> users were to try out what I implemented and just ask a bunch of
> >>>> questions.
> >>>>
> >>>> 1. Go to https://cloud.sagemath.com and make an account; this is
> >>>> completely free, and is hosted on computers at University of
> >>>> Washington.
> >>>>
> >>>> 2. Create a new project.
> >>>>
> >>>> 3. Click +New, then click "IPython" (or paste in a link to an ipython
> >>>> notebook, or upload a file).
> >>>>
> >>>> 4. An IPython notebook server will start, the given .ipynb file should
> >>>> load in a same-domain iframe, and then some of the ipython notebook
> >>>> code is and iframe contents are monkey patched, in order to support
> >>>> sync and better integration with https://cloud.sagemath.com.
> >>>>
> >>>> 5. Open the ipynb file in multiple browsers, and see that changes in
> >>>> one appear in the other, including moving cells around, creating new
> >>>> cells, editing markdown (the rendered version appears elsewhere), etc.
> >>>>   Anything that sets the notebook.dirty flag in IPython causes a sync
> >>>> (evaluating a cell that creates no output doesn't set this flag, at
> >>>> least in 1.0.0, which is a bug in IPython, I guess).
> >>>>
> >>>> Since this is all very new and the first (I guess) realtime sync
> >>>> implementation on top of IPython, there are probably a lot of issues.
> >>>>  Note that if you click the "i" info button to the right, you'll get a
> >>>> link to the standard IPython
> >>>>
> >>>> The other thing of interest is a little Python script called
> >>>> "ipython-notebook", which I wrote.  It basically makes it easy to run
> >>>> an IPython notebook server as a daemon, get the port it is running on,
> >>>> etc.  It's pretty simple but satisfies my use case, and has
> >>>> JSON-output, to make it web friendly.    As I've written it, my script
> >>>> passes several base_url options through by default, which are needed
> >>>> for cloud.sagemath.  Anyway, I've attached it to this email (with a
> >>>> BSD license) in case there is any interest.
> >>>>
> >>>> Regarding the monkey patching in 4 above, the right thing to do would
> >>>> be to explain exactly what hooks/changes in the IPython html client I
> >>>> need in order to do sync, etc., make sure these makes sense to the
> >>>> IPython devs, and send a pull request (or have a coding sprint in
> >>>> Seattle or Berkeley?).  As an example, in order to do sync
> >>>> *efficiently*, I have to be able to set a given cell from JSON -- it's
> >>>> critical to do this in place when possible, since the overhead of
> >>>> creating a new cell is huge (due probably to the overhead of creating
> >>>> CodeMirror editors); however, the fromJSON method in IPython assumes
> >>>> that the cell is brand new -- it would be nice to add an option to
> >>>> make a cell fromJSON without assuming it is empty.
> >>>>
> >>>> The ultimate outcome of this could be a clean well-defined way of
> >>>> doing sync for IPython notebooks using any third-party sync
> >>>> implementation.  IPython might provide their own sync service and
> >>>> there are starting to be others available these days -- e.g., Google
> >>>> has one: https://developers.google.com/drive/realtime/, and maybe
> >>>> Guido van Rosum helped write one for Dropbox recently?
> >>>>
> >>>> Subdirectories:   I noticed, incidentally, that the wakari version of
> >>>> the IPython notebook server allows one to load ipynb files that are in
> >>>> any subdirectory, whereas the standard IPython notebook server
> >>>> doesn't.  For cloud.sagemath, I just spawn a new IPython notebook
> >>>> server for each directory that a user accesses files in right now.
> >>>> This seems cludgy, so I'm interested in the situation regarding adding
> >>>> support for subdirectories.
> >>>>
> >>>> -- William
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> William Stein
> >>>> Professor of Mathematics
> >>>> University of Washington
> >>>> http://wstein.org
> >>>>
> >>>> _______________________________________________
> >>>> IPython-dev mailing list
> >>>> IPython-dev at scipy.org
> >>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Brian E. Granger
> >>> Cal Poly State University, San Luis Obispo
> >>> bgranger at calpoly.edu and ellisonbg at gmail.com
> >>> _______________________________________________
> >>> IPython-dev mailing list
> >>> IPython-dev at scipy.org
> >>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>
> >>
> >>
> >> --
> >> William Stein
> >> Professor of Mathematics
> >> University of Washington
> >> http://wstein.org
> >> _______________________________________________
> >> IPython-dev mailing list
> >> IPython-dev at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >
> >
> >
> > --
> > Brian E. Granger
> > Cal Poly State University, San Luis Obispo
> > bgranger at calpoly.edu and ellisonbg at gmail.com
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
>
> --
> William Stein
> Professor of Mathematics
> University of Washington
> http://wstein.org
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131013/47bf9707/attachment.html>

From maidos93 at laposte.net  Mon Oct 14 09:05:23 2013
From: maidos93 at laposte.net (thwiouz)
Date: Mon, 14 Oct 2013 06:05:23 -0700 (PDT)
Subject: [IPython-dev] Javascript callbacks
Message-ID: <1381755923715-5035680.post@n6.nabble.com>

Hello everybody,

I am trying to add a callback when executing of a function into javascript.
The code is executed but not the callback (defined in my js file).  I read
here 
http://stackoverflow.com/questions/11668704/minimalistic-example-of-ipython-kernel-javascript-bi-directional-communication
<http://stackoverflow.com/questions/11668704/minimalistic-example-of-ipython-kernel-javascript-bi-directional-communication>  
that the callback might be given with its context but I couldn't fix it.
Could someone tell me where I have to put my "handle_output" function to be
executed?
By the way, can I have access to the results of the code "inside" the result
of the /IPython.notebook.kernel.execute function/ or it's only achievable in
the "handle_output" function?

Thanks a lot,




--
View this message in context: http://python.6.x6.nabble.com/Javascript-callbacks-tp5035680.html
Sent from the IPython - Development mailing list archive at Nabble.com.


From mail at telenczuk.pl  Mon Oct 14 12:36:37 2013
From: mail at telenczuk.pl (Bartosz)
Date: Mon, 14 Oct 2013 18:36:37 +0200
Subject: [IPython-dev] nbviewer with private repos
Message-ID: <525C1D95.3090102@telenczuk.pl>

Hi all,

Is there any work in progress on using nbviewer with private repos (GH
and bitbucket)? The FAQ mentions that it's being worked on, but I did
not find anything in the issues/PRs on Github.

BTW Bitbucket offers unlimited free private repositories for academia,
so eiht nbviewer it might become great collaboration tool.

Cheers,

Bartosz


From ellisonbg at gmail.com  Mon Oct 14 12:43:35 2013
From: ellisonbg at gmail.com (Brian Granger)
Date: Mon, 14 Oct 2013 09:43:35 -0700
Subject: [IPython-dev] nbviewer with private repos
In-Reply-To: <525C1D95.3090102@telenczuk.pl>
References: <525C1D95.3090102@telenczuk.pl>
Message-ID: <CAH4pYpSwW27L++8QZHGQPzjtDvZTCXBsp7T8XF-xDD+873YJMA@mail.gmail.com>

We have no immediate plans to do this.

On Mon, Oct 14, 2013 at 9:36 AM, Bartosz <mail at telenczuk.pl> wrote:
> Hi all,
>
> Is there any work in progress on using nbviewer with private repos (GH
> and bitbucket)? The FAQ mentions that it's being worked on, but I did
> not find anything in the issues/PRs on Github.
>
> BTW Bitbucket offers unlimited free private repositories for academia,
> so eiht nbviewer it might become great collaboration tool.
>
> Cheers,
>
> Bartosz
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com


From mail at telenczuk.pl  Mon Oct 14 12:44:35 2013
From: mail at telenczuk.pl (Bartosz)
Date: Mon, 14 Oct 2013 18:44:35 +0200
Subject: [IPython-dev] nbviewer with private repos
In-Reply-To: <CAH4pYpSwW27L++8QZHGQPzjtDvZTCXBsp7T8XF-xDD+873YJMA@mail.gmail.com>
References: <525C1D95.3090102@telenczuk.pl>
	<CAH4pYpSwW27L++8QZHGQPzjtDvZTCXBsp7T8XF-xDD+873YJMA@mail.gmail.com>
Message-ID: <525C1F73.6020509@telenczuk.pl>

How about eventual PRs? Is it something you would  like to see in 
nbviewer?

Bartosz

On Mon 14 Oct 2013 06:43:35 PM CEST, Brian Granger wrote:
> We have no immediate plans to do this.
>
> On Mon, Oct 14, 2013 at 9:36 AM, Bartosz <mail at telenczuk.pl> wrote:
>> Hi all,
>>
>> Is there any work in progress on using nbviewer with private repos (GH
>> and bitbucket)? The FAQ mentions that it's being worked on, but I did
>> not find anything in the issues/PRs on Github.
>>
>> BTW Bitbucket offers unlimited free private repositories for academia,
>> so eiht nbviewer it might become great collaboration tool.
>>
>> Cheers,
>>
>> Bartosz
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
>


From bussonniermatthias at gmail.com  Mon Oct 14 12:51:06 2013
From: bussonniermatthias at gmail.com (Matthias BUSSONNIER)
Date: Mon, 14 Oct 2013 18:51:06 +0200
Subject: [IPython-dev] nbviewer with private repos
In-Reply-To: <525C1D95.3090102@telenczuk.pl>
References: <525C1D95.3090102@telenczuk.pl>
Message-ID: <1FB8274B-ADA2-4F46-8444-39DC7B8F3FB3@gmail.com>


Le 14 oct. 2013 ? 18:36, Bartosz a ?crit :

> Hi all,
> 
> Is there any work in progress on using nbviewer with private repos (GH
> and bitbucket)? The FAQ mentions that it's being worked on, but I did
> not find anything in the issues/PRs on Github.

With the current way nbviewer work this would automatically make your repo accessible to anyone. 
Private repo would need us to build an authentication mechanism with all the complication that goes with that. 
and more especially : 

1) Legal responsibility
2) Security Cost , like SSL endpoint  (that actually cost  $) which by itself would actually double the cost of nbviewer. 
3) Nbviewer is a golden goose for js injection/XSS and authentified user once we add authentication, if we don't pay attention.

Good news is :

You can install nbviewer locally, and give it access you your repo, it will also work for any public stuff. (plus a little line host and Tada). Still carefull of JS injection/XSS.

We are currently  moving to Rackspace.
It is slightly more work as we need to build the stack and (review the architecture on nbviewer to use tornado, help welcomed).
But might allow some more flexibility. 

-- 
M





> 
> BTW Bitbucket offers unlimited free private repositories for academia,
> so eiht nbviewer it might become great collaboration tool.
> 
> Cheers,
> 
> Bartosz
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



From ellisonbg at gmail.com  Mon Oct 14 12:52:38 2013
From: ellisonbg at gmail.com (Brian Granger)
Date: Mon, 14 Oct 2013 09:52:38 -0700
Subject: [IPython-dev] nbviewer with private repos
In-Reply-To: <525C1F73.6020509@telenczuk.pl>
References: <525C1D95.3090102@telenczuk.pl>
	<CAH4pYpSwW27L++8QZHGQPzjtDvZTCXBsp7T8XF-xDD+873YJMA@mail.gmail.com>
	<525C1F73.6020509@telenczuk.pl>
Message-ID: <CAH4pYpT9Luj6k+RxN2b8u3CWBBKH12ustbivo4MWnV+vcDmMtw@mail.gmail.com>

I don't understand what you mean by "eventual PRs"

On Mon, Oct 14, 2013 at 9:44 AM, Bartosz <mail at telenczuk.pl> wrote:
> How about eventual PRs? Is it something you would  like to see in
> nbviewer?
>
> Bartosz
>
> On Mon 14 Oct 2013 06:43:35 PM CEST, Brian Granger wrote:
>> We have no immediate plans to do this.
>>
>> On Mon, Oct 14, 2013 at 9:36 AM, Bartosz <mail at telenczuk.pl> wrote:
>>> Hi all,
>>>
>>> Is there any work in progress on using nbviewer with private repos (GH
>>> and bitbucket)? The FAQ mentions that it's being worked on, but I did
>>> not find anything in the issues/PRs on Github.
>>>
>>> BTW Bitbucket offers unlimited free private repositories for academia,
>>> so eiht nbviewer it might become great collaboration tool.
>>>
>>> Cheers,
>>>
>>> Bartosz
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>>
>>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com


From mail at telenczuk.pl  Mon Oct 14 12:56:24 2013
From: mail at telenczuk.pl (Bartosz)
Date: Mon, 14 Oct 2013 18:56:24 +0200
Subject: [IPython-dev] nbviewer with private repos
In-Reply-To: <CAH4pYpT9Luj6k+RxN2b8u3CWBBKH12ustbivo4MWnV+vcDmMtw@mail.gmail.com>
References: <525C1D95.3090102@telenczuk.pl>
	<CAH4pYpSwW27L++8QZHGQPzjtDvZTCXBsp7T8XF-xDD+873YJMA@mail.gmail.com>
	<525C1F73.6020509@telenczuk.pl>
	<CAH4pYpT9Luj6k+RxN2b8u3CWBBKH12ustbivo4MWnV+vcDmMtw@mail.gmail.com>
Message-ID: <525C2238.8030807@telenczuk.pl>

I am just asking if you would be interested in a pull request, but from 
Matthias explanation I see why that might be a non-trivial task. 
Perhaps I will try running a local copy.

Thanks!

Bartosz

On Mon 14 Oct 2013 06:52:38 PM CEST, Brian Granger wrote:
> I don't understand what you mean by "eventual PRs"
>
> On Mon, Oct 14, 2013 at 9:44 AM, Bartosz <mail at telenczuk.pl> wrote:
>> How about eventual PRs? Is it something you would  like to see in
>> nbviewer?
>>
>> Bartosz
>>
>> On Mon 14 Oct 2013 06:43:35 PM CEST, Brian Granger wrote:
>>> We have no immediate plans to do this.
>>>
>>> On Mon, Oct 14, 2013 at 9:36 AM, Bartosz <mail at telenczuk.pl> wrote:
>>>> Hi all,
>>>>
>>>> Is there any work in progress on using nbviewer with private repos (GH
>>>> and bitbucket)? The FAQ mentions that it's being worked on, but I did
>>>> not find anything in the issues/PRs on Github.
>>>>
>>>> BTW Bitbucket offers unlimited free private repositories for academia,
>>>> so eiht nbviewer it might become great collaboration tool.
>>>>
>>>> Cheers,
>>>>
>>>> Bartosz
>>>> _______________________________________________
>>>> IPython-dev mailing list
>>>> IPython-dev at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>
>>>
>>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
>


From ellisonbg at gmail.com  Mon Oct 14 12:58:41 2013
From: ellisonbg at gmail.com (Brian Granger)
Date: Mon, 14 Oct 2013 09:58:41 -0700
Subject: [IPython-dev] nbviewer with private repos
In-Reply-To: <525C2238.8030807@telenczuk.pl>
References: <525C1D95.3090102@telenczuk.pl>
	<CAH4pYpSwW27L++8QZHGQPzjtDvZTCXBsp7T8XF-xDD+873YJMA@mail.gmail.com>
	<525C1F73.6020509@telenczuk.pl>
	<CAH4pYpT9Luj6k+RxN2b8u3CWBBKH12ustbivo4MWnV+vcDmMtw@mail.gmail.com>
	<525C2238.8030807@telenczuk.pl>
Message-ID: <CAH4pYpQ3thwY9qj+=PoFxkc5sagCbVvUJsZn-R-8FRThodh+HQ@mail.gmail.com>

The problem with this feature is that it involves authentication with
those services, which involves *very serious* security risk that we
are not in a position to tackle at this point.

On Mon, Oct 14, 2013 at 9:56 AM, Bartosz <mail at telenczuk.pl> wrote:
> I am just asking if you would be interested in a pull request, but from
> Matthias explanation I see why that might be a non-trivial task.
> Perhaps I will try running a local copy.
>
> Thanks!
>
> Bartosz
>
> On Mon 14 Oct 2013 06:52:38 PM CEST, Brian Granger wrote:
>> I don't understand what you mean by "eventual PRs"
>>
>> On Mon, Oct 14, 2013 at 9:44 AM, Bartosz <mail at telenczuk.pl> wrote:
>>> How about eventual PRs? Is it something you would  like to see in
>>> nbviewer?
>>>
>>> Bartosz
>>>
>>> On Mon 14 Oct 2013 06:43:35 PM CEST, Brian Granger wrote:
>>>> We have no immediate plans to do this.
>>>>
>>>> On Mon, Oct 14, 2013 at 9:36 AM, Bartosz <mail at telenczuk.pl> wrote:
>>>>> Hi all,
>>>>>
>>>>> Is there any work in progress on using nbviewer with private repos (GH
>>>>> and bitbucket)? The FAQ mentions that it's being worked on, but I did
>>>>> not find anything in the issues/PRs on Github.
>>>>>
>>>>> BTW Bitbucket offers unlimited free private repositories for academia,
>>>>> so eiht nbviewer it might become great collaboration tool.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Bartosz
>>>>> _______________________________________________
>>>>> IPython-dev mailing list
>>>>> IPython-dev at scipy.org
>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>>
>>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com


From apratap at sagebase.org  Tue Oct 15 15:09:42 2013
From: apratap at sagebase.org (Abhishek Pratap)
Date: Tue, 15 Oct 2013 12:09:42 -0700
Subject: [IPython-dev] installing nbviewer on amazon ec2
Message-ID: <CAJfJrc=1Pj601nL3VcrUBfCSuY=3iBH0LWPjBTKkPHEZ-3i9Kw@mail.gmail.com>

Hey Guys

Just wondering if it is possible to install nbviewer locally outside the
heroku infrastructure. We would like to have it running on a EC2 instance.
Any pointers to the same would be of great help.

Thanks!
-Abhi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131015/87f43d6c/attachment.html>

From bussonniermatthias at gmail.com  Tue Oct 15 15:44:13 2013
From: bussonniermatthias at gmail.com (Matthias BUSSONNIER)
Date: Tue, 15 Oct 2013 21:44:13 +0200
Subject: [IPython-dev] installing nbviewer on amazon ec2
In-Reply-To: <CAJfJrc=1Pj601nL3VcrUBfCSuY=3iBH0LWPjBTKkPHEZ-3i9Kw@mail.gmail.com>
References: <CAJfJrc=1Pj601nL3VcrUBfCSuY=3iBH0LWPjBTKkPHEZ-3i9Kw@mail.gmail.com>
Message-ID: <382C1FE6-DD23-45D4-9488-013B927C6D38@gmail.com>

Hey, 

Le 15 oct. 2013 ? 21:09, Abhishek Pratap a ?crit :

> Hey Guys
> 
> Just wondering if it is possible to install nbviewer locally outside the heroku infrastructure. We would like to have it running on a EC2 instance. Any pointers to the same would be of great help.

As long has you have memcached installed and the required library, it shouldn't be harder than running on a shell


$ python gist.py

(that how I test my changes by running on localhost)

The rest like port number can be set with environment variable.
We are working on making this easier, any feedback welcomed.
-- 
M




From apratap at sagebase.org  Wed Oct 16 12:58:30 2013
From: apratap at sagebase.org (Abhishek Pratap)
Date: Wed, 16 Oct 2013 09:58:30 -0700
Subject: [IPython-dev] installing nbviewer on amazon ec2
In-Reply-To: <382C1FE6-DD23-45D4-9488-013B927C6D38@gmail.com>
References: <CAJfJrc=1Pj601nL3VcrUBfCSuY=3iBH0LWPjBTKkPHEZ-3i9Kw@mail.gmail.com>
	<382C1FE6-DD23-45D4-9488-013B927C6D38@gmail.com>
Message-ID: <CAJfJrcm0GORkpyRZ3V3qw25CXqVCxeqB8sFS4S=LrN64UdtJjA@mail.gmail.com>

Thanks for letting me know. It was a bit tricky to get the memcache to work
but it finally does. I can run the copy of nbviewer locally however I am
not sure the steps to deploy it locally at production level.

Here is what I tried so far.



1.$python app.py : returns to shell with the following message, webserver
is not started
using clasical memcached


2. python githubapp.py : ends with the following error. Flask-Cache is
installed
Traceback (most recent call last):
  File "githubapp.py", line 5, in <module>
    from flaskext.cache import Cache
ImportError: No module named cache

3. python gist.py  :starts the server but the examples on the main page
dont seem to work. I get either a 400/500 error.
using clasical memcached
debug is not activated
 * Running on http://0.0.0.0:5000/


Thanks!
-Abhi


On Tue, Oct 15, 2013 at 12:44 PM, Matthias BUSSONNIER <
bussonniermatthias at gmail.com> wrote:

> Hey,
>
> Le 15 oct. 2013 ? 21:09, Abhishek Pratap a ?crit :
>
> > Hey Guys
> >
> > Just wondering if it is possible to install nbviewer locally outside the
> heroku infrastructure. We would like to have it running on a EC2 instance.
> Any pointers to the same would be of great help.
>
> As long has you have memcached installed and the required library, it
> shouldn't be harder than running on a shell
>
>
> $ python gist.py
>
> (that how I test my changes by running on localhost)
>
> The rest like port number can be set with environment variable.
> We are working on making this easier, any feedback welcomed.
> --
> M
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131016/e5fb741a/attachment.html>

From stonerri at gmail.com  Wed Oct 16 16:38:05 2013
From: stonerri at gmail.com (Rich Stoner)
Date: Wed, 16 Oct 2013 13:38:05 -0700
Subject: [IPython-dev] notebook running in docker via dokku on digitalocean
Message-ID: <CAOG0JktfcfV_C2WsDutf3dGYsT1xzzsi+ieiwnL4BgRAsPF9Qg@mail.gmail.com>

Easily deployed ipython notebook instances in docker via dokku.

http://richstoner.github.io/blog/2013/10/16/ipython-dokku/

Still needs a lot of work but may be a useful way to spawn standalone
instances.

Best

Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131016/af91c96c/attachment.html>

From felix at fbreuer.de  Thu Oct 17 05:35:33 2013
From: felix at fbreuer.de (Felix Breuer)
Date: Thu, 17 Oct 2013 11:35:33 +0200
Subject: [IPython-dev] splitting a class definition across cells in notebook
Message-ID: <CADGimVicXzUbQXC_0xuxU5XhUBN_PmKff8M3vNqC_8O4=ReBLw@mail.gmail.com>

Hello everyone!

I am working on an IPython notebook in which I want to explain the
definition of a class in detail. (Think literate programming.) In
particular, I want to interleave the definition of the individual methods
of a class with Markdown cells explaining in detail what is going on.
However, as far as I have been able to find out, I have to put the entire
class definition in a single cell - and there is no way to amend this
definition later on. Is there any way around this?

Thanks,
Felix

-- 
http://www.felixbreuer.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131017/c27c331b/attachment.html>

From bussonniermatthias at gmail.com  Thu Oct 17 07:27:10 2013
From: bussonniermatthias at gmail.com (Matthias BUSSONNIER)
Date: Thu, 17 Oct 2013 13:27:10 +0200
Subject: [IPython-dev] splitting a class definition across cells in
	notebook
In-Reply-To: <CADGimVicXzUbQXC_0xuxU5XhUBN_PmKff8M3vNqC_8O4=ReBLw@mail.gmail.com>
References: <CADGimVicXzUbQXC_0xuxU5XhUBN_PmKff8M3vNqC_8O4=ReBLw@mail.gmail.com>
Message-ID: <F71ABEE8-517B-4718-B069-8A92701BC333@gmail.com>


Le 17 oct. 2013 ? 11:35, Felix Breuer a ?crit :

> Hello everyone!
> 
> I am working on an IPython notebook in which I want to explain the definition of a class in detail. (Think literate programming.) In particular, I want to interleave the definition of the individual methods of a class with Markdown cells explaining in detail what is going on. However, as far as I have been able to find out, I have to put the entire class definition in a single cell - and there is no way to amend this definition later on. Is there any way around this?

No there is none in the core right now. 
You could though write a Javascript extension 
that does it, but it would be a non-negligible amount of work, 
especially because you will need people to install this extension to have your notebook working.


-- 
M

> 
> Thanks,
> Felix
> 
> -- 
> http://www.felixbreuer.net
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131017/f75ffbcf/attachment.html>

From bussonniermatthias at gmail.com  Thu Oct 17 07:48:06 2013
From: bussonniermatthias at gmail.com (Matthias BUSSONNIER)
Date: Thu, 17 Oct 2013 13:48:06 +0200
Subject: [IPython-dev] Hi Matthias, wondered what the latest on ...
In-Reply-To: <CANwD8vV4f1PM8ybLTys2RoKqSubUH09pppuwLvvg3H2Tf6aP2w@mail.gmail.com>
References: <CANwD8vX2VndLCeA_OOio-SGcFWguLo6rAmxPRDTO34oqDXREMA@mail.gmail.com>
	<A69E826C-3FED-4DC4-9CF9-3FC8C695271C@gmail.com>
	<CANwD8vV4f1PM8ybLTys2RoKqSubUH09pppuwLvvg3H2Tf6aP2w@mail.gmail.com>
Message-ID: <AA1D3449-75CC-4148-8711-E00D68D8085D@gmail.com>


Le 17 oct. 2013 ? 04:46, Joshua Donnelly a ?crit :

> Thanks Matthias, for your reply and links 
> also for letting me know about the mailing list
> 
> and for your first pass at a node kernel for ipython
> basically I was following along the instuctions in 
> http://nbviewer.ipython.org/4279371/node-kernel.ipynb
> and trying to get that to work
> 
> I ran "profile create node" which did create... 
> C:/Users/Administrator/.ipython/profile_node/ipython_notebook_config.py
>  to which i added
> 
> c = get_config()
> 
> c.SubprocessKernelManager.kernel_launch_program = ['node','C:/Users/Administrator/node-kernel/kernel.js','{connection_file_name}']


Get rid of this line.
> c.MappingKernelManager.kernel_manager_class= 'IPython.zmq.subprocesskernel.SubprocessKernelManager'



> c.Session.key=''
> # which may as well be the whole file since the rest is just comments anyway
> 
> all the other instructions i tried to run exactly, i got stuck at this one
> 
> "First you will need the content of this pull request if it have not been merged yet."
> since I couldn't find  Carreau:irb "Carreau wants to merge 5 commits into ipython:master  from Carreau:rib  "

You do not need this pull request anymore. Use IPython stable without any modification, except configuration.


> so I did a completely new clone from your ipython fork
> <C:\A\Y\IPY\>clone https://github.com/Carreau/ipython.git .
> AND THEN
> [C:\A\Y\IPY\]"C:\A\Y\Canopy\Env\User\python.exe" -i "C:\A\Y\Canopy\Env\User\Scripts\pip-script.py" install -e ".[notebook]"
> to symlink and install -- and that worked!!
> 
> PS  i am back on the main dev master now, as per your email
> 
> when I ran "-m IPython notebook --profile=node" it generated a whole screed of errors 

why are you executing the module ? isn't `ipython` lowercase entry point existing ?

> so at the moment python, QT, ruby?, emacs, and web notebooks, can talk to ipython,
> but what about for an old hypertext application that just speaks ajax and jsonp, or for
> a newer browser like NodeWebKit with the full power of zeromq/sockets/and all those 
> other modules.


I think there a need to clear up the architecture. 

You have kernels : 
 - Python Kernel
 - Ruby Kernel
 - Julia Kernel
 -  Scala Kernel
 - (Node Kernel)

That speak, through ZMQ to frontend.
	- QtConsole
	- Console
	- Webserver**
 	- Vim
	- ?.

The web server is not much more that a ZMQ<-> web socket proxy that speaks with clients :
	- HTML/javascript notebook 
	- Emacs

You can then mix'n'match, i.e. Emacs-IPython-Notebook can have a ruby kernel? etc.



> what I really want to know is how to do "Hello World" from either a node context or an old browser...
> 
> Say I had the following? [...]

Older prototype of notebook were using polling and things like that, but we **need** web sockets to
push data. You can try to hack it for older browser but there are more things that will not work. 
We are really relying on new web tech to have the notebook to work.


> 
> If ipython had an http or api I could do it, similarly if it emitted jsonp that would be even better, since 
> the notebooks could be saved to disk and they would work online or offline, cross domain, 
> over BOTH file:// or http:// protocols, no sever required!!! which would be a major win.

I really don't understand what you mean there. 
Are you trying to make an In-Browser js kernel like that : 

http://nbviewer.ipython.org/5632595

> all the url rewriting makes it hard to even insert a static

What url rewriting ?

> file, I found that "custom.js" placed all the way over at, OMG... 
> C:\Users\Administrator\.ipython\profile_default\static\custom\custom.js
> worked in chrome but not in IE10, so I abandoned it in favour of "monday.txt"
> 
> <script src="{{static_url("custom/custom.js") }}" type="text/javascript" charset="utf-8"></script>
> <script src="http://127.0.0.1:89/=2/Y/Ax/1/monday.txt" ></script>

Why are you modifying templates ?

> 
> served from my local machine, but not everyone needsor wants or to have
> run another server just to add some script. In fact the whole notebook thing
> (minus the ipython eval) COULD run without a server just by addressing the 
> and coming up with some simple user/file page IDs that expanded to static 
> file locations, I could provide more info help on a way to do this if required.

I'm sorry, but I don't understand what you are trying to do. the server already serve local file under the 
file/ prefix, so you can reference files from CWD. 


> I included them a longer version of this email, but it's almost like 2 or 3 extra
> topics, and a whole list of complaints/suggestions, which are best only given
> when invited ~ because I'm sure that my issues and more you are aware of , since
> I've seen some of the conference calls/hangout sessions. I'm just saying some
> of the work I've done could help fix those pain points, and I'm happy to give an outline.

Please do, there is probably a missunderstanding and we are considering doing Live Q & A on Google
hangout. Il would be great to find a way to collect question and have user vote for what they would like to answer.

> 
> In short I just want "Hello World" run('1+1') get "2" from a  +a web browser without 
> sockets and the nodewebkit browser or a plain node.js script (via zmq)

The without socket will be the hard part from now. 
But from what I see you are not looking for a JS kernel.
You are looking for the JS client that will send request.

I don't have time now, but I'll try to have a look. 
-- 
M



From gregor.thalhammer at gmail.com  Thu Oct 17 09:42:30 2013
From: gregor.thalhammer at gmail.com (Gregor Thalhammer)
Date: Thu, 17 Oct 2013 15:42:30 +0200
Subject: [IPython-dev] splitting a class definition across cells in
	notebook
In-Reply-To: <CADGimVicXzUbQXC_0xuxU5XhUBN_PmKff8M3vNqC_8O4=ReBLw@mail.gmail.com>
References: <CADGimVicXzUbQXC_0xuxU5XhUBN_PmKff8M3vNqC_8O4=ReBLw@mail.gmail.com>
Message-ID: <E0B5870D-A20F-4099-A33D-BAD95007CB1C@gmail.com>

> Hello everyone!
> 
> I am working on an IPython notebook in which I want to explain the definition of a class in detail. (Think literate programming.) In particular, I want to interleave the definition of the individual methods of a class with Markdown cells explaining in detail what is going on. However, as far as I have been able to find out, I have to put the entire class definition in a single cell - and there is no way to amend this definition later on. Is there any way around this?

On the python side you could play some tricks, using inheritance or manually adding functions to classes to spread out the class definition across several cells. 

class A(object):
    name = 'you'
    def hi(self):
        print 'hi', self.name
a = A()
a.hi()

def ho(self):
    print 'ho', self.name
A.ho = ho
a.ho()

class A2(A):
    def ho(self):
        print 'ho', self.name

a2 = A2()
a2.ho()

Gregor



From takowl at gmail.com  Thu Oct 17 10:13:18 2013
From: takowl at gmail.com (Thomas Kluyver)
Date: Thu, 17 Oct 2013 07:13:18 -0700
Subject: [IPython-dev] splitting a class definition across cells in
	notebook
In-Reply-To: <CADGimVicXzUbQXC_0xuxU5XhUBN_PmKff8M3vNqC_8O4=ReBLw@mail.gmail.com>
References: <CADGimVicXzUbQXC_0xuxU5XhUBN_PmKff8M3vNqC_8O4=ReBLw@mail.gmail.com>
Message-ID: <CAOvn4qjG_KN0i5sBZ_vzT1+Nttvqu0Pf9zPhSDSc=DvHRyvg_Q@mail.gmail.com>

On 17 October 2013 02:35, Felix Breuer <felix at fbreuer.de> wrote:

> I am working on an IPython notebook in which I want to explain the
> definition of a class in detail. (Think literate programming.) In
> particular, I want to interleave the definition of the individual methods
> of a class with Markdown cells explaining in detail what is going on.
> However, as far as I have been able to find out, I have to put the entire
> class definition in a single cell - and there is no way to amend this
> definition later on. Is there any way around this?


One rough way to do this would be to define each method as a function, and
assign it to the class at the end of its cell. Like this:

def mymethod(self, arg):
    ...

MyClass.mymethod = mymethod

That's not ideal, but it should allow you to divide a class up into
separate cells.

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131017/f569f1f1/attachment.html>

From asmeurer at gmail.com  Thu Oct 17 12:47:14 2013
From: asmeurer at gmail.com (Aaron Meurer)
Date: Thu, 17 Oct 2013 10:47:14 -0600
Subject: [IPython-dev] splitting a class definition across cells in
	notebook
In-Reply-To: <CAOvn4qjG_KN0i5sBZ_vzT1+Nttvqu0Pf9zPhSDSc=DvHRyvg_Q@mail.gmail.com>
References: <CADGimVicXzUbQXC_0xuxU5XhUBN_PmKff8M3vNqC_8O4=ReBLw@mail.gmail.com>
	<CAOvn4qjG_KN0i5sBZ_vzT1+Nttvqu0Pf9zPhSDSc=DvHRyvg_Q@mail.gmail.com>
Message-ID: <6765108240103381009@unknownmsgid>

You could just do it the old fashioned way and use comments.

If you care about markdown formatting, what I would do is do the whole
thing in a markdown cell, with the code of the class in different code
blocks, and then define the actual thing in a code cell at the very end (or
before the markdown cell if that flows better).

Defining the class ad hoc as other people have suggested is only going to
make your complicated class even harder to understand, especially if your
audience doesn't fully understand how methods bind to classes in python.

Aaron Meurer

On Oct 17, 2013, at 8:13 AM, Thomas Kluyver <takowl at gmail.com> wrote:

On 17 October 2013 02:35, Felix Breuer <felix at fbreuer.de> wrote:

> I am working on an IPython notebook in which I want to explain the
> definition of a class in detail. (Think literate programming.) In
> particular, I want to interleave the definition of the individual methods
> of a class with Markdown cells explaining in detail what is going on.
> However, as far as I have been able to find out, I have to put the entire
> class definition in a single cell - and there is no way to amend this
> definition later on. Is there any way around this?


One rough way to do this would be to define each method as a function, and
assign it to the class at the end of its cell. Like this:

def mymethod(self, arg):
    ...

MyClass.mymethod = mymethod

That's not ideal, but it should allow you to divide a class up into
separate cells.

Thomas

_______________________________________________
IPython-dev mailing list
IPython-dev at scipy.org
http://mail.scipy.org/mailman/listinfo/ipython-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131017/8a9c8018/attachment.html>

From wstein at gmail.com  Thu Oct 17 13:01:05 2013
From: wstein at gmail.com (William Stein)
Date: Thu, 17 Oct 2013 10:01:05 -0700
Subject: [IPython-dev] splitting a class definition across cells in
	notebook
In-Reply-To: <6765108240103381009@unknownmsgid>
References: <CADGimVicXzUbQXC_0xuxU5XhUBN_PmKff8M3vNqC_8O4=ReBLw@mail.gmail.com>
	<CAOvn4qjG_KN0i5sBZ_vzT1+Nttvqu0Pf9zPhSDSc=DvHRyvg_Q@mail.gmail.com>
	<6765108240103381009@unknownmsgid>
Message-ID: <CACLE5GA+XTrshxq1de7szc7-HM6_4yPd+nS50scO9CJsDLa4AQ@mail.gmail.com>

Hi,

I'm not sure how easy this is in IPython, but you could define a new
%%mode that syntax highlights normally and instead of evaluating code,
it appends that code as a string to some variable.  Then do

[markdown]
[code cell starting with %%mode]
[markdown]
[code cell starting with %%mode]
etc.

Finally, at the end, simply exec that string.  Alternatively, append
to a file in each step, instead of a string, then exec the file at the
very end.

I don't know if IPython has a way of temporarily enabling a default
mode, but if it does you could enable it at the top of this, do
everything, then disable it at the bottom, so you don't have to
explicitly put %%mode at the top of each cell.

(I'm guessing IPython can do these things, since they're natural to
implement, and I implemented similar things in cloud.sagemath
worksheets.)

Anyway -- think of this question as a challenge for how to use/better
develop core features...

 -- William

On Thu, Oct 17, 2013 at 9:47 AM, Aaron Meurer <asmeurer at gmail.com> wrote:
> You could just do it the old fashioned way and use comments.
>
> If you care about markdown formatting, what I would do is do the whole thing
> in a markdown cell, with the code of the class in different code blocks, and
> then define the actual thing in a code cell at the very end (or before the
> markdown cell if that flows better).
>
> Defining the class ad hoc as other people have suggested is only going to
> make your complicated class even harder to understand, especially if your
> audience doesn't fully understand how methods bind to classes in python.
>
> Aaron Meurer
>
> On Oct 17, 2013, at 8:13 AM, Thomas Kluyver <takowl at gmail.com> wrote:
>
> On 17 October 2013 02:35, Felix Breuer <felix at fbreuer.de> wrote:
>>
>> I am working on an IPython notebook in which I want to explain the
>> definition of a class in detail. (Think literate programming.) In
>> particular, I want to interleave the definition of the individual methods of
>> a class with Markdown cells explaining in detail what is going on. However,
>> as far as I have been able to find out, I have to put the entire class
>> definition in a single cell - and there is no way to amend this definition
>> later on. Is there any way around this?
>
>
> One rough way to do this would be to define each method as a function, and
> assign it to the class at the end of its cell. Like this:
>
> def mymethod(self, arg):
>     ...
>
> MyClass.mymethod = mymethod
>
> That's not ideal, but it should allow you to divide a class up into separate
> cells.
>
> Thomas
>
> _______________________________________________
>
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
William Stein
Professor of Mathematics
University of Washington
http://wstein.org


From andreas at andreasbuhr.de  Thu Oct 17 14:35:18 2013
From: andreas at andreasbuhr.de (Andreas Buhr)
Date: Thu, 17 Oct 2013 20:35:18 +0200
Subject: [IPython-dev] Parallel IPython: Spawn Tasks from Tasks,
	direct scheduling
Message-ID: <52602DE6.9010807@andreasbuhr.de>

Dear IPython Community,

I have a hard time understanding the task mechanisms in parallel
IPython, maybe you can help me please?

I'd like to have lots of data lying on the workers, i.e. Python objects.
Then I'd like to call member functions of these objects, using tasks. So
I would like to have a task which says: "Go to worker A and there
execute method B on object C (which is already there)".

Is this possible with IPython?

thanks a lot in advance and best regards,
Andreas


From benjaminrk at gmail.com  Thu Oct 17 15:06:03 2013
From: benjaminrk at gmail.com (MinRK)
Date: Thu, 17 Oct 2013 12:06:03 -0700
Subject: [IPython-dev] Parallel IPython: Spawn Tasks from Tasks,
	direct scheduling
In-Reply-To: <52602DE6.9010807@andreasbuhr.de>
References: <52602DE6.9010807@andreasbuhr.de>
Message-ID: <CAHNn8BWAkHMeP8RznF32gtgSkGtTF01Bmw=dD+bpxxtgXcO2pA@mail.gmail.com>

There are two ways to do this:

   1. use parallel.Reference for the task function and/or any arguments
   2. use lambdas and rely on globals to fetch names from the interactive
   namespace

A notebook illustrating both approaches<http://nbviewer.ipython.org/7030408>

-MinRK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131017/583ea871/attachment.html>

From andreas at andreasbuhr.de  Thu Oct 17 15:16:17 2013
From: andreas at andreasbuhr.de (Andreas Buhr)
Date: Thu, 17 Oct 2013 21:16:17 +0200
Subject: [IPython-dev] Parallel IPython: Spawn Tasks from Tasks,
 direct scheduling
In-Reply-To: <CAHNn8BWAkHMeP8RznF32gtgSkGtTF01Bmw=dD+bpxxtgXcO2pA@mail.gmail.com>
References: <52602DE6.9010807@andreasbuhr.de>
	<CAHNn8BWAkHMeP8RznF32gtgSkGtTF01Bmw=dD+bpxxtgXcO2pA@mail.gmail.com>
Message-ID: <52603781.8010805@andreasbuhr.de>

Hi,

wow, thanks a lot for your help, that's great.

On 10/17/2013 09:06 PM, MinRK wrote:
> A notebook illustrating both approaches
> <http://nbviewer.ipython.org/7030408>

>From inside of those member functions, can I spawn new tasks? Can I just
get a new 'Client()', even when I am on a worker?

And if I spawn a new task on a worker, and that new task is to be
executed on the exact same machine, is there a way to execute that task
without going back to the HUB/scheduler?

thanks a lot again,
best regards,
Andreas



From benjaminrk at gmail.com  Thu Oct 17 15:20:31 2013
From: benjaminrk at gmail.com (MinRK)
Date: Thu, 17 Oct 2013 12:20:31 -0700
Subject: [IPython-dev] Parallel IPython: Spawn Tasks from Tasks,
	direct scheduling
In-Reply-To: <52603781.8010805@andreasbuhr.de>
References: <52602DE6.9010807@andreasbuhr.de>
	<CAHNn8BWAkHMeP8RznF32gtgSkGtTF01Bmw=dD+bpxxtgXcO2pA@mail.gmail.com>
	<52603781.8010805@andreasbuhr.de>
Message-ID: <CAHNn8BW3M+6VqPpQpHd0924JZ2g1Q9wdCMF+Q6CQAJfixxRO3g@mail.gmail.com>

On Thu, Oct 17, 2013 at 12:16 PM, Andreas Buhr <andreas at andreasbuhr.de>wrote:

> Hi,
>
> wow, thanks a lot for your help, that's great.
>
> On 10/17/2013 09:06 PM, MinRK wrote:
> > A notebook illustrating both approaches
> > <http://nbviewer.ipython.org/7030408>
>
> >From inside of those member functions, can I spawn new tasks? Can I just
> get a new 'Client()', even when I am on a worker?
>

You can create a client and submit new tasks from there,
though there can be hazards associated with that in terms of the number of
sockets created.


>
> And if I spawn a new task on a worker, and that new task is to be
> executed on the exact same machine, is there a way to execute that task
> without going back to the HUB/scheduler?
>

If you spawn new tasks, they are submitted in exactly the same way as all
other tasks via the scheduler. If you want it to run on the same machine
that's submitting the task, why not just call the function directly?

-MinRK


>
> thanks a lot again,
> best regards,
> Andreas
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131017/7512d027/attachment.html>

From andreas at andreasbuhr.de  Thu Oct 17 15:34:49 2013
From: andreas at andreasbuhr.de (Andreas Buhr)
Date: Thu, 17 Oct 2013 21:34:49 +0200
Subject: [IPython-dev] Parallel IPython: Spawn Tasks from Tasks,
 direct scheduling
In-Reply-To: <CAHNn8BW3M+6VqPpQpHd0924JZ2g1Q9wdCMF+Q6CQAJfixxRO3g@mail.gmail.com>
References: <52602DE6.9010807@andreasbuhr.de>	<CAHNn8BWAkHMeP8RznF32gtgSkGtTF01Bmw=dD+bpxxtgXcO2pA@mail.gmail.com>	<52603781.8010805@andreasbuhr.de>
	<CAHNn8BW3M+6VqPpQpHd0924JZ2g1Q9wdCMF+Q6CQAJfixxRO3g@mail.gmail.com>
Message-ID: <52603BD9.5090601@andreasbuhr.de>

Hi MinRK,

On 10/17/2013 09:20 PM, MinRK wrote:
> 
>     And if I spawn a new task on a worker, and that new task is to be
>     executed on the exact same machine, is there a way to execute that task
>     without going back to the HUB/scheduler?
> 
> 
> If you spawn new tasks, they are submitted in exactly the same way as
> all other tasks via the scheduler. If you want it to run on the same
> machine that's submitting the task, why not just call the function directly?

Because I would like to have also task priorities and there might be
tasks with higher priority waiting. Are there task priorities in IPython?
Also because I would not like the task spawner to know where the task
will be executed. At the end, I'd like to say "Call function A on object
B with arguments C", and the system I am about to create should carry
the task to B's home and execute it there. And it should not go over the
wire if B happen to live on the same machine.

Thanks again for your help :-)

best regards,
Andreas



From benjaminrk at gmail.com  Thu Oct 17 16:18:00 2013
From: benjaminrk at gmail.com (MinRK)
Date: Thu, 17 Oct 2013 13:18:00 -0700
Subject: [IPython-dev] Parallel IPython: Spawn Tasks from Tasks,
	direct scheduling
In-Reply-To: <52603BD9.5090601@andreasbuhr.de>
References: <52602DE6.9010807@andreasbuhr.de>
	<CAHNn8BWAkHMeP8RznF32gtgSkGtTF01Bmw=dD+bpxxtgXcO2pA@mail.gmail.com>
	<52603781.8010805@andreasbuhr.de>
	<CAHNn8BW3M+6VqPpQpHd0924JZ2g1Q9wdCMF+Q6CQAJfixxRO3g@mail.gmail.com>
	<52603BD9.5090601@andreasbuhr.de>
Message-ID: <CAHNn8BXzCVN+MQA6gcWa5yemOCdQ_OtzhEWaWZ0HM-HqqrkHLQ@mail.gmail.com>

That's interesting.  If you are doing engine assignment yourself, I would
probably say that you should have that logic at a level slightly higher
than IPython.  Then on task submission, you can call out to a function
directly if your code determines that it should be run locally rather than
submitted via IPython.


On Thu, Oct 17, 2013 at 12:34 PM, Andreas Buhr <andreas at andreasbuhr.de>wrote:

> Hi MinRK,
>
> On 10/17/2013 09:20 PM, MinRK wrote:
> >
> >     And if I spawn a new task on a worker, and that new task is to be
> >     executed on the exact same machine, is there a way to execute that
> task
> >     without going back to the HUB/scheduler?
> >
> >
> > If you spawn new tasks, they are submitted in exactly the same way as
> > all other tasks via the scheduler. If you want it to run on the same
> > machine that's submitting the task, why not just call the function
> directly?
>
> Because I would like to have also task priorities and there might be
> tasks with higher priority waiting. Are there task priorities in IPython?
> Also because I would not like the task spawner to know where the task
> will be executed. At the end, I'd like to say "Call function A on object
> B with arguments C", and the system I am about to create should carry
> the task to B's home and execute it there. And it should not go over the
> wire if B happen to live on the same machine.
>
> Thanks again for your help :-)
>
> best regards,
> Andreas
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131017/5c163911/attachment.html>

From mcburton at gmail.com  Thu Oct 17 16:55:54 2013
From: mcburton at gmail.com (mcburton)
Date: Thu, 17 Oct 2013 16:55:54 -0400
Subject: [IPython-dev] IPython Notebooks, dissertations,
	and scholarly publication
Message-ID: <CA+0EHHr8UPpNYb2GRV3KmEFfoumKgBQSCkH52yGrqB-E6v1fTQ@mail.gmail.com>

Hello,

I am on a panel discussion tomorrow morning talking about "digital
dissertations" (broadly construed) and I was going to bring up the IPython
Notebook as not only a platform for interactive computing, but the Notebook
specifically as an emerging genre of scholarship in and of itself.

We have already seen published Notebooks being used for teaching
programming[1], as supplementary materials for a book[2], and even as a
platform for the book itself[3]. I  toying with ways to similarly integrate
the notebook into my dissertation (most likely as supplementary material on
Github due to institutional formatting constraints). But it would be
interesting to ruminate about the possibility of submitting a Notebook (or
set of Notebooks) to my committee.

I was wondering if there is anyone on this list who has similarly explored,
if only in your imagination, the IPython Notebook as a platform for
dissertations or, to be even more provocative, as a platform for scholarly
publishing more generally[4]?

I've been spreading the IPython Notebook gospel in various conversations
about new modes scholarly communication/publishing and people get very
excited. I'd love to hear what folks on ipython-dev think.

--
mcb


[1]
http://peak5390.wordpress.com/2013/09/22/how-ipython-notebook-and-github-have-changed-the-way-i-teach-python/

[2] https://github.com/ptwobrussell/Mining-the-Social-Web-2nd-Edition

[3]
http://camdavidsonpilon.github.io/Probabilistic-Programming-and-Bayesian-Methods-for-Hackers/

[4]
https://github.com/ipython/ipython/wiki/A-gallery-of-interesting-IPython-Notebooks#-reproducible-academic-publications
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131017/60ce316b/attachment.html>

From gmbecker at ucdavis.edu  Thu Oct 17 18:03:01 2013
From: gmbecker at ucdavis.edu (Gabriel Becker)
Date: Thu, 17 Oct 2013 15:03:01 -0700
Subject: [IPython-dev] IPython Notebooks, dissertations,
	and scholarly publication
In-Reply-To: <CA+0EHHr8UPpNYb2GRV3KmEFfoumKgBQSCkH52yGrqB-E6v1fTQ@mail.gmail.com>
References: <CA+0EHHr8UPpNYb2GRV3KmEFfoumKgBQSCkH52yGrqB-E6v1fTQ@mail.gmail.com>
Message-ID: <CADwqtCMiuy9Jb0_p_zZ-+83M3+Q4rS7KCGh8+Y70r4Cy_Kos_g@mail.gmail.com>

Matt,

Disclaimer: I'm not on the IPython core team and I don't claim to represent
the views of the team or any particular member therein. I am, however,
doing my thesis on systems for creating, processing, and displaying
documents which capture and convey the research process for data analytic
research, so I've thought about this topic a bit.

The concept of executable journal articles and repeatability (I use this
term instead of "reproducibility" for a very specific reason which I will
get to later length permitting) in "in silico" research is an exciting one
which has been getting a good amount of attention lately [1] [2]

IPython has quite a bit of potential in this arena but IMO more as a
submission format and downloadable form for papers rather than the default
viewing mechanism for them. One reason that I say this is that while the
availability of the exact code used to run the analysis described in a
paper is *extremely* important, in many contexts its actually pretty
detrimental for every single line of code to appear in an article as it is
being read (this does not include some situations where the intended
purpose is to teach coding or which require full display of the code for
other reasons).

nbconvert gives us a way around this by allowing us to generate a concise
static view containing only the text and code we actually want to show (ie
an article pdf/HTML page), but we lose the interactivity. Furthermore, if
we want to distribute the ipynb and allow people to run it then generate
the static article view themselves (we do), we need to distribute the
nbconvert filter as well, which loses us the "everything contained in a
single file" benefit.

The paradigm wherein documents are used to *generate* articles rather than
*being* the articles themselves is actually an extremely powerful one. It
allows us to, potentially, move beyond the ability to regenerate
*results*(repeatability) towards being able to reproduce
*research* (reproducibility). To quote  AJ Rossini from an embarassingly
long time ago [3]

The resulting document should provide a clear description of the paths
taken during the analyses to produce the working dataset, descriptive,
exploratory, and con firmatory analyses. This should describe results and
lessons learned, both substantiative and for statistical practice, as well
as *a means to reproduce all steps, even those not used in a
concise**reconstruction, which were taken in the analysis
*

(emphasis mine).

That, however, is a discussion for another time (and has to a large extent
already happened on this list with respect to IPython specifically).

Getting back to the more immediate subject, I think its great that you're
thinking of having your thesis be a notebook. I think there are a large
number of benefits to doing so even if you end up needing to use nbconvert
to generate a concise "readable" version for publication or submission to
your committee.

~G

[1] http://www.executablepapers.com/

[2]
http://www.vistrails.org/index.php/Main_Page#Publishing_Reproducible_Results

[3] http://www.r-project.org/conferences/DSC-2001/Proceedings/Rossini.pdf


On Thu, Oct 17, 2013 at 1:55 PM, mcburton <mcburton at gmail.com> wrote:

> Hello,
>
> I am on a panel discussion tomorrow morning talking about "digital
> dissertations" (broadly construed) and I was going to bring up the IPython
> Notebook as not only a platform for interactive computing, but the Notebook
> specifically as an emerging genre of scholarship in and of itself.
>
> We have already seen published Notebooks being used for teaching
> programming[1], as supplementary materials for a book[2], and even as a
> platform for the book itself[3]. I  toying with ways to similarly integrate
> the notebook into my dissertation (most likely as supplementary material on
> Github due to institutional formatting constraints). But it would be
> interesting to ruminate about the possibility of submitting a Notebook (or
> set of Notebooks) to my committee.
>
> I was wondering if there is anyone on this list who has similarly
> explored, if only in your imagination, the IPython Notebook as a platform
> for dissertations or, to be even more provocative, as a platform for
> scholarly publishing more generally[4]?
>
> I've been spreading the IPython Notebook gospel in various conversations
> about new modes scholarly communication/publishing and people get very
> excited. I'd love to hear what folks on ipython-dev think.
>
> --
> mcb
>
>
> [1]
> http://peak5390.wordpress.com/2013/09/22/how-ipython-notebook-and-github-have-changed-the-way-i-teach-python/
>
> [2] https://github.com/ptwobrussell/Mining-the-Social-Web-2nd-Edition
>
> [3]
> http://camdavidsonpilon.github.io/Probabilistic-Programming-and-Bayesian-Methods-for-Hackers/
>
> [4]
> https://github.com/ipython/ipython/wiki/A-gallery-of-interesting-IPython-Notebooks#-reproducible-academic-publications
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>


-- 
Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131017/2795b740/attachment.html>

From rgbkrk at gmail.com  Thu Oct 17 18:33:47 2013
From: rgbkrk at gmail.com (Kyle Kelley)
Date: Thu, 17 Oct 2013 17:33:47 -0500
Subject: [IPython-dev] installing nbviewer on amazon ec2
In-Reply-To: <CAJfJrcm0GORkpyRZ3V3qw25CXqVCxeqB8sFS4S=LrN64UdtJjA@mail.gmail.com>
References: <CAJfJrc=1Pj601nL3VcrUBfCSuY=3iBH0LWPjBTKkPHEZ-3i9Kw@mail.gmail.com>
	<382C1FE6-DD23-45D4-9488-013B927C6D38@gmail.com>
	<CAJfJrcm0GORkpyRZ3V3qw25CXqVCxeqB8sFS4S=LrN64UdtJjA@mail.gmail.com>
Message-ID: <CA+tbMaXhBNQzT=US3-ksvmxeJ+GQowA3+Dv8_VuYn7=fcMMaMg@mail.gmail.com>

Abhi,

If you're comfortable using salt, there are salt states for deploying
nbviewer (https://github.com/rgbkrk/salt-nbviewer). Currently this installs
straight from the master branch of nbviewer. In the near future, this will
have branch/environment setup to deploy to qa, staging and production
servers.

If you're not comfortable with salt, it serves as a good reference for
which packages to install, how to set up the virtualenv, working
configurations for both supervisor and memcache. top.sls shows the order (
https://github.com/rgbkrk/salt-nbviewer/blob/master/top.sls), follow that
up with the init.sls files in each of the directories. If you'd like more
detail than this, I could probably be convinced to write something up.

-- Kyle


On Wed, Oct 16, 2013 at 11:58 AM, Abhishek Pratap <apratap at sagebase.org>wrote:

> Thanks for letting me know. It was a bit tricky to get the memcache to
> work but it finally does. I can run the copy of nbviewer locally however I
> am not sure the steps to deploy it locally at production level.
>
> Here is what I tried so far.
>
>
>
> 1.$python app.py : returns to shell with the following message, webserver
> is not started
> using clasical memcached
>
>
> 2. python githubapp.py : ends with the following error. Flask-Cache is
> installed
> Traceback (most recent call last):
>   File "githubapp.py", line 5, in <module>
>     from flaskext.cache import Cache
> ImportError: No module named cache
>
> 3. python gist.py  :starts the server but the examples on the main page
> dont seem to work. I get either a 400/500 error.
> using clasical memcached
> debug is not activated
>  * Running on http://0.0.0.0:5000/
>
>
> Thanks!
> -Abhi
>
>
> On Tue, Oct 15, 2013 at 12:44 PM, Matthias BUSSONNIER <
> bussonniermatthias at gmail.com> wrote:
>
>> Hey,
>>
>> Le 15 oct. 2013 ? 21:09, Abhishek Pratap a ?crit :
>>
>> > Hey Guys
>> >
>> > Just wondering if it is possible to install nbviewer locally outside
>> the heroku infrastructure. We would like to have it running on a EC2
>> instance. Any pointers to the same would be of great help.
>>
>> As long has you have memcached installed and the required library, it
>> shouldn't be harder than running on a shell
>>
>>
>> $ python gist.py
>>
>> (that how I test my changes by running on localhost)
>>
>> The rest like port number can be set with environment variable.
>> We are working on making this easier, any feedback welcomed.
>> --
>> M
>>
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131017/1a025829/attachment.html>

From takowl at gmail.com  Thu Oct 17 20:04:31 2013
From: takowl at gmail.com (Thomas Kluyver)
Date: Thu, 17 Oct 2013 17:04:31 -0700
Subject: [IPython-dev] IPython Notebooks, dissertations,
	and scholarly publication
In-Reply-To: <CA+0EHHr8UPpNYb2GRV3KmEFfoumKgBQSCkH52yGrqB-E6v1fTQ@mail.gmail.com>
References: <CA+0EHHr8UPpNYb2GRV3KmEFfoumKgBQSCkH52yGrqB-E6v1fTQ@mail.gmail.com>
Message-ID: <CAOvn4qjmem33fKmUAh_P36jE5ask6Xz_0HpAV-x96d9sMf7Vpw@mail.gmail.com>

I know someone wrote their thesis in sphinx - google sphinx thesis
resource. You could probably integrate notebooks into that via nbconvert,
though the output is then essentially static documents.

Thomas
On Oct 17, 2013 3:55 PM, "mcburton" <mcburton at gmail.com> wrote:

> Hello,
>
> I am on a panel discussion tomorrow morning talking about "digital
> dissertations" (broadly construed) and I was going to bring up the IPython
> Notebook as not only a platform for interactive computing, but the Notebook
> specifically as an emerging genre of scholarship in and of itself.
>
> We have already seen published Notebooks being used for teaching
> programming[1], as supplementary materials for a book[2], and even as a
> platform for the book itself[3]. I  toying with ways to similarly integrate
> the notebook into my dissertation (most likely as supplementary material on
> Github due to institutional formatting constraints). But it would be
> interesting to ruminate about the possibility of submitting a Notebook (or
> set of Notebooks) to my committee.
>
> I was wondering if there is anyone on this list who has similarly
> explored, if only in your imagination, the IPython Notebook as a platform
> for dissertations or, to be even more provocative, as a platform for
> scholarly publishing more generally[4]?
>
> I've been spreading the IPython Notebook gospel in various conversations
> about new modes scholarly communication/publishing and people get very
> excited. I'd love to hear what folks on ipython-dev think.
>
> --
> mcb
>
>
> [1]
> http://peak5390.wordpress.com/2013/09/22/how-ipython-notebook-and-github-have-changed-the-way-i-teach-python/
>
> [2] https://github.com/ptwobrussell/Mining-the-Social-Web-2nd-Edition
>
> [3]
> http://camdavidsonpilon.github.io/Probabilistic-Programming-and-Bayesian-Methods-for-Hackers/
>
> [4]
> https://github.com/ipython/ipython/wiki/A-gallery-of-interesting-IPython-Notebooks#-reproducible-academic-publications
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131017/d17461c6/attachment.html>

From moorepants at gmail.com  Thu Oct 17 23:51:40 2013
From: moorepants at gmail.com (Jason Moore)
Date: Thu, 17 Oct 2013 23:51:40 -0400
Subject: [IPython-dev] IPython Notebooks, dissertations,
	and scholarly publication
In-Reply-To: <CAOvn4qjmem33fKmUAh_P36jE5ask6Xz_0HpAV-x96d9sMf7Vpw@mail.gmail.com>
References: <CA+0EHHr8UPpNYb2GRV3KmEFfoumKgBQSCkH52yGrqB-E6v1fTQ@mail.gmail.com>
	<CAOvn4qjmem33fKmUAh_P36jE5ask6Xz_0HpAV-x96d9sMf7Vpw@mail.gmail.com>
Message-ID: <CAP7f1Ag7gS72vXrZustMnS+6yMADEm8wc7tk7vFf1N1i2Lmwsg@mail.gmail.com>

I wrote my dissertation as a Sphinx document:
moorepants.github.io/dissertation. The source to generate most of the
figures was included with the Sphinx source. The IPython notebook wasn't an
option at the time, but I would have certainly considered it for
distributing some of the calculations. There is a more formal package for
using Sphinx for a thesis here: https://github.com/jterrace/sphinxtr.
Notebooks could be integrated into the Sphinx output.


Jason
moorepants.info
+01 530-601-9791


On Thu, Oct 17, 2013 at 8:04 PM, Thomas Kluyver <takowl at gmail.com> wrote:

> I know someone wrote their thesis in sphinx - google sphinx thesis
> resource. You could probably integrate notebooks into that via nbconvert,
> though the output is then essentially static documents.
>
> Thomas
> On Oct 17, 2013 3:55 PM, "mcburton" <mcburton at gmail.com> wrote:
>
>> Hello,
>>
>> I am on a panel discussion tomorrow morning talking about "digital
>> dissertations" (broadly construed) and I was going to bring up the IPython
>> Notebook as not only a platform for interactive computing, but the Notebook
>> specifically as an emerging genre of scholarship in and of itself.
>>
>> We have already seen published Notebooks being used for teaching
>> programming[1], as supplementary materials for a book[2], and even as a
>> platform for the book itself[3]. I  toying with ways to similarly integrate
>> the notebook into my dissertation (most likely as supplementary material on
>> Github due to institutional formatting constraints). But it would be
>> interesting to ruminate about the possibility of submitting a Notebook (or
>> set of Notebooks) to my committee.
>>
>> I was wondering if there is anyone on this list who has similarly
>> explored, if only in your imagination, the IPython Notebook as a platform
>> for dissertations or, to be even more provocative, as a platform for
>> scholarly publishing more generally[4]?
>>
>> I've been spreading the IPython Notebook gospel in various conversations
>> about new modes scholarly communication/publishing and people get very
>> excited. I'd love to hear what folks on ipython-dev think.
>>
>> --
>> mcb
>>
>>
>> [1]
>> http://peak5390.wordpress.com/2013/09/22/how-ipython-notebook-and-github-have-changed-the-way-i-teach-python/
>>
>> [2] https://github.com/ptwobrussell/Mining-the-Social-Web-2nd-Edition
>>
>> [3]
>> http://camdavidsonpilon.github.io/Probabilistic-Programming-and-Bayesian-Methods-for-Hackers/
>>
>> [4]
>> https://github.com/ipython/ipython/wiki/A-gallery-of-interesting-IPython-Notebooks#-reproducible-academic-publications
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131017/2702a23d/attachment.html>

From adgaudio at gmail.com  Thu Oct 17 23:54:13 2013
From: adgaudio at gmail.com (Alex Gaudio)
Date: Thu, 17 Oct 2013 23:54:13 -0400
Subject: [IPython-dev]  IPython Parallel: Dealing with code changes
Message-ID: <CA+Oo3s0GericXEGPL4gMWhMuNPocL2MLrEvdhU1=gJ8_Nf5f0g@mail.gmail.com>

Hello,

Thanks everyone for building such a great tool!  I have a question about
how one should deal with code changes when using IPython parallel.

The general problem I have is this:  I run several deal tasks continuously
on IPython engines, and I'm also constantly pushing code changes to the
machines running my IPython parallel cluster(s).  How should I architect my
system such that the engines handle code changes?

Here are a couple solutions that seem like good ideas but aren't to my
knowledge currently possible (please correct me if I'm wrong!):

   - When a certain event happens (such as a code deploy), have all
   existing engines restart themselves after they finish their currently
   executing task.  The engines will then run all outstanding jobs using the
   new code base.  More specifically, the first few of those pending jobs will
   execute with an engine that hasn't imported any code yet.
   - The other option I could see:  Execute the tasks with an option that
   tells the engine to treat the tasks as a proper python process so that:  1)
   things like sys.exitfunc() are triggered properly when the task ends, and
   2) imported modules are actually imported for the first time.  Regarding
   2), I know that currently, we can just import modules inside a function
   call (ie view.apply(my_func_with_imports) ), but if the modules loaded by
   the engine have any globally modified state, that modified state persists
   across tasks.  This has bitten me quite a few times.

I believe both of these options can also be solved with a soft restart of
the engines, but client.shutdown(targets=[...], restart=True) is currently
NotImplemented.

To work around the problem, I basically implemented a soft ipcluster
restart:  Whenever I deploy new code to the machines, I simply start a new
ipython cluster on the machines, and I distinguish these clusters using the
--cluster-id option.  (This is via a (significantly) modified version of
the default StarCluster IPython plugin).  This plugin lets the old
ipcluster complete it's queue (and then it eventually gets shut down), and
all new incoming tasks go to the new ipcluster.  This work around was
great, but we are starting to deploy code more frequently, which means that
there are multiple ipcluster instances on our machines at any given time,
and I foresee two problems:  Multiple ipcluster instances on the same nodes
means the engines will begin competing for the limited cpu resources on one
node; And having multiple different task queues does make it a bit annoying
to keep track of which job is associated to which ipcluster, and it's also
difficult to know how many jobs are queued in general.

Do you have any suggestions as to what approach I should take?  I would be
happy to work on a PR to support client.shutdown(restart=True) if you think
that is a good way to solve this problem, but I'd also like to know what
that PR would require, as I'm only slightly familiar with the
IPython.parallel code base.

Thank you in advance for your input!
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131017/d1b7f163/attachment.html>

From bussonniermatthias at gmail.com  Fri Oct 18 04:07:37 2013
From: bussonniermatthias at gmail.com (Matthias BUSSONNIER)
Date: Fri, 18 Oct 2013 10:07:37 +0200
Subject: [IPython-dev] thanks for outlining the architecture:
In-Reply-To: <CANwD8vU+wAZiSMszVYV8o8rOJrCF5Ru6M_=trwKR_0SZsY79wA@mail.gmail.com>
References: <CANwD8vU+wAZiSMszVYV8o8rOJrCF5Ru6M_=trwKR_0SZsY79wA@mail.gmail.com>
Message-ID: <ED2AEE4B-E0FD-4F6D-B412-8581D779EEA2@gmail.com>


Le 18 oct. 2013 ? 03:54, Joshua Donnelly a ?crit :

> I learnt a few more things, and made some progress, mainly
> SOME GOOD NEWS is back on dev master, with that ipython_notebook_config.py line removed
> as you suggested... "C:\A\Y\Canopy\Env\User\python.exe" -m IPython notebook --profile=node
> NOW starts the notebook server!! (repeated below with notes, since the test code
> ["hello from "," to IPython Notebook"].join("Node.js") just runs with errors)
> 
> I cc'd to ipython-dev at scipy.org but no response,

That happen, you can also reply only to dev-list, I'm on it and will continue to respond. 
activity on list comes and goes. maybe the already started discussion and long mail 
saved some peoples.


> 
> Still stuck at Hello World (from a browser or node context with or without sockets)
> but that's okay for now, thanks so much for your replies (re time constraints
> don't worry about a reply here, I will try to catch up with you on the public 
> Q&A session if that eventuates) and will start just posting to  ipython-dev at scipy.org
> 
> True, I don't need a node kernel (but the code there would provide a starting point),
> to make the simplest node or browser (sockets or no sockets) client script that talks to ipython.  
> ie. "ipython hello world" from IE6, node.js, or chrome canary -- any of those would be a good start 

(I would give up IE6 for now)

> 
> There we're some questions about what I was doing in your last email, the
> stuff below answers those mainly, 
> (Answer) RE: Are you trying to make an In-Browser js kernel like http://nbviewer.ipython.org/5632595? No
> (Answer) RE: why "python.exe -m IPython" and not "python.exe ipython" ? I'm just trying to do what works.

There should be ipython.exe entry point (usually)

Can't tell you exactly haven't use windows in years.

> (Answer) RE: why are you editing the templates? I am editing the templates because that is the true source of the notebook html page, no? 

Yes but you shouldn't have to edit that to inject stuff, (but it is true it is easier)

> (Answer) RE: url rewriting? The url rewriting i was referring to was the static_url() calls and MathJax shenanigins, where
> the server is required to merge files from multiple "static" locations? 

Don't try to mess-up with mathjax, it works without it. 
as for the static_url() it is mostly use on server side when IPython is runned under a prefix. 
usually it only append /static/ at the beginning of url relative to root. 
The merging of static dir is a convenience, it is *just* a search path.

> 
> I was pleased to hear about all those kernels, and wanted to know how to get them all running at once and how to reference a particular on in a notebook cell?
> would it be as easy as saying "language":"ruby" , in a ipynb cell. I mean the notebook select menu doesn't have options for them. Is there a git branch that includes them all for use/testing? as they don't appear to be in the main dev repo, maybe they are just floating around out there (if I search for "Julia" in C:\A\Y\IPY it doesn't show any files) and so far I haven't seen any of the extra kernels working, and trying to do so, has not been easy or fun.

You cannot on a per cell basis, and we don't have any short term, nor long term plan to add this on a per cell basis.
We will add ways to do that on a per-notebook basis, but not yet. 

Right now, you have to run many server, each 'bind' to a language. 

if you install julia you can do in Julia:

Julia> Pkg.add("IJulia")

and it will download lot of stuff, install a python profile. 
then you can actually start IPython-with-julia-kernel with 
$ ipython notebook --profile=julia

you can also do 

$ gem install iruby
then
$ iruby notebook 
under the hood it does `ipython notebook --profile=ruby`

In best cases it should work out of the box, but theses are both pretty recent projects.

> which is like wow, that's REALLY cool,
> how does one reference a target language/kernel in myfile.ipynb cell? 
> can they all be running at once? or is it just going to use the one
> specified at  -m IPython notebook --profile=xxxx for everything

Yes for now, it is on a per profile

> {
>      "language": "python",
>      "metadata": {},
>      "outputs": [ ?

The language will be moved at a top level key soon. 
 
> maybe python is following the of the folder path (case sensitive like unix not windows)
> C:\A\Y\IPY\IPython that was made when I cloned the repo. -m is not my choice
> it just seems to be what works since IPython is a pure script and not an executable.

python.exe -m 
Run the module, but there should be a IPython entry point installed on windows
you shouldn't have to run the module but if it works...


> 
> 
> I had the command: 
> "C:\A\Y\Canopy\Env\User\python.exe" -i "C:\A\Y\Canopy\Env\User\Scripts\pip-script.py" install -e ".[notebook]"
> that I thought installed and symlinked ipython
> 
> SOME GOOD NEWS is back on dev master, with that ipython_notebook_config.py line removed
> as you suggested... "C:\A\Y\Canopy\Env\User\python.exe" -m IPython notebook --profile=node
> 
> NOW starts the notebook server!!



> 
> _______________________________________________________________
> C:/Users/Administrator/.ipython/profile_node/ipython_notebook_config.py
> _______________________________________________________________
> # Configuration file for ipython-notebook.
> c = get_config()
> c.SubprocessKernelManager.kernel_launch_program = ['node','C:/Users/Administrator/node-kernel/kernel.js','{connection_file_name}']
> c.Session.key=''
> ________________________________________________________________

Sorry my fault I read too fast, and mixed and match old and new config:

try the following

_______________________________________________________________
C:/Users/Administrator/.ipython/profile_node/ipython_notebook_config.py
_______________________________________________________________
# Configuration file for ipython-notebook.
c = get_config()
c.KernelManager.kernel_cmd = ['node','C:/Users/Administrator/node-kernel/kernel.js','{connection_file}']
c.Session.key=''
________________________________________________________________

Usually the
 c.XxxxxxYyyyy.mmmm_nnnn =
should already exist in the file and just be commented.

> 
> and at least the test code shows something...
> 
> ["hello from "," to IPython Notebook"].join("Node.js")
> ---------------------------------------------------------------------------
> AttributeError                            Traceback (most recent call last)
> <ipython-input-1-9dad664227a0> in <module>()
> ----> 1 ["hello from "," to IPython Notebook"].join("Node.js")
> 
> AttributeError: 'list' object has no attribute 'join'

Seeing a python traceback hint that you are using a python kernel above instruction should fix that.

> _________________________________________________________________
> (Answer) RE: why are you editing the templates? I am editing the templates because that is the true source of the notebook html page, no? 
> (Answer) RE: url rewriting? the url rewriting i was referring to was the static_url() calls and MathJax shenanigins, where
> the server is required to merge files from multiple "static" locations... 
>  
> i did a little test and writting plain href="./static/yes.htm" file references are easier now
> (once one understands what ipy is doing, which I don't) 

Basicaly everything in notebook-webserver-search-path is served under ./static/*.
it is slightly more complicated, but for a first approach it should be ok/



> _________________________________________________________________________
> C:\Users\Administrator\.ipython\profile_default\static\user_hello.htm
> C:\A\Y\IPY\IPython\html\static\yes.htm
> <h1>{{static_url("hello.htm") }}</h1>
> <br><a href={{static_url("user_hello.htm") }} >./static/user_hello.htm ~ via static_url()</a>
> <br><a href="./static/user_hello.htm"} >./static/user_hello.htm</a>
> <br><a href="./static/yes.htm"} >./static/yes.htm</a>
> _________________________________________________________________________
> 
> 
> ===============================================================================
> 
> Trying to make https://github.com/minrk/profile_jskernel work:
> 
> instructions "the run a javascript kernel in-browser instead of remote via websockets, just clone this repo into your IPython directory, and use it with
> ipython notebook --profile jskernel"
> 
> which also the nb file, also at http://nbviewer.ipython.org/5632595 
> 
> which I saved as"C:\A\Y\IPY\examples\notebooks\JSS.ipynb" and ran 
> python -m IPython notebook --profile=jskernel
> which is quite different than the "ipython notebook --profile jskernel" command given at  minrk/profile_jskernel github 
> which will not work on windows since there are exactly zero exe/cmd/
> and only 1 make.bat file in the main IPY/IPython/ repo cloned from github,
> and the pip ipython notebook install added nothing to the system.path anyway 

So this is weird. It should have I guess.

> 
> the notebook app did open, but not the JSS.ipynb file instead I got a nice web prompt saying "Error loading notebook:An unknown error occurred while loading this notebook. This version can load notebook formats v3 or earlier." someone ought to tell people to save it as utf-8 without a BOM, (and why can't ipython notebook can't handle both?) so then it opens in notebook, and I try Math.random()

We should handle both, but with few windows user, we have few bug report. 
If you can reproduce please open a bug ticket.

> 
> {
>      "cell_type": "markdown",
>      "metadata": {},
>      "source": [
>       "With [this profile](
> https://github.com/minrk/profile_jskernel
> ),\n",
>       "kernel.js is replaced by a simple object that executes javascript in the browser rather than remotely via websockets.\n",
>       "\n",
>       "This is more of a toy / proof of concept than anything."
>      ]
>     },
>     {
>      "cell_type": "code",
>      "collapsed": false,
>      "input": [
>       "Math.random()"
>      ],
>      "language": "python",
>      "metadata": {},
>      "outputs": [
>       {
>        "ename": "NameError",
>        "evalue": "name 'Math' is not defined",
>        "output_type": "pyerr",
>        "traceback": [
>         "\u001b[1;31m---------------------------------------------------------------------------\u001b[0m\n\u001b[1;31mNameError\u001b[0m                                 Traceback (most recent call last)",
>         "\u001b[1;32m<ipython-input-1-5edbfbed6442>\u001b[0m in \u001b[0;36m<module>\u001b[1;34m()\u001b[0m\n\u001b[1;32m----> 1\u001b[1;33m \u001b[0mMath\u001b[0m\u001b[1;33m.\u001b[0m\u001b[0mrandom\u001b[0m\u001b[1;33m(\u001b[0m\u001b[1;33m)\u001b[0m\u001b[1;33m\u001b[0m\u001b[0m\n\u001b[0m",
>         "\u001b[1;31mNameError\u001b[0m: name 'Math' is not defined"
>        ]
>       }
>      ],
>      "prompt_number": 1
>     }
> 
> what's weird about that is 
> "language": "python" shouldn't it be like language:"javascript" since here we are trying 

(no the field will not change, but we are working on that)
Still the traceback is python so you are probably not running the js kernel. But I guess the read me is wrong.

> into your IPython **profile** directory

> 
> to run an in browser javascript kernel, which didn't work anyway so it doesn't matter
> 
> https://github.com/minrk/profile_jskernel/blob/master/static/js/kernel.js
> is 5 months old and maybe it replaces the other "kernel.js" that is in the repo
> at "C:\A\Y\IPY\IPython\html\static\services\kernels\js\kernel.js" but maybe not
> so i will go to "C:\A\Y\IPY\IPython\"
> and C:\Users\Administrator\Downloads\profile_jskernel-master\profile_jskernel-master\static\js\kernel.js
> and try to add that 1 file manually, but I don't see a "C:\A\Y\IPY\IPython\static\" folder so maybe
> it is the one in the user profiles static folder since "profile_jskernel-master" "profile" suggests this may be the place
> "C:\Users\Administrator\.ipython\profile_default\static\"
> and add "js\kernel.js" so there is now a new "js" directoty and a file at:
> C:\Users\Administrator\.ipython\profile_default\static\js\kernel.js 
> and then TASKKILL /F /IM python.exe and then 
> -m IPython notebook --profile=jskernel
> 

if you put it in profile_default, then you should run $ ipython.exe notebook --profile=default 
...


> which outputs: 
> cwd C:\A\Y\IPY\examples\notebooks
> 
> 2013-10-18 10:33:05.783 [NotebookApp] Using existing profile dir: u'C:\\Users\\Administrator\\.ipython\\profile_jskernel'
> 2013-10-18 10:33:05.801 [NotebookApp] Serving local MathJax from C:\Users\Administrator\.ipython\nbextensions\mathjax\MathJax.js at /nbextensions/mathjax/MathJax.js
> 2013-10-18 10:33:05.841 [NotebookApp] Serving notebooks from local directory: C:\A\Y\IPY\examples\notebooks
> 2013-10-18 10:33:05.841 [NotebookApp] The IPython Notebook is running at: 
> http://127.0.0.1:8888/
> 2013-10-18
>  10:33:05.841 [NotebookApp] Use Control-C to stop this server and shut down all kernels (twice to skip confirmation).
> 
> 
> this "C:\\Users\\Administrator\\.ipython\\profile_jskernel" won't exist since it hasn't been created and there are no

that basically would have been created by the the cloning operation, but because of the README typo you cloned it in the wrong place...

> instructions for doing so nothing at https://github.com/minrk/profile_jskernel is workable or easily repeatable for me.
> 
> _______________________________________________________________________
> RE: version:3 of the 
> 
> {
>      "cell_type": "code",
>      "collapsed": false,
>      "input": [
>       "samsungData['activity'].value_counts()"
>      ],
>      "language": "python",
>      "metadata": {},
>      "outputs": [
>       {
>        "output_type": "pyout",
>        "prompt_number": 14,
>        "text": [
>         "laying      1407\n",
>         "standing    1374\n",
>         "sitting     1286\n",
>         "walk        1226\n",
>         "walkup      1073\n",
>         "walkdown     986"
>        ]
>       }
>      ],
>      "prompt_number": 14
>     }
>  


> I guess there were design decisions that ended up using all this extra clutter 
> for storing strings in arrays, with all of them ending in \n except for the last,

This is optional, you can store only one string instead of a list of string. 
List of string are just nice for version control.


> having to include "metadata": {} empty objects,

Are not always empty, but some processing operation are **much** more painful if the field does not exist as you alway have to check 
for its existence.


>  and others like "language": "python", 
> which would just be the default, all the double quotes around property values are not
> required by javascript (but are a historic cruft left over from douglas crockford being too
> lazy when he drafted the json spec, json5 would be lighter and easier to read, but I don't
> know if your python json.parser could handle plainer object literals {a:1, b:2, c:true, etc:null}

ipynb are not read only by python and js, so we use default json writer, with just a few options.


> either
> something like text:'line0\n\line1\nline2' could have worked equally as well but whatever is working 
> now is best.

Both word at load time

> And why is "prompt_number": 14 in there twice,
technically there is output prompt number and input prompt number, but most of the time they should match, it is true.

> the output prompts are refreshed each time a new kernel starts or a command is run (massive overuse of the word kernel).

Here I'm lost in what you are trying to show/ask and why there is a overuse of "kernel".

-- 
M




From david.verelst at gmail.com  Fri Oct 18 07:25:55 2013
From: david.verelst at gmail.com (David Verelst)
Date: Fri, 18 Oct 2013 13:25:55 +0200
Subject: [IPython-dev] Viewing IPython notebooks in GitLab
In-Reply-To: <CAH4pYpTf11xc689z9u02r3hz3kSL02khCz7Ut=GQmAUwDS-3UQ@mail.gmail.com>
References: <CAG7wmXwQSxRrMNau3XuOo5UL8SZCrnVgT6gCUU8vAuxrbLefOA@mail.gmail.com>
	<CAH4pYpTf11xc689z9u02r3hz3kSL02khCz7Ut=GQmAUwDS-3UQ@mail.gmail.com>
Message-ID: <CALObe=CS_5Gf-UBjXYu7oxu8Z+iLje+AT_O3BwcLHQxJm8=Psg@mail.gmail.com>

Dear Martijn,

This is very interesting. We are also running a Gitlab instance and I would
be very interested in having this. Why not trying to get this merged
upstream, it is a killer feature in my opinion :-) ? With the monthly
updates on the Gitlab front it might be non trivial to keep it up to date.
I can help you with testing and cleaning up the code for a nice pull
request, but I would be overly ambitious by claiming I could do this by
myself.

Thanks for sharing this!

Regards,
David


On 11 October 2013 19:15, Brian Granger <ellisonbg at gmail.com> wrote:

> Martijn,
>
> Thanks for letting us know about this.  This is a perfect usage of
> nbconvert and I am sure the users of GitLab will appreciate this.
>
> Cheers,
>
> Brian
>
> On Thu, Oct 10, 2013 at 3:04 PM, Martijn Vermaat <martijn at vermaat.name>
> wrote:
> > Hi all,
> >
> > At my institute we run a private instance of the GitLab software (a
> > GitHub clone). We're also big fans of the IPython notebook, so the
> > obivous result is many repositories in GitLab containing IPython
> > notebooks.
> >
> > Unfortunately, clicking a notebook file in GitLab shows just the JSON
> > source and because the raw files are not available anonymously, it's
> > non-trivial to use the Notebook Viewer. (And many repositories are
> > private on purpose anyway.)
> >
> > So I made a very simple hack that embeds an HTML view of a notebook
> > directly in the GitLab page (of course by calling nbconvert).
> >
> > In case anyone is interested, I wrote some documentation here:
> >
> >   https://gist.github.com/martijnvermaat/6926070
> >
> > Direct link to the patched GitLab master branch:
> >
> >   https://github.com/martijnvermaat/gitlabhq/tree/blob-ipython-notebook
> >
> > cheers,
> > Martijn
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu and ellisonbg at gmail.com
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131018/9b685922/attachment.html>

From bussonniermatthias at gmail.com  Fri Oct 18 10:54:52 2013
From: bussonniermatthias at gmail.com (Matthias BUSSONNIER)
Date: Fri, 18 Oct 2013 16:54:52 +0200
Subject: [IPython-dev] Cool cool,
	those pointers got things working better
In-Reply-To: <CANwD8vUh5CYp7iFhfxae0Xgu8QprJ-ctc3f2dZTezBnfDw9SJA@mail.gmail.com>
References: <CANwD8vUh5CYp7iFhfxae0Xgu8QprJ-ctc3f2dZTezBnfDw9SJA@mail.gmail.com>
Message-ID: <DC166DC5-121A-454E-9B52-8A906019A6B7@gmail.com>


Le 18 oct. 2013 ? 16:24, Joshua Donnelly a ?crit :

> the change from 
> c.KernelManager.kernel_cmd 
> (rather than .kernel_launch_program) made it work a little more now, 
> so now the notebook starts without errors :)
> 
> though when i interact with a cell, a modal dialog repeatedly says... 
> __________________________________________________________
> Kernel Restarting
> The kernel appears to have died. It will restart automatically.
> __________________________________________________________


Do you have error in the console ? 
Probably bad node version, of required packages.


> i guess that's the javascript 'working', so 
> would there be a good set of notebooks documenting the ipython internals
> or the notebook UI itself? because i don't know what you mean by "profile_default" (contains: settings/history/the json for the connections/etc)

IPython store many profile in .ipython/profile_<profile-name>/  on unix at least. Most of the customization happened here, 
you can overwrite some of IPython file (that is what Min's profile_jskernel does) and have some configuration.



> if you put it in profile_default, then you should run $ ipython.exe notebook --profile=default
> ok (for the "in browser js kernel.js" ) it was at 
> "C:\Users\Administrator\.ipython\profile_default\static\js\kernel.js"
> should it go at?  
> C:\Users\Administrator\.ipython\profile_default\kernel.js (no)
> or C:\Users\Administrator\.ipython\profile_default\static\kernel.jswell (no) i tried it in all 3 places at once, which probably wouldn't hurt, and it did not work, so i emptied the cache... and tried it at 
> C:\A\Y\IPY\IPython\html\static\services\kernels\js\kernel.js
> and it WORKS there, so that's good, So it's meant to be a drop
> in replacement for that existing file which makes sense since it's
> not linked in any other way. 

Ok, that's good. Anaconda might be doing some weird stuff. 
> So for those following along: https://github.com/minrk/profile_jskernel/blob/master/static/js/kernel.js -- just right click that and SaveAs your version of... 
> C:\A\Y\IPY\IPython\html\static\services\kernels\js\kernel.js
> (maybe keep a copy of "kernelORIGINAL.js" to revet back to)
> 
> I thought the ipythonblocks_demo was pretty cool,
> lots of good stuff there
> I agree that it is **much** more painful if the field does not exist as you alway have to check for its existence. -- but when you loop thru the whole lot for the first render the missing properties could be added 
> 
> if(!blah.metadata){blah.metadata={}} 
> 
> then when it as it is saved back 
> 
> if(JSON.stringify(blah.metadata)=='{}'){delete blah.metadata} 

The problem is that other languages might want to **read** the file. 


> or the python equivalent (a couple of lines to save millions of meaningless artifacts being written out to the web is a good thing). Also, I reckon the UNnecessary double quotes are evil ~ if it's mainly just going from python to the browser and you control the codebase, just pull them out, it would also encourage the use of a jsonp wrapper around the notebooks, because only jsonp and eval and not JSON.parse would work in that case, and jsonp has some serious advantages in terms of getting to you data online or offline with or without a server, over http: or file: protocol, it would be like a tripple win)

But we keep in mind those proposition. 
Would you like to open features requests on github with each of theses issue. 
When the notebook format changes, we can consider it and decide with the all core team, and people affected.

> WARNING:root:404 PUT /notebooks/0301f8f7-a094-442c-aab4-f0aa74615529 (127.0.0.1): Notebook does not exist: 0301f8f7-a094-442c-aab4-f0aa74615529
> WARNING:root:404 PUT /notebooks/0301f8f7-a094-442c-aab4-f0aa74615529 (127.0.0.1) 3.00ms
> wonder what it's doing there, trying to access something that isn't there


Which browser  Does it generate thumbnail of websites ? 
If so it's probably an old notebook as UUID are not kept across server restart. 


-- 
M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131018/e87b9085/attachment.html>

From adfgagliardi at gmail.com  Fri Oct 18 16:58:00 2013
From: adfgagliardi at gmail.com (Alessandro Gagliardi)
Date: Fri, 18 Oct 2013 13:58:00 -0700
Subject: [IPython-dev] RJDBC in IPython using rmagic
Message-ID: <CAJ6arDdY3bt6RASUOOYFQ+9WnXy2haf5Az+HrdD9qP9nnTJHsA@mail.gmail.com>

I would like to be able to access a MS SQL Server Database in R through
IPython Notebook. I've been able to get RJDBC to work in R natively, but
when I try to load the library through rmagic, I get the following error:

Loading required package: rJava
Error : .onLoad failed in loadNamespace() for 'rJava', details:
  call: dyn.load(file, DLLpath = DLLpath, ...)
  error: unable to load shared object
'/usr/local/lib/R/site-library/rJava/libs/rJava.so':
  libjvm.so: cannot open shared object file: No such file or directory
Error: package ?rJava? could not be loaded

It would seem that when R is being run through IPython Notebook, it cannot
find libjvm.so. I'm not entirely clear on how rmagic works (and how running
commands through a cell headed with %%R is different from running the same
through R itself). Any help would be much appreciated.

Thank you,

Alessandro Gagliardi
Sr. Data Scientist, Glassdoor.com
alessandro.gagliardi at glassdoor.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131018/6c33faef/attachment.html>

From takowl at gmail.com  Fri Oct 18 18:10:13 2013
From: takowl at gmail.com (Thomas Kluyver)
Date: Fri, 18 Oct 2013 15:10:13 -0700
Subject: [IPython-dev] RJDBC in IPython using rmagic
In-Reply-To: <CAJ6arDdY3bt6RASUOOYFQ+9WnXy2haf5Az+HrdD9qP9nnTJHsA@mail.gmail.com>
References: <CAJ6arDdY3bt6RASUOOYFQ+9WnXy2haf5Az+HrdD9qP9nnTJHsA@mail.gmail.com>
Message-ID: <CAOvn4qh7BVHmuvOpuvc9dzg-dDPuDPVe=8YLzq=A7PdX20p+qQ@mail.gmail.com>

On 18 October 2013 13:58, Alessandro Gagliardi <adfgagliardi at gmail.com>wrote:

> It would seem that when R is being run through IPython Notebook, it cannot
> find libjvm.so. I'm not entirely clear on how rmagic works (and how running
> commands through a cell headed with %%R is different from running the same
> through R itself). Any help would be much appreciated.


rmagic is really just a thin wrapper around rpy2, which actually provides
the communication between Python and R. So you'll probably need to talk to
the people working on that:

http://rpy.sourceforge.net/maillist.html

Best wishes,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131018/9fe17227/attachment.html>

From benjaminrk at gmail.com  Sat Oct 19 01:32:49 2013
From: benjaminrk at gmail.com (MinRK)
Date: Fri, 18 Oct 2013 22:32:49 -0700
Subject: [IPython-dev] IPEP15 ~ would "%autosave 0" would turn it off,
 or where is the global setting for that
In-Reply-To: <CANwD8vVx=CbMJSXw1SiCiHk8qO513U4JZ6mcGZo4yf7U-FZ6Dg@mail.gmail.com>
References: <CANwD8vVx=CbMJSXw1SiCiHk8qO513U4JZ6mcGZo4yf7U-FZ6Dg@mail.gmail.com>
Message-ID: <CAHNn8BVKbcDvOC4rkHn_yLh-AC_j_XNxyCCPcmG0J7Z3V+JMiw@mail.gmail.com>

On Fri, Oct 18, 2013 at 10:02 PM, Joshua Donnelly
<joshuadonnelly at gmail.com>wrote:

> Hi,
>
> So i have sent a few emails to ipython-dev at scipy.org and one of the other
> devs,
> who has been really helpful to me in getting acquainted with the ipy web
> notebook.
>
>
> I hadn't seen any of the IPEPS, which are quite interesting,
> regarding this one in particular:
>
>
> https://github.com/ipython/ipython/wiki/IPEP-15%3A-Autosaving-the-IPython-Notebook
>
> I wondered if "%autosave 0" would turn it off?
>

Yes, it does. If you try it, you will see a message confirming this fact.
But the effect doesn't persist beyond the current notebook session.


>  since i mainly use the notebooks as a scratch pad,
> and am MUCH more happy to explicitly choose a
> save point by clicking the save button (or Ctrl+S).
>
> surely such a thing as autosave should be opt-in opt-out,
> but I didn't quite catch how to do that in the IPEP or on...
>

It may become opt-out once we have a system for propagating user
preferences to the client side.
But we haven't done this yet.


>
>
> https://github.com/ipython/ipython/commit/b69eb67e69fd0ca9ec7840181a1baf50ab26a0ad
> https://github.com/ipython/ipython/pull/3158
> https://github.com/ipython/ipython/pull/3158/files
>
> as these IPEPS are made where are the endUser docs
> for these new features?
>
> In short i would like to know where the ON/OFF
> setting for autosave can be set.
>

> thanks
> josh
>
>
> PS.
>
> Regarding https://github.com/minrk/profile_jskernel
>
> I finally got it working with the instructions below.
> (when will people stop thinking of javascript as a toy,
> and see it as it really is  -- the only true language,
> it will give me a way to explore the the beautiful mess
> that is the ipython web based UI, so thanks so much)
>

"only true language," eh? Nice troll.


> I mainly use git as a download button, and I got into trouble
> when you said "just clone this repo into your IPython directory"
> the word "just" is kind of an involved process for the rest of us,
> and the less i know about git the better, so by way of an old
> fashioned pull request ~ adding something like the following
> to the readme there, would be good:
>

By "just clone this into your IPython dir", I mean the following two steps
are all you need to do:

cd `ipython locate` # usually ~/.ipython, this is called the "IPython
directory"
git clone minrk/profile_jskernel

and you are done. If you don't have the hub wrapper for git, then the git
url is slightly more verbose:

git clone https://github.com/minrk/profile_jskernel

After this, you can switch to the javascript kernel by starting IPython
with:

ipython notebook --profile jskernel

The directions below edit the actual IPython source, which is what this
profile is meant to avoid.

-MinRK


>
>
> To try out the js kernel for a windows noobs
>
> 1. Right click
> https://github.com/minrk/profile_jskernel/blob/master/static/js/kernel.js
>
>
> 2. And choose SaveAs
> C:\A\Y\IPY\IPython\html\static\services\kernels\js\kernel.js
> (or your version thereof)
> !! first keeping a copy of "kernelORIGINAL.js" to revert back to!!
>
> 3. Right click
> https://raw.github.com/minrk/profile_jskernel/master/Javascript.ipynb
> and save that in
> C:\A\Y\IPY\examples\notebooks\Javascript.ipynb
>
> Note: IE will save it as "Javascript.ipynb.txt" in UTF8 with a BOM
> and iypython requires it to be "UTF8 without BOM", so fix that up
> by Saving it with chrome, or use the notepad++ [Encoding] menu
> to re-save and fix that up. Trim off the extra .txt extension in the file
> system if needs be.
>
> **also clearing the browser cache at this point may be useful to
>
> 4. Press[Win]+[R] type cmd to open a command console
> type in
> cd C:\A\Y\IPY\examples\notebooks
> press [Enter]. and then type
> C:\A\Y\Canopy\Env\User\python.exe -m IPython notebook
>
> your paths will vary, but something like that will get you going,
> on windows at least. When the web browser notebook pops up
> at http://127.0.0.1:8888/
> refresh it a couple of time and try it out by typing "Math.random()" or
> some other javascript to test that it works.
>
> To install a version of python which can run ipython on windows get
> Canopy Express
>
> Canopy Express comes with more than 30 pre-configured Python packages,
> from https://www.enthought.com/store/
>
> And choose to install to C:\A\Y\ (or similar, space free paths are best)
> that will make the C:\A\Y\Canopy\ folder automatically
> >>take note of the install options as some of them are quite useful<<
> for me it is 2.7.3 | 64-bit | but is needed since ipython uses a lot of
> the
> extra packages it that Canopy comes with :-)
>
> To get ipython working on windows download
> https://github.com/ipython/ipython/archive/master.zip
> and unzip it to C:\A\Y\IPY (so we have a folder structure like
> C:\A\Y\IPY\examples\notebooks)
> you may also need to run
> "C:\A\Y\Canopy\Env\User\python.exe" -i
> "C:\A\Y\Canopy\Env\User\Scripts\easy_install-script.py" pip
> to install pip and then some thing like
>
> cmd.exe
> cd C:\A\Y\IPY\
> "C:\A\Y\Canopy\Env\User\python.exe" -i
> "C:\A\Y\Canopy\Env\User\Scripts\pip-script.py" install -e ".[notebook]"
> to do whatever the IPY installer requires to get set up
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131018/c82d32a3/attachment.html>

From martijn at vermaat.name  Sun Oct 20 08:42:25 2013
From: martijn at vermaat.name (Martijn Vermaat)
Date: Sun, 20 Oct 2013 14:42:25 +0200
Subject: [IPython-dev] Viewing IPython notebooks in GitLab
In-Reply-To: <CALObe=CS_5Gf-UBjXYu7oxu8Z+iLje+AT_O3BwcLHQxJm8=Psg@mail.gmail.com>
References: <CAG7wmXwQSxRrMNau3XuOo5UL8SZCrnVgT6gCUU8vAuxrbLefOA@mail.gmail.com>
	<CAH4pYpTf11xc689z9u02r3hz3kSL02khCz7Ut=GQmAUwDS-3UQ@mail.gmail.com>
	<CALObe=CS_5Gf-UBjXYu7oxu8Z+iLje+AT_O3BwcLHQxJm8=Psg@mail.gmail.com>
Message-ID: <CAG7wmXwQe4A+Fa0vKqTGWNOVeLFnFE0-ExeVMkEtrP=NrkUA-w@mail.gmail.com>

Hi david,

Thanks for the interest. I was thinking this is probably too specific
for GitLab upstream (and of course calling nbconvert as an external
process during page rendering is not a very clean solution), so didn't
bother to create a pull request. I also did not get any response on my
GitLab mailing list announcement.

However, you convinced me it is worth a shot to at least discuss the
possibilities, so I submitted a pull request:
https://github.com/gitlabhq/gitlabhq/pull/5378 (don't know if this is
the best channel though)

If there's upstream interest, any help is welcome of course :)

thanks,
Martijn


2013/10/18 David Verelst <david.verelst at gmail.com>:
> Dear Martijn,
>
> This is very interesting. We are also running a Gitlab instance and I would
> be very interested in having this. Why not trying to get this merged
> upstream, it is a killer feature in my opinion :-) ? With the monthly
> updates on the Gitlab front it might be non trivial to keep it up to date. I
> can help you with testing and cleaning up the code for a nice pull request,
> but I would be overly ambitious by claiming I could do this by myself.
>
> Thanks for sharing this!
>
> Regards,
> David
>
>
> On 11 October 2013 19:15, Brian Granger <ellisonbg at gmail.com> wrote:
>>
>> Martijn,
>>
>> Thanks for letting us know about this.  This is a perfect usage of
>> nbconvert and I am sure the users of GitLab will appreciate this.
>>
>> Cheers,
>>
>> Brian
>>
>> On Thu, Oct 10, 2013 at 3:04 PM, Martijn Vermaat <martijn at vermaat.name>
>> wrote:
>> > Hi all,
>> >
>> > At my institute we run a private instance of the GitLab software (a
>> > GitHub clone). We're also big fans of the IPython notebook, so the
>> > obivous result is many repositories in GitLab containing IPython
>> > notebooks.
>> >
>> > Unfortunately, clicking a notebook file in GitLab shows just the JSON
>> > source and because the raw files are not available anonymously, it's
>> > non-trivial to use the Notebook Viewer. (And many repositories are
>> > private on purpose anyway.)
>> >
>> > So I made a very simple hack that embeds an HTML view of a notebook
>> > directly in the GitLab page (of course by calling nbconvert).
>> >
>> > In case anyone is interested, I wrote some documentation here:
>> >
>> >   https://gist.github.com/martijnvermaat/6926070
>> >
>> > Direct link to the patched GitLab master branch:
>> >
>> >   https://github.com/martijnvermaat/gitlabhq/tree/blob-ipython-notebook
>> >
>> > cheers,
>> > Martijn
>> > _______________________________________________
>> > IPython-dev mailing list
>> > IPython-dev at scipy.org
>> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>>
>>
>> --
>> Brian E. Granger
>> Cal Poly State University, San Luis Obispo
>> bgranger at calpoly.edu and ellisonbg at gmail.com
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>


From ehmatthes at gmail.com  Sun Oct 20 19:05:15 2013
From: ehmatthes at gmail.com (Eric Matthes)
Date: Sun, 20 Oct 2013 15:05:15 -0800
Subject: [IPython-dev] Numbered lines after using nbconvert?
Message-ID: <CAH-3OQ7SHarzvnLuFTEdBZPA=Y-js2tZWQe81Rfki8AnPZqGCw@mail.gmail.com>

I just realized you can use Ctrl-M L to turn line numbering on in a cell,
but I notice that those numbers are not visible when I view a notebook
through IPython Notebook Viewer. After I use nbconvert on a notebook with
the numbers visible, the resulting html file does not have line numbers.

Is there a way to have the line numbers included in the html output when
using nbconvert?

Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131020/911f98b7/attachment.html>

From apratap at sagebase.org  Mon Oct 21 15:02:55 2013
From: apratap at sagebase.org (Abhishek Pratap)
Date: Mon, 21 Oct 2013 12:02:55 -0700
Subject: [IPython-dev] Sample ipython notebooks showcasing interactive
	graphics
Message-ID: <CAJfJrc=xUwM0w4GNDiidc-gSECVGzzvYsT+dAiMkyB_pANFVVQ@mail.gmail.com>

Hi All

Note: The same question was posted on stackoverflow last week but dint
garner enough attention I guess. (link below)

Just wondering if there are examples(may be Ipython notebooks) of rendering
interactive plots in python that are bit more involved than simple bar/line
plots.

I did look at d3py and vincent. In the case of latter I was not able to
find any example of interactive graphics but only static images using
D3/JS. For d3py I am looking for an interesting graphic/s beyond simpler
demo bar line plots.

Any Ipython notebook demonstrating the same would be very helpful. It will
be good to know if there are other packages that I should be keeping on my
radar. Did have a quick look at Bokeh but not sure if I shud wait a bit
before it is more stable and has some documentation.

*PS: looking for something that can be slickly integrated into a webpage /
Ipython notebook*

*
*

*stackoverflow link:*

*
http://stackoverflow.com/questions/19453430/examples-of-interactive-plots-through-python
*

*
*

Thanks!
-Abhi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131021/55ea0b16/attachment.html>

From bussonniermatthias at gmail.com  Mon Oct 21 15:16:01 2013
From: bussonniermatthias at gmail.com (Matthias BUSSONNIER)
Date: Mon, 21 Oct 2013 21:16:01 +0200
Subject: [IPython-dev] Sample ipython notebooks showcasing interactive
	graphics
In-Reply-To: <CAJfJrc=xUwM0w4GNDiidc-gSECVGzzvYsT+dAiMkyB_pANFVVQ@mail.gmail.com>
References: <CAJfJrc=xUwM0w4GNDiidc-gSECVGzzvYsT+dAiMkyB_pANFVVQ@mail.gmail.com>
Message-ID: <8D011E41-BC61-4C25-BD9B-A441E79A5F61@gmail.com>

Hi Abi, 

Please have a look at our roadmap, 

For example here:

	https://github.com/ipython/ipython/wiki/Roadmap:-IPython

You will see that ability to do so is planned for future release, and that current 
example you find on the web right now are mostly hackish, and that IPython 
infrastructure is not ready for that yet. 

You can follow up by tracking the relevant issues on github, or 
watching the live youtube lab meeting every Thursday. 

Thanks. 
-- 
M



Le 21 oct. 2013 ? 21:02, Abhishek Pratap a ?crit :

> Hi All
> 
> Note: The same question was posted on stackoverflow last week but dint garner enough attention I guess. (link below)
> 
> Just wondering if there are examples(may be Ipython notebooks) of rendering interactive plots in python that are bit more involved than simple bar/line plots.
> I did look at d3py and vincent. In the case of latter I was not able to find any example of interactive graphics but only static images using D3/JS. For d3py I am looking for an interesting graphic/s beyond simpler demo bar line plots.
> 
> Any Ipython notebook demonstrating the same would be very helpful. It will be good to know if there are other packages that I should be keeping on my radar. Did have a quick look at Bokeh but not sure if I shud wait a bit before it is more stable and has some documentation.
> 
> PS: looking for something that can be slickly integrated into a webpage / Ipython notebook
> 
> 
> 
> stackoverflow link:
> 
> http://stackoverflow.com/questions/19453430/examples-of-interactive-plots-through-python
> 
> 
> 
> Thanks!
> 
> -Abhi
> 
> 
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



From apratap at sagebase.org  Tue Oct 22 15:07:35 2013
From: apratap at sagebase.org (Abhishek Pratap)
Date: Tue, 22 Oct 2013 12:07:35 -0700
Subject: [IPython-dev] Sample ipython notebooks showcasing interactive
	graphics
In-Reply-To: <8D011E41-BC61-4C25-BD9B-A441E79A5F61@gmail.com>
References: <CAJfJrc=xUwM0w4GNDiidc-gSECVGzzvYsT+dAiMkyB_pANFVVQ@mail.gmail.com>
	<8D011E41-BC61-4C25-BD9B-A441E79A5F61@gmail.com>
Message-ID: <CAJfJrcn_pSX4V_exo2WMd57pLhUF1R-NEzBviOvF1+1V12Cf=g@mail.gmail.com>

Thanks..

In the meantime can someone propose a way to push in a HTML+JS
code(rendering a plot) in a Ipython cell.

For example the attached html file is a simple plot based on D3. If I can
update the DOM with required JS libs and render a HTML/JS script mashup ..I
think it will work. Any pointers ?

I did look at the https://github.com/cschin/ipython_d3_mashup code base but
dont want to spit out plot in a separate box. I would prefer it to be
integrated within Ipython cell.


-Abhi


On Mon, Oct 21, 2013 at 12:16 PM, Matthias BUSSONNIER <
bussonniermatthias at gmail.com> wrote:

> Hi Abi,
>
> Please have a look at our roadmap,
>
> For example here:
>
>         https://github.com/ipython/ipython/wiki/Roadmap:-IPython
>
> You will see that ability to do so is planned for future release, and that
> current
> example you find on the web right now are mostly hackish, and that IPython
> infrastructure is not ready for that yet.
>
> You can follow up by tracking the relevant issues on github, or
> watching the live youtube lab meeting every Thursday.
>
> Thanks.
> --
> M
>
>
>
> Le 21 oct. 2013 ? 21:02, Abhishek Pratap a ?crit :
>
> > Hi All
> >
> > Note: The same question was posted on stackoverflow last week but dint
> garner enough attention I guess. (link below)
> >
> > Just wondering if there are examples(may be Ipython notebooks) of
> rendering interactive plots in python that are bit more involved than
> simple bar/line plots.
> > I did look at d3py and vincent. In the case of latter I was not able to
> find any example of interactive graphics but only static images using
> D3/JS. For d3py I am looking for an interesting graphic/s beyond simpler
> demo bar line plots.
> >
> > Any Ipython notebook demonstrating the same would be very helpful. It
> will be good to know if there are other packages that I should be keeping
> on my radar. Did have a quick look at Bokeh but not sure if I shud wait a
> bit before it is more stable and has some documentation.
> >
> > PS: looking for something that can be slickly integrated into a webpage
> / Ipython notebook
> >
> >
> >
> > stackoverflow link:
> >
> >
> http://stackoverflow.com/questions/19453430/examples-of-interactive-plots-through-python
> >
> >
> >
> > Thanks!
> >
> > -Abhi
> >
> >
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131022/65914a3d/attachment.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131022/65914a3d/attachment-0001.html>

From apratap at sagebase.org  Tue Oct 22 16:32:24 2013
From: apratap at sagebase.org (Abhishek Pratap)
Date: Tue, 22 Oct 2013 13:32:24 -0700
Subject: [IPython-dev] nbviewer down ?
Message-ID: <CAJfJrckxmBxvSM_Kyz0oEdMOEtp5_UUpdyDJ9fAQiS=M-xLLgg@mail.gmail.com>

FYI:
http://nbviewer.ipython.org

I am getting the following error

Application Error

An error occurred in the application and your page could not be served.
Please try again in a few moments.

If you are the application owner, check your logs for details.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131022/0475e1a7/attachment.html>

From gmbecker at ucdavis.edu  Tue Oct 22 18:03:35 2013
From: gmbecker at ucdavis.edu (Gabriel Becker)
Date: Tue, 22 Oct 2013 15:03:35 -0700
Subject: [IPython-dev] Some new cell types for describing data analyses
 in IPy. Notebook
In-Reply-To: <CAH+mRR0NcsGLszb9W-vbbXRBZV0eVSPM_77YmmGnY7HyX+CBkg@mail.gmail.com>
References: <CADwqtCNRb3EK7g6E80XXMSoY+QLrF1BaAdCm2yMhjWbr-Y-KzQ@mail.gmail.com>
	<CAHNn8BUZy5+0sMFiT9sFwnD4gUPKhZ-Mfv4W_6Q9jaOOHGBhwQ@mail.gmail.com>
	<CADwqtCN_NyjPBmny511LC8LkTTfo5cpAbBFQR5y_-wC9s6M=xw@mail.gmail.com>
	<CAHNn8BVP_0_o98ryMCeNEHjdPdq009zDu9majmrpXAbfhBrZgQ@mail.gmail.com>
	<F33ADD32-33D0-456A-9436-5FAE915FCA81@gmail.com>
	<CADwqtCM11DurMQFNd1PB+h_n_wMWHy1kR_d25V7VeJsQrY4LXw@mail.gmail.com>
	<CAH4pYpST2b81nVz5WJWMt6PpfqoGhRuOmw_wyKUDZFqGh=+7=Q@mail.gmail.com>
	<CADwqtCPQNrT95oZcTfXp=XG=avhWsj=fgjyzhHuc36w3nFESDA@mail.gmail.com>
	<CAH4pYpQjs_tTNLxD1c6fO7aYHgTYmgUpFPkGinQ8jOufHDzhYQ@mail.gmail.com>
	<CADwqtCP-cJxFqde_9YwsvzdOSRfx_tkrVcTxaE69VxU+Ni43Rw@mail.gmail.com>
	<CAH4pYpT4TBgHgqgZXLEN48+GWBk3Lk-_y+NY-QboFC+LH0t=rg@mail.gmail.com>
	<CADwqtCPzJUTjYSkLQq-UGX+_CBZYvRr=1_0psgZE_yw0=eDWQQ@mail.gmail.com>
	<CADwqtCPHzp0MrK1MPSFbQ0jvp+1k=fmKV4dt87Yfsruc__nFTA@mail.gmail.com>
	<CAHAreOq9DRJ5_bNn2ZEPsNv3ADRidFY6G_=8UWsFtW0+cYjzXg@mail.gmail.com>
	<CAH4pYpS_z8Pwmp-Rmk5b6VW=YYx0mAH-uAjELC1raocUbjxAPA@mail.gmail.com>
	<CADwqtCOAe-DOy45a7zxbAdHDQVOvyuB7=-fi0Zjhbm1m2mFAJw@mail.gmail.com>
	<CAH+mRR0NcsGLszb9W-vbbXRBZV0eVSPM_77YmmGnY7HyX+CBkg@mail.gmail.com>
Message-ID: <CADwqtCNsceZSHQ2CbJmB2cEmF6_nmjSqN-nxS3+R6oLTVcB4pw@mail.gmail.com>

Hi all,

Sorry I disappeared for a bit. I would still very much like to take part in
one of the g+ dev hangouts and discuss these ideas.

Are they still held at 10am on Thursdays? If so I have a previous
obligation this week but would be happy to schedule for next week if the
itinerary is not yet full. If it is, let me know when there is an opening
and I should be able to make it work.

Thanks and looking forward to talking to you all.

~G


On Mon, Oct 7, 2013 at 3:54 PM, Dami?n Avila <damianavila at gmail.com> wrote:

> >What format would this and my participation be in? Would I be presenting
> something to get people up to speed or assuming that they have read the
> novel that this thread has turned into?
>
> Probably most of the core developers have read this one, but is long
> thread... and the beginning was some months ago.
> I think that a quick summary covering the main issues and a little demo
> can be a nice way to present this "novel" ;-)
>
>
> 2013/10/7 Gabriel Becker <gmbecker at ucdavis.edu>
>
>> I'm happy to jump in on one of the hangouts to discuss these ideas. I
>> could probably manage this thursday but next thursday might be better. I do
>> agree that the discrete post/respond cycle of emails does prove a bit
>> cumbersome for large detailed discussions like this. I still hope to meet
>> the local(ish) portions of the team in person at some point, but it sounds
>> like the logistics of that are tough and it is of course important to
>> include and engage the non-local people as well.
>>
>> What format would this and my participation be in? Would I be presenting
>> something to get people up to speed or assuming that they have read the
>> novel that this thread has turned into?
>>
>> Also, @fperez, I'd love to grab coffee and sit down with you when you're
>> in Davis.
>>
>> ~G
>>
>>
>> On Mon, Oct 7, 2013 at 11:36 AM, Brian Granger <ellisonbg at gmail.com>wrote:
>>
>>> Gabriel,
>>>
>>> I think we are pushing the limits of email on this discussion.  I
>>> think it would be great to continue the discussion in person or our
>>> Google Hangouts as Fernando mentions below.
>>>
>>> > sorry to have been silent, but everyone else is doing a great job on
>>> this
>>> > discussion...
>>> >
>>> > I just wanted to say that we'd love to talk to you at Berkeley, but I'm
>>> > leaving town tonight for a couple weeks, so it won't work until late
>>> October
>>> > or more likely November.  But in Nov. I'm giving a talk at Davis, in J.
>>> > Eisen's group. Perhaps at least you and I could meet for coffee while
>>> I'm
>>> > there and cover some ground.
>>>
>>> That would be a great start to the in person discussions...
>>>
>>> > Another alternative for a higher-bandwidth technical discussion is to
>>> > schedule a slot into one of our public dev meetings on Thursdays. This
>>> week
>>> > we had Peter Krautzberger, from MathJax, join us and it was very
>>> useful.
>>> > That will decouple us from finding a time when everyone can meet in
>>> > Berkeley, and more importantly, will allow others who can't make it in
>>> > person to also follow the discussion.
>>>
>>> Let us know if/when you can join us on this.
>>>
>>> Cheers,
>>>
>>> Brian
>>>
>>> > Cheers,
>>> >
>>> > f
>>> >
>>> >
>>> > On Sun, Oct 6, 2013 at 4:39 PM, Gabriel Becker <gmbecker at ucdavis.edu>
>>> wrote:
>>> >>
>>> >> Hey Brian et al,
>>> >>
>>> >> Just checking in to see if you and/or other team members are still
>>> >> interested in meeting in person and chatting about some of the ideas
>>> we had
>>> >> been discussing in this thread.
>>> >>
>>> >> Happy to also continue the conversation here in the meantime.
>>> >>
>>> >> ~G
>>> >>
>>> >>
>>> >> On Tue, Sep 10, 2013 at 6:32 PM, Gabriel Becker <gmbecker at ucdavis.edu
>>> >
>>> >> wrote:
>>> >>>
>>> >>> Brian et al,
>>> >>>
>>> >>> Brian I hope your move/travel/etc was as pleasant as such things can
>>> be.
>>> >>>
>>> >>>
>>> >>> On Fri, Jul 12, 2013 at 9:21 AM, Brian Granger <ellisonbg at gmail.com>
>>> >>> wrote:
>>> >>>>
>>> >>>> Gabriel,
>>> >>>> <snip>
>>> >>>>
>>> >>>>
>>> >>>> Great, let's talk in Sept. to figure out a time that would work.
>>> >>>
>>> >>>
>>> >>> I'm still quite interested in meeting with you guys. Somewhere near
>>> the
>>> >>> end of the month would be best for me, but I'm pretty flexible.
>>> >>>
>>> >>>>
>>> >>>> <snip>
>>> >>>>
>>> >>>> > Branching/DAG notebooks allow a single document to encompass the
>>> >>>> > research
>>> >>>> > you did, while providing easy access to various views
>>> corresponding to
>>> >>>> > the
>>> >>>> > generation of intermediate, alternative, and final results.
>>> >>>> >
>>> >>>> > These more complex notebooks allow the viewer to ask and answer
>>> >>>> > important
>>> >>>> > questions such as "What else did (s)he try here?" and potentially
>>> even
>>> >>>> > "Why
>>> >>>> > did (s)he choose this particular analysis strategy?". These
>>> questions
>>> >>>> > can be
>>> >>>> > answered in the text or external supplementary materials in a
>>> linear
>>> >>>> > notebook, but this is a significant barrier to reproducibility of
>>> the
>>> >>>> > research process (as opposed to the analysis results).
>>> >>>>
>>> >>>> I can see that, however, I think the pure alt cells lack a critical
>>> >>>> feature.  They treat all branches as being equally important.  In
>>> >>>> reality, the branch that is chosen as the "best" one will likely
>>> >>>> require further analysis and discussion that that other branches
>>> >>>> don't.  Putting the different branches side by side makes it a
>>> little
>>> >>>> like "choose your own adventure" - when in reality, the author of
>>> the
>>> >>>> research want to steer the reader along a very particular path.  The
>>> >>>> alternative paths maybe useful to have around, but they should be be
>>> >>>> given equal weight as the "best" one.  But, maybe it is just
>>> >>>> presentation and can be accounted for in descriptive text.
>>> >>>
>>> >>>
>>> >>> This is very true. My current thinking calls for both a "default"
>>> >>> designation and a "most recently selected/run" designation, which I
>>> believe
>>> >>> deals with the valid concern you raise above.
>>> >>>
>>> >>> There are also other important designations for "branch types". The
>>> most
>>> >>> notable/easily explained of these is the concept of a "terminal"
>>> branch,
>>> >>> which is a branch that records important computations (and prose),
>>> and which
>>> >>> a viewer of the notebook  (be it the original author, a reviewer, a
>>> student,
>>> >>> or someone looking to extend the work) may want to look at or run,
>>> but whose
>>> >>> output is not compatible with the subsequent computations. This
>>> arises most
>>> >>> commonly when one analysis strategy is implemented and pursued, but
>>> >>> ultimately abandoned  (hopefully for good reasons, and with this we
>>> can
>>> >>> check!) in favor of a different final strategy which produces
>>> incompatible
>>> >>> output. The subsequent code then makes assumptions about the output
>>> which
>>> >>> are compatible with the final strategy computations, but not the
>>> original
>>> >>> strategy ones. A way to gracefully deal with this case is important
>>> for any
>>> >>> document/processing/rendering system attempting to pursue these
>>> concepts.
>>> >>>
>>> >>> There are other cases that arise with these documents, but I will
>>> omit a
>>> >>> detailed discussion of them and what I think should be done to
>>> support them
>>> >>> here, as that would make this mail burdensomely long and it is not my
>>> >>> primary message.
>>> >>>
>>> >>> I will note, though, that while I agree that the
>>> final/core/whathaveyou
>>> >>> and secondary/informative/archival branches should not be
>>> indistinguishable,
>>> >>> it is important for my usecase that they be easily accessible when
>>> the
>>> >>> reader wants to in both interactive (notebook) and headless
>>> (nbconvert)
>>> >>> modes.
>>> >>>
>>> >>>>
>>> >>>> <snip>
>>> >>>>
>>> >>>>
>>> >>>> > As a practical/UI standpoint unselected branches can be hidden
>>> almost
>>> >>>> > entirely (in theory, not currently in my PoC :p), resulting in a
>>> view
>>> >>>> > equivalent to (any) the only view offered by a linear notebook.
>>> This
>>> >>>> > means
>>> >>>> > that from a viewer (and author since a straight line IS a DAG and
>>> >>>> > nesting
>>> >>>> > isn't forced) standpoint, what I'm describing is in essense a
>>> strict
>>> >>>> > extension of what the notebook does now, rather than a change.
>>> >>>>
>>> >>>> I would be *more* interested in alt-cell approaches that present the
>>> >>>> notebook as a linear entity in all cases, but that has the alt-cell
>>> >>>> logic underneath.  For example, what about the following:
>>> >>>>
>>> >>>> * A user writes the different N alt cells in linear sequence
>>> >>>> * The result is a purely linear notebook where one of the N cells
>>> should
>>> >>>> be run.
>>> >>>> * We write a JavaScript plugin for the notebook that does a couple
>>> of
>>> >>>> things:
>>> >>>>
>>> >>>> 1. It provides a cell toolbar for marking those cells as members of
>>> an
>>> >>>> alt-set.  This would simple modify the cell level metadata and allow
>>> >>>> the author to provide titles of each alt-member.
>>> >>>
>>> >>>
>>> >>> What about branching that is 2 or more levels deep? That happens
>>> >>> naturally with my approach but sounds difficult/annoying to keep
>>> track of in
>>> >>> the one you are describing.
>>> >>>
>>> >>>>
>>> >>>> 2. It provides the logic for building a UI for viewing one of the
>>> >>>> alt-set members at a time.  It could be as simple as injecting a
>>> drop
>>> >>>> down menu that shows one and hides the rest.
>>> >>>
>>> >>>
>>> >>> I have an ugly but functional version of this now in my
>>> implementation.
>>> >>>
>>> >>>>
>>> >>>>
>>> >>>> * This plugin could simple walk the notebook cells and find all the
>>> >>>> alt-cell sets and build this supplementary UI.
>>> >>>> * This plugin could also have settings that allow the author to
>>> select
>>> >>>> the "best" member of the alt-set.
>>> >>>> * nbconvert Transformers could use the cell level metadata to export
>>> >>>> the notebook in different formats.
>>> >>>>
>>> >>>> As I write about this - I think this would be extremely nice, and it
>>> >>>> would not be difficult to write at all.  Because of how our
>>> JavaScript
>>> >>>> plugins work, it could be developed outside IPython initially.  The
>>> >>>> question of inclusion in the official code base could be handled
>>> >>>> later.  Honestly, this approach should be much easier than the work
>>> >>>> you have already done.
>>> >>>
>>> >>>
>>> >>> Well, editing the notebook once it exists in this form seems like it
>>> >>> would be much less fun, in terms of adding new cells.
>>> >>>
>>> >>> What you're describing is also much more onerous for the author. With
>>> >>> what I have now, you declare a cell to be an altset or task and
>>> everything
>>> >>> just sort of works. New cells are inserted in the right places, cells
>>> >>> trivially know who their parents are, etc.
>>> >>>
>>> >>> If I understand you correctly, the author would have to write all the
>>> >>> alternatives in a big linear document (not fun or easy to test, see
>>> >>> discussion below) and then click a bunch of buttons to manually
>>> select what
>>> >>> cells go in which alternate. That is a much larger cognitive burden
>>> on the
>>> >>> author (as well as probably being really annoying...).
>>> >>>
>>> >>>>
>>> >>>>
>>> >>>> Best of all the resulting notebooks would remain standard linear
>>> >>>> notebooks that could be shared today on nbviewer, etc.  It would
>>> just
>>> >>>> work.
>>> >>>
>>> >>>
>>> >>> Respectfully, this is actually the fatal flaw of this approach IMO,
>>> both
>>> >>> in this case and in other cases where a JS plugin/extension uses the
>>> >>> metadata approach to fundamentally modify behavior (as opposed to
>>> >>> aestethics/UI) of the IPython Notebook.
>>> >>>
>>> >>> The issue, stated in the context of the nesting/alts/etc cells
>>> extension,
>>> >>> is that a notebook that has branching/alternates *requires* that
>>> they be
>>> >>> understood as such, rather than simply benefiting from it.
>>> >>>
>>> >>> The ability to distribute notebooks I write and have them work
>>> properly
>>> >>> is entirely core to my usecase for IPython. If I can't do so, what I
>>> >>> personally can get IPython or IPython notebooks to do on my own
>>> machine is
>>> >>> not something I have any real interest in. Now you may be thinking to
>>> >>> yourself "But Gabe, no one is using your fork so you can't do that
>>> now with
>>> >>> your implementation anyway". That is true, but if someone without my
>>> fork
>>> >>> installed manages to get their hands on a notebook which uses the
>>> nesting
>>> >>> features, it will break when they try to load it.
>>> >>>
>>> >>> If I create an extension as you are describing, create a complex
>>> notebook
>>> >>> using it, and someone without the plugin installed finds it,
>>> downloads it,
>>> >>> and runs it, it will run fine and happily give them incorrect results
>>> >>> without even noticing the extra bits I stuck in the metadata.
>>> >>>
>>> >>> The core issue here is that running a notebook with branching as a
>>> linear
>>> >>> notebook by executing each of the branches in sequence is actually
>>> erroneous
>>> >>> and will produce undefined, untrustworthy, and likely incorrect,
>>> behavior
>>> >>> and output. The reason for this is that branches/alternatives are
>>> assumed to
>>> >>> be mutually exclusive by the computational model, and can alter
>>> objects
>>> >>> in-place in manners that can have unintended cumulative effects.
>>> >>>
>>> >>> As a very simple example consider branches which handle outliers in a
>>> >>> certain variable by modifying the variable in-place and trimming its
>>> values
>>> >>> by .1, 1, 5, and 10%, respectively,  using quantiles and then
>>> consider what
>>> >>> would happen if these branches were all run in an arbitrary order.
>>> >>>
>>> >>> It is easy to see that the outcome from running all the branches
>>> (which
>>> >>> is what will silently happen if the notebook is treated as a
>>> standard linear
>>> >>> notebook because the plugin is not being used) does not reflect any
>>> of the
>>> >>> choices intended by the author and more complex situations could be
>>> >>> difficult to predict at all without sitting down and thinking about
>>> it.
>>> >>>
>>> >>> As such, I would not be comfortable distributing branching notebooks
>>> >>> using the extension mechanism as I understand it to exist now
>>> because a) I
>>> >>> feel it indirectly damages the type of scientific reprodicibility
>>> and result
>>> >>> trustworthiness I seek to advance, and b) I don't want to spend all
>>> my time
>>> >>> fielding angry emails/bugreports from notebook authors who sent their
>>> >>> notebooks to collaborators who didn't have the plugin installed.
>>> >>>
>>> >>>
>>> >>>>
>>> >>>>
>>> >>>> <snip>
>>> >>>>
>>> >>>> > Consider the example of classifying new data based on a training
>>> set
>>> >>>> > via
>>> >>>> > KNN, SVM, and GLM approaches. These approaches all need different
>>> sets
>>> >>>> > of
>>> >>>> > parameters, return different types of objects as the output of the
>>> >>>> > fitting
>>> >>>> > function, may have subtley different behaviour when being used for
>>> >>>> > prediction, etc.
>>> >>>>
>>> >>>> Yep, that is the big challenge with the branching idea in general.
>>>  It
>>> >>>> is not always true that the members of the alt sets can be swapped
>>> >>>> out.
>>> >>>
>>> >>>
>>> >>> And under the model I am envisioning, that is actually an informative
>>> >>> and queriable feature, rather than a drawback. See my discussion
>>> above
>>> >>> regarding terminal branches.
>>> >>>
>>> >>>>
>>> >>>>
>>> >>>> <snip>
>>> >>>>
>>> >>>> I hope you can see that I really like the general idea and think the
>>> >>>> usage cases you are describing are really important.  I think I can
>>> >>>> speak for the project in saying that we want the notebook to be
>>> useful
>>> >>>> for things like this.  But I think our abstractions are important
>>> >>>> enough that we make every attempt to see how we can do these while
>>> >>>> leveraging our existing abstractions.  This is partially a question
>>> >>>> about implementation, but also partly a question about how the new
>>> >>>> features are thought about.  The reason we don't like to break
>>> >>>> abstractions for new features is that we have found an interesting
>>> >>>> relationship between abstraction breaking and new features.  We have
>>> >>>> found that when a new feature/idea breaks a core abstraction that we
>>> >>>> have thought about very carefully, it is usually because the feature
>>> >>>> has not been fully understood.  Time and time again, we have found
>>> >>>> that when we take the time to fully understand the feature, it
>>> usually
>>> >>>> fits within our abstractions beautifully and is even much better
>>> that
>>> >>>> we ever imagined it could be.
>>> >>>>
>>> >>>> The plugin idea above is a perfect example of this.  By preserving
>>> the
>>> >>>> abstractions the new feature itself a multiplication of even new
>>> >>>> functionality:
>>> >>>>
>>> >>>> * The resulting notebooks can still be version controlled.  This
>>> means
>>> >>>> that the different alt-cell can be thrown into git and when we
>>> develop
>>> >>>> a visual diff tool for notebooks, they will *just work*.
>>> >>>
>>> >>>
>>> >>> I don't really understand this point. I have numerous fork-based
>>> >>> non-linear notebooks under version control.
>>> >>>
>>> >>> Also, when you have a visual diff tool, it will successfully do
>>> something
>>> >>> when given a linear+metadata branching notebook, but whether that
>>> something
>>> >>> would be to deliver the information required to understand changes to
>>> >>> non-linear notebooks  is less clear (and seems somewhat unlikely).
>>> >>>
>>> >>>>
>>> >>>> * The notebooks can immediately leverage the abstractions we have
>>> put
>>> >>>> into place for converting notebooks to different formats.  You could
>>> >>>> write custom transformers to present the notebook in a reveal.js
>>> >>>> giving alt-cells special treatment.
>>> >>>
>>> >>>
>>> >>>
>>> >>> I could write custom transformers, this is true, but the default
>>> behavior
>>> >>> would treat the notebook as if it actually were linear (instead of
>>> just
>>> >>> being stored that way) which is problematic.
>>> >>>
>>> >>>
>>> >>>>
>>> >>>> * All of this can be done, and into the hands of user, without going
>>> >>>> through those overly conservative IPython developers ;-)
>>> >>>> * It will just work with nbviewer as well.
>>> >>>
>>> >>>
>>> >>> Again, I disagree. It would *display* in nbviewer, but not work, in
>>> that
>>> >>> the display would be actively misleading regarding what the notebook
>>> would
>>> >>> do when executed properly.
>>> >>>
>>> >>>>
>>> >>>> * It provides a cleanly abstracted foundation for other people to
>>> build
>>> >>>> upon
>>> >>>
>>> >>>
>>> >>> I agree that this is important, but it is not clear to me that it
>>> would
>>> >>> be more true in the case that I created the extension via custom JS
>>> than it
>>> >>> would if nesting were supported in the actual ipynb format and core
>>> notebook
>>> >>> mechanisms.
>>> >>>
>>> >>>>
>>> >>>>
>>> >>>> In summary, we are trying to build an architecture that allows a few
>>> >>>> simple abstractions (we actually don't have that many!) to combine
>>> in
>>> >>>> boundless ways to create features we never planned on, but that
>>> "just
>>> >>>> work".
>>> >>>
>>> >>>
>>> >>> I agree that the customjs + metadata extensions approach is very
>>> powerful
>>> >>> and almost infinitely versatile. I think it is great for extensions
>>> which
>>> >>> change appearance/rendering/UI details of how the notebook behaves.
>>> >>>
>>> >>> As far as I can see, however,  it has some signficant problems with
>>> >>> regard to extensions which fundamentally change non-rendering
>>> behavior of
>>> >>> notebooks (please correct me if I'm wrong), namely:
>>> >>>
>>> >>> There is no guarantee that notebooks authored using an extension
>>> which
>>> >>> alters fundamental behaviors will work or visibly fail in the
>>> absence of
>>> >>> that extension
>>> >>> There is no way for an individual notebook to require a particular
>>> >>> extension
>>> >>> There is no way to ensure that two extensions are compatible with
>>> >>> each-other
>>> >>> There is no standard/unified way for end-users to install extensions
>>> >>> There is no way for users to determine which extensions they have
>>> >>>
>>> >>> The first point is not true of extensions which exclusively affect
>>> >>> rendering and UI, making the rest of the points minor nuisances
>>> rather than
>>> >>> critical issues.
>>> >>>
>>> >>> Looking forward to hearing your (further) thoughts about this stuff
>>> and
>>> >>> hopefully meeting you in person soon.
>>> >>>
>>> >>> ~G
>>> >>>
>>> >>> --
>>> >>> Gabriel Becker
>>> >>> Graduate Student
>>> >>> Statistics Department
>>> >>> University of California, Davis
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Gabriel Becker
>>> >> Graduate Student
>>> >> Statistics Department
>>> >> University of California, Davis
>>> >>
>>> >> _______________________________________________
>>> >> IPython-dev mailing list
>>> >> IPython-dev at scipy.org
>>> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Fernando Perez (@fperez_org; http://fperez.org)
>>> > fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
>>> > fernando.perez-at-berkeley: contact me here for any direct mail
>>> >
>>> > _______________________________________________
>>> > IPython-dev mailing list
>>> > IPython-dev at scipy.org
>>> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>>> >
>>>
>>>
>>>
>>> --
>>> Brian E. Granger
>>> Cal Poly State University, San Luis Obispo
>>> bgranger at calpoly.edu and ellisonbg at gmail.com
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>
>>
>>
>>
>> --
>> Gabriel Becker
>> Graduate Student
>> Statistics Department
>> University of California, Davis
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>>
>
>
> --
> Dami?n Avila
> Scientific Python Developer
> Quantitative Finance Analyst
> Statistics, Biostatistics and Econometrics Consultant
> Biochemist
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>


-- 
Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131022/c68b7b48/attachment.html>

From clayton.davis at continuum.io  Tue Oct 22 19:39:30 2013
From: clayton.davis at continuum.io (Clayton Davis)
Date: Tue, 22 Oct 2013 19:39:30 -0400
Subject: [IPython-dev] Sample ipython notebooks showcasing interactive
	graphics
In-Reply-To: <CAJfJrcn_pSX4V_exo2WMd57pLhUF1R-NEzBviOvF1+1V12Cf=g@mail.gmail.com>
References: <CAJfJrc=xUwM0w4GNDiidc-gSECVGzzvYsT+dAiMkyB_pANFVVQ@mail.gmail.com>
	<8D011E41-BC61-4C25-BD9B-A441E79A5F61@gmail.com>
	<CAJfJrcn_pSX4V_exo2WMd57pLhUF1R-NEzBviOvF1+1V12Cf=g@mail.gmail.com>
Message-ID: <CAO5HWPbKH2KcGJnWmjRWgA3GMCGzN=9xrMx7ZKAEigkFDZRrQQ@mail.gmail.com>

Here's another example of interactive IPython + HTML + JS using Google Maps
API:
https://www.wakari.io/sharing/bundle/wakari_demo/realtime_twitter_analysis

Note the Wakari preview (and I'm pretty sure nbviewer) won't run JS, so you
need to download and run the notebook or run/edit it in Wakari.


Clayton A Davis
Continuum Analytics


On Tue, Oct 22, 2013 at 3:07 PM, Abhishek Pratap <apratap at sagebase.org>wrote:

> Thanks..
>
> In the meantime can someone propose a way to push in a HTML+JS
> code(rendering a plot) in a Ipython cell.
>
> For example the attached html file is a simple plot based on D3. If I can
> update the DOM with required JS libs and render a HTML/JS script mashup ..I
> think it will work. Any pointers ?
>
> I did look at the https://github.com/cschin/ipython_d3_mashup code base
> but dont want to spit out plot in a separate box. I would prefer it to be
> integrated within Ipython cell.
>
>
> -Abhi
>
>
> On Mon, Oct 21, 2013 at 12:16 PM, Matthias BUSSONNIER <
> bussonniermatthias at gmail.com> wrote:
>
>> Hi Abi,
>>
>> Please have a look at our roadmap,
>>
>> For example here:
>>
>>         https://github.com/ipython/ipython/wiki/Roadmap:-IPython
>>
>> You will see that ability to do so is planned for future release, and
>> that current
>> example you find on the web right now are mostly hackish, and that IPython
>> infrastructure is not ready for that yet.
>>
>> You can follow up by tracking the relevant issues on github, or
>> watching the live youtube lab meeting every Thursday.
>>
>> Thanks.
>> --
>> M
>>
>>
>>
>> Le 21 oct. 2013 ? 21:02, Abhishek Pratap a ?crit :
>>
>> > Hi All
>> >
>> > Note: The same question was posted on stackoverflow last week but dint
>> garner enough attention I guess. (link below)
>> >
>> > Just wondering if there are examples(may be Ipython notebooks) of
>> rendering interactive plots in python that are bit more involved than
>> simple bar/line plots.
>> > I did look at d3py and vincent. In the case of latter I was not able to
>> find any example of interactive graphics but only static images using
>> D3/JS. For d3py I am looking for an interesting graphic/s beyond simpler
>> demo bar line plots.
>> >
>> > Any Ipython notebook demonstrating the same would be very helpful. It
>> will be good to know if there are other packages that I should be keeping
>> on my radar. Did have a quick look at Bokeh but not sure if I shud wait a
>> bit before it is more stable and has some documentation.
>> >
>> > PS: looking for something that can be slickly integrated into a webpage
>> / Ipython notebook
>> >
>> >
>> >
>> > stackoverflow link:
>> >
>> >
>> http://stackoverflow.com/questions/19453430/examples-of-interactive-plots-through-python
>> >
>> >
>> >
>> > Thanks!
>> >
>> > -Abhi
>> >
>> >
>> > _______________________________________________
>> > IPython-dev mailing list
>> > IPython-dev at scipy.org
>> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131022/eef85f6b/attachment.html>

From nathan12343 at gmail.com  Tue Oct 22 20:41:22 2013
From: nathan12343 at gmail.com (Nathan Goldbaum)
Date: Tue, 22 Oct 2013 17:41:22 -0700
Subject: [IPython-dev] Using sphinx to evaluate notebook cells?
Message-ID: <CAJXewOnbwmyw5VzPtW2pSGjDFOdO1YHyrEffLGw_9q241xPQQg@mail.gmail.com>

Hi all,

Myself and some of the other yt devs are thinking about ways to improve
cookbook section of our documentation by replacing the scripts we currently
host with notebooks.

Since some of our cookbook recipes store plots, we'd like to track these
notebooks in version control in an unevaluated state, mainly to avoid
versioning images.  We have a CI server that already builds our cookbook
recipes for our dev docs, so something that integrates with sphinx seems to
be the way to go. I think I could write a sphinx plugin that does the job,
but it would need to use whatever machinery IPython uses when notebook
cells get evaluated.

Does anyone know if such a plugin is available somewhere?  If not, does
anyone know where I should look in the IPython codebase for when I try to
write it myself?

Thanks for your help,

-Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131022/0c509772/attachment.html>

From benjaminrk at gmail.com  Tue Oct 22 21:58:43 2013
From: benjaminrk at gmail.com (MinRK)
Date: Tue, 22 Oct 2013 18:58:43 -0700
Subject: [IPython-dev] Multi-directory support landed in master
Message-ID: <CAHNn8BVpCC_0BpueoziL32C-d9=6z5OSkm268GnttLArTXkRfw@mail.gmail.com>

Multidirectory support has landed in master, which includes major changes
in the URL structure (no more UUID URLs, yay!).

There isn?t a UI for navigation yet, but you can enter URLs relative to the
initial server directory.

Give it a test drive, and let us know what you find.

Description in IPEP
16<https://github.com/ipython/ipython/wiki/IPEP-16%3A-Notebook-multi-directory-dashboard-and-URL-mapping>
.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131022/d1f74eda/attachment.html>

From yanghatespam at gmail.com  Tue Oct 22 22:40:17 2013
From: yanghatespam at gmail.com (Yang Zhang)
Date: Tue, 22 Oct 2013 19:40:17 -0700
Subject: [IPython-dev] Embedding IPython Notebook in Flask web app
Message-ID: <CAKxBDU9hWzpt2bxkuyAYHCtnbBxjxcEdv5Vbc3tAfjemGQnS6w@mail.gmail.com>

I'm interested in embedding IPython Notebook in a Python (Flask) web app.

This web app essentially lets users browse/view datasets.  When
viewing a dataset, it would be great if we could add a button that
starts an IPython Notebook (pre-loaded with the dataset and some
utility libraries) to allow users to deep-dive into that dataset.

I know this has been brought up a couple times in the past but I'm
just asking again in case the situation has changed, since it's been a
while, and also our situation is slightly different - we're not
looking to provide generic IPython Notebook hosting, and we're not
worried about security (this is an internal web app to just our team,
all of whom have access to the underlying data anyway).

I'm basically looking for the Notebook server analogy to
IPython.start_ipython().  Any hints on the most straightforward route
would be greatly appreciated.  Thanks in advance!


From benjaminrk at gmail.com  Tue Oct 22 23:21:32 2013
From: benjaminrk at gmail.com (MinRK)
Date: Tue, 22 Oct 2013 20:21:32 -0700
Subject: [IPython-dev] Embedding IPython Notebook in Flask web app
In-Reply-To: <CAKxBDU9hWzpt2bxkuyAYHCtnbBxjxcEdv5Vbc3tAfjemGQnS6w@mail.gmail.com>
References: <CAKxBDU9hWzpt2bxkuyAYHCtnbBxjxcEdv5Vbc3tAfjemGQnS6w@mail.gmail.com>
Message-ID: <CAHNn8BVzPj4x0rL5WEQumOR-dpR8bttP4yhSM_aY44aUPHu2KA@mail.gmail.com>

Since all of the existing notebook web handlers are for tornado, you would
have to either rewrite the web side with django instead of tornado, or
*also* run a tornado webserver, and embed that content on your page (via
iframe or otherwise).


On Tue, Oct 22, 2013 at 7:40 PM, Yang Zhang <yanghatespam at gmail.com> wrote:

> I'm interested in embedding IPython Notebook in a Python (Flask) web app.
>
> This web app essentially lets users browse/view datasets.  When
> viewing a dataset, it would be great if we could add a button that
> starts an IPython Notebook (pre-loaded with the dataset and some
> utility libraries) to allow users to deep-dive into that dataset.
>
> I know this has been brought up a couple times in the past but I'm
> just asking again in case the situation has changed, since it's been a
> while, and also our situation is slightly different - we're not
> looking to provide generic IPython Notebook hosting, and we're not
> worried about security (this is an internal web app to just our team,
> all of whom have access to the underlying data anyway).
>
> I'm basically looking for the Notebook server analogy to
> IPython.start_ipython().  Any hints on the most straightforward route
> would be greatly appreciated.  Thanks in advance!
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131022/e2f5a6b0/attachment.html>

From yanghatespam at gmail.com  Wed Oct 23 01:48:13 2013
From: yanghatespam at gmail.com (Yang Zhang)
Date: Tue, 22 Oct 2013 22:48:13 -0700
Subject: [IPython-dev] Embedding IPython Notebook in Flask web app
In-Reply-To: <CAHNn8BVzPj4x0rL5WEQumOR-dpR8bttP4yhSM_aY44aUPHu2KA@mail.gmail.com>
References: <CAKxBDU9hWzpt2bxkuyAYHCtnbBxjxcEdv5Vbc3tAfjemGQnS6w@mail.gmail.com>
	<CAHNn8BVzPj4x0rL5WEQumOR-dpR8bttP4yhSM_aY44aUPHu2KA@mail.gmail.com>
Message-ID: <CAKxBDU8q3r+2E755F77mMFvSeTwFVbTUPmuv=+D4Wx6ugZchfA@mail.gmail.com>

Right, I wasn't anticipating anything *not* involving spinning up separate
servers, but I was wondering if there was anything in the way of doing
that/managing them, and (more importantly) whether I can pre-load the
session with the right environment (is the best bet to produce and
somehow load a notebook file?).

On Tue, Oct 22, 2013 at 8:21 PM, MinRK <benjaminrk at gmail.com> wrote:
> Since all of the existing notebook web handlers are for tornado, you would
> have to either rewrite the web side with django instead of tornado, or
> *also* run a tornado webserver, and embed that content on your page (via
> iframe or otherwise).
>
>
> On Tue, Oct 22, 2013 at 7:40 PM, Yang Zhang <yanghatespam at gmail.com> wrote:
>>
>> I'm interested in embedding IPython Notebook in a Python (Flask) web app.
>>
>> This web app essentially lets users browse/view datasets.  When
>> viewing a dataset, it would be great if we could add a button that
>> starts an IPython Notebook (pre-loaded with the dataset and some
>> utility libraries) to allow users to deep-dive into that dataset.
>>
>> I know this has been brought up a couple times in the past but I'm
>> just asking again in case the situation has changed, since it's been a
>> while, and also our situation is slightly different - we're not
>> looking to provide generic IPython Notebook hosting, and we're not
>> worried about security (this is an internal web app to just our team,
>> all of whom have access to the underlying data anyway).
>>
>> I'm basically looking for the Notebook server analogy to
>> IPython.start_ipython().  Any hints on the most straightforward route
>> would be greatly appreciated.  Thanks in advance!
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Yang Zhang
http://yz.mit.edu/


From zvoros at gmail.com  Wed Oct 23 02:37:47 2013
From: zvoros at gmail.com (=?ISO-8859-1?Q?Zolt=E1n_V=F6r=F6s?=)
Date: Wed, 23 Oct 2013 08:37:47 +0200
Subject: [IPython-dev] Sample ipython notebooks showcasing interactive
 graphics
In-Reply-To: <CAJfJrcn_pSX4V_exo2WMd57pLhUF1R-NEzBviOvF1+1V12Cf=g@mail.gmail.com>
References: <CAJfJrc=xUwM0w4GNDiidc-gSECVGzzvYsT+dAiMkyB_pANFVVQ@mail.gmail.com>
	<8D011E41-BC61-4C25-BD9B-A441E79A5F61@gmail.com>
	<CAJfJrcn_pSX4V_exo2WMd57pLhUF1R-NEzBviOvF1+1V12Cf=g@mail.gmail.com>
Message-ID: <52676EBB.4040404@gmail.com>

Hi Abhi,

You can also look at the flot package for inspiration: 
http://i.imgur.com/vk2Q6.png

https://github.com/crbates/ipython-flot

Cheers,
Zolt?n


On 22/10/13 21:07, Abhishek Pratap wrote:
> Thanks..
>
> In the meantime can someone propose a way to push in a HTML+JS 
> code(rendering a plot) in a Ipython cell.
>
> For example the attached html file is a simple plot based on D3. If I 
> can update the DOM with required JS libs and render a HTML/JS script 
> mashup ..I think it will work. Any pointers ?
>
> I did look at the https://github.com/cschin/ipython_d3_mashup code 
> base but dont want to spit out plot in a separate box. I would prefer 
> it to be integrated within Ipython cell.
>
>
> -Abhi
>
>
> On Mon, Oct 21, 2013 at 12:16 PM, Matthias BUSSONNIER 
> <bussonniermatthias at gmail.com <mailto:bussonniermatthias at gmail.com>> 
> wrote:
>
>     Hi Abi,
>
>     Please have a look at our roadmap,
>
>     For example here:
>
>     https://github.com/ipython/ipython/wiki/Roadmap:-IPython
>
>     You will see that ability to do so is planned for future release,
>     and that current
>     example you find on the web right now are mostly hackish, and that
>     IPython
>     infrastructure is not ready for that yet.
>
>     You can follow up by tracking the relevant issues on github, or
>     watching the live youtube lab meeting every Thursday.
>
>     Thanks.
>     --
>     M
>
>
>
>     Le 21 oct. 2013 ? 21:02, Abhishek Pratap a ?crit :
>
>     > Hi All
>     >
>     > Note: The same question was posted on stackoverflow last week
>     but dint garner enough attention I guess. (link below)
>     >
>     > Just wondering if there are examples(may be Ipython notebooks)
>     of rendering interactive plots in python that are bit more
>     involved than simple bar/line plots.
>     > I did look at d3py and vincent. In the case of latter I was not
>     able to find any example of interactive graphics but only static
>     images using D3/JS. For d3py I am looking for an interesting
>     graphic/s beyond simpler demo bar line plots.
>     >
>     > Any Ipython notebook demonstrating the same would be very
>     helpful. It will be good to know if there are other packages that
>     I should be keeping on my radar. Did have a quick look at Bokeh
>     but not sure if I shud wait a bit before it is more stable and has
>     some documentation.
>     >
>     > PS: looking for something that can be slickly integrated into a
>     webpage / Ipython notebook
>     >
>     >
>     >
>     > stackoverflow link:
>     >
>     >
>     http://stackoverflow.com/questions/19453430/examples-of-interactive-plots-through-python
>     >
>     >
>     >
>     > Thanks!
>     >
>     > -Abhi
>     >
>     >
>     > _______________________________________________
>     > IPython-dev mailing list
>     > IPython-dev at scipy.org <mailto:IPython-dev at scipy.org>
>     > http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>     _______________________________________________
>     IPython-dev mailing list
>     IPython-dev at scipy.org <mailto:IPython-dev at scipy.org>
>     http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131023/1ffdf540/attachment.html>

From bussonniermatthias at gmail.com  Wed Oct 23 02:45:33 2013
From: bussonniermatthias at gmail.com (Matthias BUSSONNIER)
Date: Wed, 23 Oct 2013 08:45:33 +0200
Subject: [IPython-dev] Multi-directory support landed in master
In-Reply-To: <CAHNn8BVpCC_0BpueoziL32C-d9=6z5OSkm268GnttLArTXkRfw@mail.gmail.com>
References: <CAHNn8BVpCC_0BpueoziL32C-d9=6z5OSkm268GnttLArTXkRfw@mail.gmail.com>
Message-ID: <AB6DA5B1-4A2E-4C94-854F-2CEF517EEF30@gmail.com>


Le 23 oct. 2013 ? 03:58, MinRK a ?crit :

> Multidirectory support has landed in master, which includes major changes in the URL structure (no more UUID URLs, yay!).
> 
> There isn?t a UI for navigation yet, but you can enter URLs relative to the initial server directory.
> 
> Give it a test drive, and let us know what you find.


Still don't forget to back-up your data, this is still development version.

And you should now be able to get rid of the file/ prefix IIRC, 
(for those who know what I'm talking about).

-- 
M



From jason-sage at creativetrax.com  Wed Oct 23 02:52:42 2013
From: jason-sage at creativetrax.com (Jason Grout)
Date: Wed, 23 Oct 2013 01:52:42 -0500
Subject: [IPython-dev] Sample ipython notebooks showcasing interactive
 graphics
In-Reply-To: <CAJfJrc=xUwM0w4GNDiidc-gSECVGzzvYsT+dAiMkyB_pANFVVQ@mail.gmail.com>
References: <CAJfJrc=xUwM0w4GNDiidc-gSECVGzzvYsT+dAiMkyB_pANFVVQ@mail.gmail.com>
Message-ID: <5267723A.3020805@creativetrax.com>

On 10/21/13 2:02 PM, Abhishek Pratap wrote:
> *PS: looking for something that can be slickly integrated into a webpage
> / Ipython notebook*
>

Since you ask about integrating into a webpage, I'll mention that we're 
doing a lot of interactive stuff with the Sage Cell server (based on 
IPython+Sage [1], which includes lots and lots of other packages), which 
is trivial to embed into a webpage.  Here are some recent examples using 
IPython's new Comm architecture that is currently in review:

http://sagecell.sagemath.org/?q=fyjgmk

http://sagecell.sagemath.org/?q=rdsbja

http://sagecell.sagemath.org/?q=hpjfxz

I was also working on porting matplotlib's interactive backend to the 
Comm framework.

It's easy to embed these things into a webpage.  Just follow the 
directions here: http://sagecell.sagemath.org/static/about.html.  See 
http://buzzard.ups.edu/ for an example.

Also, you might check out Sage interacts, which is our current way of 
doing interactive things: See http://interact.sagemath.org/ and 
http://wiki.sagemath.org/interact/ for examples.

Thanks,

Jason

[1] http://sagemath.org

--
Jason Grout



From bussonniermatthias at gmail.com  Wed Oct 23 04:11:20 2013
From: bussonniermatthias at gmail.com (Matthias Bussonnier)
Date: Wed, 23 Oct 2013 10:11:20 +0200
Subject: [IPython-dev] Using sphinx to evaluate notebook cells?
In-Reply-To: <CAJXewOnbwmyw5VzPtW2pSGjDFOdO1YHyrEffLGw_9q241xPQQg@mail.gmail.com>
References: <CAJXewOnbwmyw5VzPtW2pSGjDFOdO1YHyrEffLGw_9q241xPQQg@mail.gmail.com>
Message-ID: <0013520D-74AC-420D-B5CC-7AEE18EC931C@gmail.com>

Hi

I'm not aware of such a plugin.
Definitively interested as we want our doc as notebook in IPython too.

Have a look at runipy (Google is your friend, and is on pypi iirc). It runs notebook headless and generate static HTML from that. 
Having a nbconvert preprocessor that run notebook would also be great!

(Sorry no direct link, from my phone)
-- 
M

Envoy? de mon iPhone

> Le 23 oct. 2013 ? 02:41, Nathan Goldbaum <nathan12343 at gmail.com> a ?crit :
> 
> Hi all,
> 
> Myself and some of the other yt devs are thinking about ways to improve cookbook section of our documentation by replacing the scripts we currently host with notebooks.
> 
> Since some of our cookbook recipes store plots, we'd like to track these notebooks in version control in an unevaluated state, mainly to avoid versioning images.  We have a CI server that already builds our cookbook recipes for our dev docs, so something that integrates with sphinx seems to be the way to go. I think I could write a sphinx plugin that does the job, but it would need to use whatever machinery IPython uses when notebook cells get evaluated.  
> 
> Does anyone know if such a plugin is available somewhere?  If not, does anyone know where I should look in the IPython codebase for when I try to write it myself?
> 
> Thanks for your help,
> 
> -Nathan
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev


From zvoros at gmail.com  Wed Oct 23 04:14:17 2013
From: zvoros at gmail.com (=?ISO-8859-1?Q?Zolt=E1n_V=F6r=F6s?=)
Date: Wed, 23 Oct 2013 10:14:17 +0200
Subject: [IPython-dev] Multi-directory support landed in master
In-Reply-To: <CAHNn8BVpCC_0BpueoziL32C-d9=6z5OSkm268GnttLArTXkRfw@mail.gmail.com>
References: <CAHNn8BVpCC_0BpueoziL32C-d9=6z5OSkm268GnttLArTXkRfw@mail.gmail.com>
Message-ID: <52678559.7060103@gmail.com>

Hi all,

I have checked out the changes from github, but I seem to have 
encountered two issues. From the linux command line

 > BROWSER=chromium-browser ipython notebook

appears to start the server, but in the browser only an "Error 
connecting to server." message can be seen.

If I do this

 > ipython notebook

then this takes me to the dashbord in firefox (it's OK for now), and I 
can open notebooks that are listed, but when I try to upload a notebook, 
I get an

"Invalid file format:
Uploaded notebooks must be .ipynb files"

message. If I take the address from the address bar, and copy it into 
chromium's address bar, nothing happens, chromium still reports that it 
can't connect to the server. Is this the expected behaviour? Let me 
know, if there is anything that I could do to track down the source of 
the problem.

Cheers,
Zolt?n


On 23/10/13 03:58, MinRK wrote:
>
> Multidirectory support has landed in master, which includes major 
> changes in the URL structure (no more UUID URLs, yay!).
>
> There isn't a UI for navigation yet, but you can enter URLs relative 
> to the initial server directory.
>
> Give it a test drive, and let us know what you find.
>
> Description in IPEP 16 
> <https://github.com/ipython/ipython/wiki/IPEP-16%3A-Notebook-multi-directory-dashboard-and-URL-mapping>.
>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131023/18a3cd7c/attachment.html>

From bussonniermatthias at gmail.com  Wed Oct 23 04:17:41 2013
From: bussonniermatthias at gmail.com (Matthias Bussonnier)
Date: Wed, 23 Oct 2013 10:17:41 +0200
Subject: [IPython-dev] Some new cell types for describing data analyses
	in IPy. Notebook
In-Reply-To: <CADwqtCNsceZSHQ2CbJmB2cEmF6_nmjSqN-nxS3+R6oLTVcB4pw@mail.gmail.com>
References: <CADwqtCNRb3EK7g6E80XXMSoY+QLrF1BaAdCm2yMhjWbr-Y-KzQ@mail.gmail.com>
	<CAHNn8BUZy5+0sMFiT9sFwnD4gUPKhZ-Mfv4W_6Q9jaOOHGBhwQ@mail.gmail.com>
	<CADwqtCN_NyjPBmny511LC8LkTTfo5cpAbBFQR5y_-wC9s6M=xw@mail.gmail.com>
	<CAHNn8BVP_0_o98ryMCeNEHjdPdq009zDu9majmrpXAbfhBrZgQ@mail.gmail.com>
	<F33ADD32-33D0-456A-9436-5FAE915FCA81@gmail.com>
	<CADwqtCM11DurMQFNd1PB+h_n_wMWHy1kR_d25V7VeJsQrY4LXw@mail.gmail.com>
	<CAH4pYpST2b81nVz5WJWMt6PpfqoGhRuOmw_wyKUDZFqGh=+7=Q@mail.gmail.com>
	<CADwqtCPQNrT95oZcTfXp=XG=avhWsj=fgjyzhHuc36w3nFESDA@mail.gmail.com>
	<CAH4pYpQjs_tTNLxD1c6fO7aYHgTYmgUpFPkGinQ8jOufHDzhYQ@mail.gmail.com>
	<CADwqtCP-cJxFqde_9YwsvzdOSRfx_tkrVcTxaE69VxU+Ni43Rw@mail.gmail.com>
	<CAH4pYpT4TBgHgqgZXLEN48+GWBk3Lk-_y+NY-QboFC+LH0t=rg@mail.gmail.com>
	<CADwqtCPzJUTjYSkLQq-UGX+_CBZYvRr=1_0psgZE_yw0=eDWQQ@mail.gmail.com>
	<CADwqtCPHzp0MrK1MPSFbQ0jvp+1k=fmKV4dt87Yfsruc__nFTA@mail.gmail.com>
	<CAHAreOq9DRJ5_bNn2ZEPsNv3ADRidFY6G_=8UWsFtW0+cYjzXg@mail.gmail.com>
	<CAH4pYpS_z8Pwmp-Rmk5b6VW=YYx0mAH-uAjELC1raocUbjxAPA@mail.gmail.com>
	<CADwqtCOAe-DOy45a7zxbAdHDQVOvyuB7=-fi0Zjhbm1m2mFAJw@mail.gmail.com>
	<CAH+mRR0NcsGLszb9W-vbbXRBZV0eVSPM_77YmmGnY7HyX+CBkg@mail.gmail.com>
	<CADwqtCNsceZSHQ2CbJmB2cEmF6_nmjSqN-nxS3+R6oLTVcB4pw@mail.gmail.com>
Message-ID: <E000D6FF-9BB3-4AA5-BE89-E3C4EA5B8F94@gmail.com>

Yes live meeting are at 10am PST every Thursday.

You can edit the hackpad and add a short summary of what you would like to discuss in the section for the relevant day. Add a small "don't forget to invite me" near your edits. 
-- 
M


Envoy? de mon iPhone

> Le 23 oct. 2013 ? 00:03, Gabriel Becker <gmbecker at ucdavis.edu> a ?crit :
> 
> Hi all,
> 
> Sorry I disappeared for a bit. I would still very much like to take part in one of the g+ dev hangouts and discuss these ideas.
> 
> Are they still held at 10am on Thursdays? If so I have a previous obligation this week but would be happy to schedule for next week if the itinerary is not yet full. If it is, let me know when there is an opening and I should be able to make it work.
> 
> Thanks and looking forward to talking to you all.
> 
> ~G
> 
> 
>> On Mon, Oct 7, 2013 at 3:54 PM, Dami?n Avila <damianavila at gmail.com> wrote:
>> >What format would this and my participation be in? Would I be presenting something to get people up to speed or assuming that they have read the novel that this thread has turned into?
>> 
>> Probably most of the core developers have read this one, but is long thread... and the beginning was some months ago. 
>> I think that a quick summary covering the main issues and a little demo can be a nice way to present this "novel" ;-)
>> 
>> 
>> 2013/10/7 Gabriel Becker <gmbecker at ucdavis.edu>
>>> I'm happy to jump in on one of the hangouts to discuss these ideas. I could probably manage this thursday but next thursday might be better. I do agree that the discrete post/respond cycle of emails does prove a bit cumbersome for large detailed discussions like this. I still hope to meet the local(ish) portions of the team in person at some point, but it sounds like the logistics of that are tough and it is of course important to include and engage the non-local people as well.
>>> 
>>> What format would this and my participation be in? Would I be presenting something to get people up to speed or assuming that they have read the novel that this thread has turned into?
>>> 
>>> Also, @fperez, I'd love to grab coffee and sit down with you when you're in Davis. 
>>> 
>>> ~G
>>> 
>>> 
>>>> On Mon, Oct 7, 2013 at 11:36 AM, Brian Granger <ellisonbg at gmail.com> wrote:
>>>> Gabriel,
>>>> 
>>>> I think we are pushing the limits of email on this discussion.  I
>>>> think it would be great to continue the discussion in person or our
>>>> Google Hangouts as Fernando mentions below.
>>>> 
>>>> > sorry to have been silent, but everyone else is doing a great job on this
>>>> > discussion...
>>>> >
>>>> > I just wanted to say that we'd love to talk to you at Berkeley, but I'm
>>>> > leaving town tonight for a couple weeks, so it won't work until late October
>>>> > or more likely November.  But in Nov. I'm giving a talk at Davis, in J.
>>>> > Eisen's group. Perhaps at least you and I could meet for coffee while I'm
>>>> > there and cover some ground.
>>>> 
>>>> That would be a great start to the in person discussions...
>>>> 
>>>> > Another alternative for a higher-bandwidth technical discussion is to
>>>> > schedule a slot into one of our public dev meetings on Thursdays. This week
>>>> > we had Peter Krautzberger, from MathJax, join us and it was very useful.
>>>> > That will decouple us from finding a time when everyone can meet in
>>>> > Berkeley, and more importantly, will allow others who can't make it in
>>>> > person to also follow the discussion.
>>>> 
>>>> Let us know if/when you can join us on this.
>>>> 
>>>> Cheers,
>>>> 
>>>> Brian
>>>> 
>>>> > Cheers,
>>>> >
>>>> > f
>>>> >
>>>> >
>>>> > On Sun, Oct 6, 2013 at 4:39 PM, Gabriel Becker <gmbecker at ucdavis.edu> wrote:
>>>> >>
>>>> >> Hey Brian et al,
>>>> >>
>>>> >> Just checking in to see if you and/or other team members are still
>>>> >> interested in meeting in person and chatting about some of the ideas we had
>>>> >> been discussing in this thread.
>>>> >>
>>>> >> Happy to also continue the conversation here in the meantime.
>>>> >>
>>>> >> ~G
>>>> >>
>>>> >>
>>>> >> On Tue, Sep 10, 2013 at 6:32 PM, Gabriel Becker <gmbecker at ucdavis.edu>
>>>> >> wrote:
>>>> >>>
>>>> >>> Brian et al,
>>>> >>>
>>>> >>> Brian I hope your move/travel/etc was as pleasant as such things can be.
>>>> >>>
>>>> >>>
>>>> >>> On Fri, Jul 12, 2013 at 9:21 AM, Brian Granger <ellisonbg at gmail.com>
>>>> >>> wrote:
>>>> >>>>
>>>> >>>> Gabriel,
>>>> >>>> <snip>
>>>> >>>>
>>>> >>>>
>>>> >>>> Great, let's talk in Sept. to figure out a time that would work.
>>>> >>>
>>>> >>>
>>>> >>> I'm still quite interested in meeting with you guys. Somewhere near the
>>>> >>> end of the month would be best for me, but I'm pretty flexible.
>>>> >>>
>>>> >>>>
>>>> >>>> <snip>
>>>> >>>>
>>>> >>>> > Branching/DAG notebooks allow a single document to encompass the
>>>> >>>> > research
>>>> >>>> > you did, while providing easy access to various views corresponding to
>>>> >>>> > the
>>>> >>>> > generation of intermediate, alternative, and final results.
>>>> >>>> >
>>>> >>>> > These more complex notebooks allow the viewer to ask and answer
>>>> >>>> > important
>>>> >>>> > questions such as "What else did (s)he try here?" and potentially even
>>>> >>>> > "Why
>>>> >>>> > did (s)he choose this particular analysis strategy?". These questions
>>>> >>>> > can be
>>>> >>>> > answered in the text or external supplementary materials in a linear
>>>> >>>> > notebook, but this is a significant barrier to reproducibility of the
>>>> >>>> > research process (as opposed to the analysis results).
>>>> >>>>
>>>> >>>> I can see that, however, I think the pure alt cells lack a critical
>>>> >>>> feature.  They treat all branches as being equally important.  In
>>>> >>>> reality, the branch that is chosen as the "best" one will likely
>>>> >>>> require further analysis and discussion that that other branches
>>>> >>>> don't.  Putting the different branches side by side makes it a little
>>>> >>>> like "choose your own adventure" - when in reality, the author of the
>>>> >>>> research want to steer the reader along a very particular path.  The
>>>> >>>> alternative paths maybe useful to have around, but they should be be
>>>> >>>> given equal weight as the "best" one.  But, maybe it is just
>>>> >>>> presentation and can be accounted for in descriptive text.
>>>> >>>
>>>> >>>
>>>> >>> This is very true. My current thinking calls for both a "default"
>>>> >>> designation and a "most recently selected/run" designation, which I believe
>>>> >>> deals with the valid concern you raise above.
>>>> >>>
>>>> >>> There are also other important designations for "branch types". The most
>>>> >>> notable/easily explained of these is the concept of a "terminal" branch,
>>>> >>> which is a branch that records important computations (and prose), and which
>>>> >>> a viewer of the notebook  (be it the original author, a reviewer, a student,
>>>> >>> or someone looking to extend the work) may want to look at or run, but whose
>>>> >>> output is not compatible with the subsequent computations. This arises most
>>>> >>> commonly when one analysis strategy is implemented and pursued, but
>>>> >>> ultimately abandoned  (hopefully for good reasons, and with this we can
>>>> >>> check!) in favor of a different final strategy which produces incompatible
>>>> >>> output. The subsequent code then makes assumptions about the output which
>>>> >>> are compatible with the final strategy computations, but not the original
>>>> >>> strategy ones. A way to gracefully deal with this case is important for any
>>>> >>> document/processing/rendering system attempting to pursue these concepts.
>>>> >>>
>>>> >>> There are other cases that arise with these documents, but I will omit a
>>>> >>> detailed discussion of them and what I think should be done to support them
>>>> >>> here, as that would make this mail burdensomely long and it is not my
>>>> >>> primary message.
>>>> >>>
>>>> >>> I will note, though, that while I agree that the final/core/whathaveyou
>>>> >>> and secondary/informative/archival branches should not be indistinguishable,
>>>> >>> it is important for my usecase that they be easily accessible when the
>>>> >>> reader wants to in both interactive (notebook) and headless (nbconvert)
>>>> >>> modes.
>>>> >>>
>>>> >>>>
>>>> >>>> <snip>
>>>> >>>>
>>>> >>>>
>>>> >>>> > As a practical/UI standpoint unselected branches can be hidden almost
>>>> >>>> > entirely (in theory, not currently in my PoC :p), resulting in a view
>>>> >>>> > equivalent to (any) the only view offered by a linear notebook. This
>>>> >>>> > means
>>>> >>>> > that from a viewer (and author since a straight line IS a DAG and
>>>> >>>> > nesting
>>>> >>>> > isn't forced) standpoint, what I'm describing is in essense a strict
>>>> >>>> > extension of what the notebook does now, rather than a change.
>>>> >>>>
>>>> >>>> I would be *more* interested in alt-cell approaches that present the
>>>> >>>> notebook as a linear entity in all cases, but that has the alt-cell
>>>> >>>> logic underneath.  For example, what about the following:
>>>> >>>>
>>>> >>>> * A user writes the different N alt cells in linear sequence
>>>> >>>> * The result is a purely linear notebook where one of the N cells should
>>>> >>>> be run.
>>>> >>>> * We write a JavaScript plugin for the notebook that does a couple of
>>>> >>>> things:
>>>> >>>>
>>>> >>>> 1. It provides a cell toolbar for marking those cells as members of an
>>>> >>>> alt-set.  This would simple modify the cell level metadata and allow
>>>> >>>> the author to provide titles of each alt-member.
>>>> >>>
>>>> >>>
>>>> >>> What about branching that is 2 or more levels deep? That happens
>>>> >>> naturally with my approach but sounds difficult/annoying to keep track of in
>>>> >>> the one you are describing.
>>>> >>>
>>>> >>>>
>>>> >>>> 2. It provides the logic for building a UI for viewing one of the
>>>> >>>> alt-set members at a time.  It could be as simple as injecting a drop
>>>> >>>> down menu that shows one and hides the rest.
>>>> >>>
>>>> >>>
>>>> >>> I have an ugly but functional version of this now in my implementation.
>>>> >>>
>>>> >>>>
>>>> >>>>
>>>> >>>> * This plugin could simple walk the notebook cells and find all the
>>>> >>>> alt-cell sets and build this supplementary UI.
>>>> >>>> * This plugin could also have settings that allow the author to select
>>>> >>>> the "best" member of the alt-set.
>>>> >>>> * nbconvert Transformers could use the cell level metadata to export
>>>> >>>> the notebook in different formats.
>>>> >>>>
>>>> >>>> As I write about this - I think this would be extremely nice, and it
>>>> >>>> would not be difficult to write at all.  Because of how our JavaScript
>>>> >>>> plugins work, it could be developed outside IPython initially.  The
>>>> >>>> question of inclusion in the official code base could be handled
>>>> >>>> later.  Honestly, this approach should be much easier than the work
>>>> >>>> you have already done.
>>>> >>>
>>>> >>>
>>>> >>> Well, editing the notebook once it exists in this form seems like it
>>>> >>> would be much less fun, in terms of adding new cells.
>>>> >>>
>>>> >>> What you're describing is also much more onerous for the author. With
>>>> >>> what I have now, you declare a cell to be an altset or task and everything
>>>> >>> just sort of works. New cells are inserted in the right places, cells
>>>> >>> trivially know who their parents are, etc.
>>>> >>>
>>>> >>> If I understand you correctly, the author would have to write all the
>>>> >>> alternatives in a big linear document (not fun or easy to test, see
>>>> >>> discussion below) and then click a bunch of buttons to manually select what
>>>> >>> cells go in which alternate. That is a much larger cognitive burden on the
>>>> >>> author (as well as probably being really annoying...).
>>>> >>>
>>>> >>>>
>>>> >>>>
>>>> >>>> Best of all the resulting notebooks would remain standard linear
>>>> >>>> notebooks that could be shared today on nbviewer, etc.  It would just
>>>> >>>> work.
>>>> >>>
>>>> >>>
>>>> >>> Respectfully, this is actually the fatal flaw of this approach IMO, both
>>>> >>> in this case and in other cases where a JS plugin/extension uses the
>>>> >>> metadata approach to fundamentally modify behavior (as opposed to
>>>> >>> aestethics/UI) of the IPython Notebook.
>>>> >>>
>>>> >>> The issue, stated in the context of the nesting/alts/etc cells extension,
>>>> >>> is that a notebook that has branching/alternates *requires* that they be
>>>> >>> understood as such, rather than simply benefiting from it.
>>>> >>>
>>>> >>> The ability to distribute notebooks I write and have them work properly
>>>> >>> is entirely core to my usecase for IPython. If I can't do so, what I
>>>> >>> personally can get IPython or IPython notebooks to do on my own machine is
>>>> >>> not something I have any real interest in. Now you may be thinking to
>>>> >>> yourself "But Gabe, no one is using your fork so you can't do that now with
>>>> >>> your implementation anyway". That is true, but if someone without my fork
>>>> >>> installed manages to get their hands on a notebook which uses the nesting
>>>> >>> features, it will break when they try to load it.
>>>> >>>
>>>> >>> If I create an extension as you are describing, create a complex notebook
>>>> >>> using it, and someone without the plugin installed finds it, downloads it,
>>>> >>> and runs it, it will run fine and happily give them incorrect results
>>>> >>> without even noticing the extra bits I stuck in the metadata.
>>>> >>>
>>>> >>> The core issue here is that running a notebook with branching as a linear
>>>> >>> notebook by executing each of the branches in sequence is actually erroneous
>>>> >>> and will produce undefined, untrustworthy, and likely incorrect, behavior
>>>> >>> and output. The reason for this is that branches/alternatives are assumed to
>>>> >>> be mutually exclusive by the computational model, and can alter objects
>>>> >>> in-place in manners that can have unintended cumulative effects.
>>>> >>>
>>>> >>> As a very simple example consider branches which handle outliers in a
>>>> >>> certain variable by modifying the variable in-place and trimming its values
>>>> >>> by .1, 1, 5, and 10%, respectively,  using quantiles and then consider what
>>>> >>> would happen if these branches were all run in an arbitrary order.
>>>> >>>
>>>> >>> It is easy to see that the outcome from running all the branches (which
>>>> >>> is what will silently happen if the notebook is treated as a standard linear
>>>> >>> notebook because the plugin is not being used) does not reflect any of the
>>>> >>> choices intended by the author and more complex situations could be
>>>> >>> difficult to predict at all without sitting down and thinking about it.
>>>> >>>
>>>> >>> As such, I would not be comfortable distributing branching notebooks
>>>> >>> using the extension mechanism as I understand it to exist now because a) I
>>>> >>> feel it indirectly damages the type of scientific reprodicibility and result
>>>> >>> trustworthiness I seek to advance, and b) I don't want to spend all my time
>>>> >>> fielding angry emails/bugreports from notebook authors who sent their
>>>> >>> notebooks to collaborators who didn't have the plugin installed.
>>>> >>>
>>>> >>>
>>>> >>>>
>>>> >>>>
>>>> >>>> <snip>
>>>> >>>>
>>>> >>>> > Consider the example of classifying new data based on a training set
>>>> >>>> > via
>>>> >>>> > KNN, SVM, and GLM approaches. These approaches all need different sets
>>>> >>>> > of
>>>> >>>> > parameters, return different types of objects as the output of the
>>>> >>>> > fitting
>>>> >>>> > function, may have subtley different behaviour when being used for
>>>> >>>> > prediction, etc.
>>>> >>>>
>>>> >>>> Yep, that is the big challenge with the branching idea in general.  It
>>>> >>>> is not always true that the members of the alt sets can be swapped
>>>> >>>> out.
>>>> >>>
>>>> >>>
>>>> >>> And under the model I am envisioning, that is actually an informative
>>>> >>> and queriable feature, rather than a drawback. See my discussion above
>>>> >>> regarding terminal branches.
>>>> >>>
>>>> >>>>
>>>> >>>>
>>>> >>>> <snip>
>>>> >>>>
>>>> >>>> I hope you can see that I really like the general idea and think the
>>>> >>>> usage cases you are describing are really important.  I think I can
>>>> >>>> speak for the project in saying that we want the notebook to be useful
>>>> >>>> for things like this.  But I think our abstractions are important
>>>> >>>> enough that we make every attempt to see how we can do these while
>>>> >>>> leveraging our existing abstractions.  This is partially a question
>>>> >>>> about implementation, but also partly a question about how the new
>>>> >>>> features are thought about.  The reason we don't like to break
>>>> >>>> abstractions for new features is that we have found an interesting
>>>> >>>> relationship between abstraction breaking and new features.  We have
>>>> >>>> found that when a new feature/idea breaks a core abstraction that we
>>>> >>>> have thought about very carefully, it is usually because the feature
>>>> >>>> has not been fully understood.  Time and time again, we have found
>>>> >>>> that when we take the time to fully understand the feature, it usually
>>>> >>>> fits within our abstractions beautifully and is even much better that
>>>> >>>> we ever imagined it could be.
>>>> >>>>
>>>> >>>> The plugin idea above is a perfect example of this.  By preserving the
>>>> >>>> abstractions the new feature itself a multiplication of even new
>>>> >>>> functionality:
>>>> >>>>
>>>> >>>> * The resulting notebooks can still be version controlled.  This means
>>>> >>>> that the different alt-cell can be thrown into git and when we develop
>>>> >>>> a visual diff tool for notebooks, they will *just work*.
>>>> >>>
>>>> >>>
>>>> >>> I don't really understand this point. I have numerous fork-based
>>>> >>> non-linear notebooks under version control.
>>>> >>>
>>>> >>> Also, when you have a visual diff tool, it will successfully do something
>>>> >>> when given a linear+metadata branching notebook, but whether that something
>>>> >>> would be to deliver the information required to understand changes to
>>>> >>> non-linear notebooks  is less clear (and seems somewhat unlikely).
>>>> >>>
>>>> >>>>
>>>> >>>> * The notebooks can immediately leverage the abstractions we have put
>>>> >>>> into place for converting notebooks to different formats.  You could
>>>> >>>> write custom transformers to present the notebook in a reveal.js
>>>> >>>> giving alt-cells special treatment.
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> I could write custom transformers, this is true, but the default behavior
>>>> >>> would treat the notebook as if it actually were linear (instead of just
>>>> >>> being stored that way) which is problematic.
>>>> >>>
>>>> >>>
>>>> >>>>
>>>> >>>> * All of this can be done, and into the hands of user, without going
>>>> >>>> through those overly conservative IPython developers ;-)
>>>> >>>> * It will just work with nbviewer as well.
>>>> >>>
>>>> >>>
>>>> >>> Again, I disagree. It would *display* in nbviewer, but not work, in that
>>>> >>> the display would be actively misleading regarding what the notebook would
>>>> >>> do when executed properly.
>>>> >>>
>>>> >>>>
>>>> >>>> * It provides a cleanly abstracted foundation for other people to build
>>>> >>>> upon
>>>> >>>
>>>> >>>
>>>> >>> I agree that this is important, but it is not clear to me that it would
>>>> >>> be more true in the case that I created the extension via custom JS than it
>>>> >>> would if nesting were supported in the actual ipynb format and core notebook
>>>> >>> mechanisms.
>>>> >>>
>>>> >>>>
>>>> >>>>
>>>> >>>> In summary, we are trying to build an architecture that allows a few
>>>> >>>> simple abstractions (we actually don't have that many!) to combine in
>>>> >>>> boundless ways to create features we never planned on, but that "just
>>>> >>>> work".
>>>> >>>
>>>> >>>
>>>> >>> I agree that the customjs + metadata extensions approach is very powerful
>>>> >>> and almost infinitely versatile. I think it is great for extensions which
>>>> >>> change appearance/rendering/UI details of how the notebook behaves.
>>>> >>>
>>>> >>> As far as I can see, however,  it has some signficant problems with
>>>> >>> regard to extensions which fundamentally change non-rendering behavior of
>>>> >>> notebooks (please correct me if I'm wrong), namely:
>>>> >>>
>>>> >>> There is no guarantee that notebooks authored using an extension which
>>>> >>> alters fundamental behaviors will work or visibly fail in the absence of
>>>> >>> that extension
>>>> >>> There is no way for an individual notebook to require a particular
>>>> >>> extension
>>>> >>> There is no way to ensure that two extensions are compatible with
>>>> >>> each-other
>>>> >>> There is no standard/unified way for end-users to install extensions
>>>> >>> There is no way for users to determine which extensions they have
>>>> >>>
>>>> >>> The first point is not true of extensions which exclusively affect
>>>> >>> rendering and UI, making the rest of the points minor nuisances rather than
>>>> >>> critical issues.
>>>> >>>
>>>> >>> Looking forward to hearing your (further) thoughts about this stuff and
>>>> >>> hopefully meeting you in person soon.
>>>> >>>
>>>> >>> ~G
>>>> >>>
>>>> >>> --
>>>> >>> Gabriel Becker
>>>> >>> Graduate Student
>>>> >>> Statistics Department
>>>> >>> University of California, Davis
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> Gabriel Becker
>>>> >> Graduate Student
>>>> >> Statistics Department
>>>> >> University of California, Davis
>>>> >>
>>>> >> _______________________________________________
>>>> >> IPython-dev mailing list
>>>> >> IPython-dev at scipy.org
>>>> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Fernando Perez (@fperez_org; http://fperez.org)
>>>> > fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
>>>> > fernando.perez-at-berkeley: contact me here for any direct mail
>>>> >
>>>> > _______________________________________________
>>>> > IPython-dev mailing list
>>>> > IPython-dev at scipy.org
>>>> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>> >
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Brian E. Granger
>>>> Cal Poly State University, San Luis Obispo
>>>> bgranger at calpoly.edu and ellisonbg at gmail.com
>>>> _______________________________________________
>>>> IPython-dev mailing list
>>>> IPython-dev at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>> 
>>> 
>>> 
>>> -- 
>>> Gabriel Becker
>>> Graduate Student
>>> Statistics Department
>>> University of California, Davis
>>> 
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>> 
>> 
>> 
>> -- 
>> Dami?n Avila
>> Scientific Python Developer
>> Quantitative Finance Analyst
>> Statistics, Biostatistics and Econometrics Consultant
>> Biochemist
>> 
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> 
> 
> 
> -- 
> Gabriel Becker
> Graduate Student
> Statistics Department
> University of California, Davis
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131023/50fb4e87/attachment.html>

From zvoros at gmail.com  Wed Oct 23 07:09:14 2013
From: zvoros at gmail.com (=?ISO-8859-1?Q?Zolt=E1n_V=F6r=F6s?=)
Date: Wed, 23 Oct 2013 13:09:14 +0200
Subject: [IPython-dev] Multi-directory support landed in master
In-Reply-To: <CAHNn8BVpCC_0BpueoziL32C-d9=6z5OSkm268GnttLArTXkRfw@mail.gmail.com>
References: <CAHNn8BVpCC_0BpueoziL32C-d9=6z5OSkm268GnttLArTXkRfw@mail.gmail.com>
Message-ID: <5267AE5A.7060504@gmail.com>

Hi all,

A clean install seems to have solved one of the problems I mentioned in 
my previous e-mail, namely, I can now connect to the server, if I 
specify the browser. However, I still can't upload valid notebook files. 
Any ideas?

Cheers,
Zolt?n



On 23/10/13 03:58, MinRK wrote:
>
> Multidirectory support has landed in master, which includes major 
> changes in the URL structure (no more UUID URLs, yay!).
>
> There isn't a UI for navigation yet, but you can enter URLs relative 
> to the initial server directory.
>
> Give it a test drive, and let us know what you find.
>
> Description in IPEP 16 
> <https://github.com/ipython/ipython/wiki/IPEP-16%3A-Notebook-multi-directory-dashboard-and-URL-mapping>.
>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131023/0cc9525a/attachment.html>

From matthias at matthias-k.org  Wed Oct 23 10:33:53 2013
From: matthias at matthias-k.org (Matthias =?ISO-8859-1?Q?K=FCmmerer?=)
Date: Wed, 23 Oct 2013 16:33:53 +0200
Subject: [IPython-dev] fancyboxes in IPython Notebooks
Message-ID: <1730399.HYKpIib2F9@klio>

Hi all,

I am a PhD student in computational neuroscience and I am using IPython 
Notebooks besides data analysis etc. for keeping my lab journal, where I 
document my results. For that, I save the figures that I want to have in the 
lab journal in a subfolder and include them in the notebook using markdown 
(actually I wrote a small library some to automate this process. It is still 
very alpha, but very useful for me [1]).

For the lab journal, I would prefer to have my plots only as small pictures 
included to make scrolling trough the notebook easier. But of course at some 
point I may need the actual plot in full resolution. Thus I thought it would 
be great, if there is an easy way to make the images clickable with the full 
size image appearing after an click, e.g. using jquery fancybox (see [2] or 
[3] for an older version). Basically this is very easy to use, but I am not 
sure how I could make it usable in the notebook. The easiest way would be just 
to include fancybox somehow and write the html-code in the markdown cells for 
the href:

<a class="fancybox" rel="group" href="big_image_1.jpg"><img 
src="small_image_1.jpg" alt="" /></a>

but then still some javascript code has to deal with creating the fancy box. 
It would probably be more elegant to have some kind of extension in the 
IPython Notebook that deals with this automatically and converts markdown 
images in fancy box links.

I would be very interested in this feature and I am definitely willing to 
invest some time on this if you could give me some hints how this could be 
plugged into IPython Notebook best.

Thanks for your help and the work on IPython!
Best,
  Matthias



[1] https://github.com/matthias-k/ipython-journal
[2] http://fancyapps.com/fancybox/
[3] http://fancybox.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131023/8075208a/attachment.sig>

From scopatz at gmail.com  Wed Oct 23 10:48:48 2013
From: scopatz at gmail.com (Anthony Scopatz)
Date: Wed, 23 Oct 2013 09:48:48 -0500
Subject: [IPython-dev] Using sphinx to evaluate notebook cells?
In-Reply-To: <0013520D-74AC-420D-B5CC-7AEE18EC931C@gmail.com>
References: <CAJXewOnbwmyw5VzPtW2pSGjDFOdO1YHyrEffLGw_9q241xPQQg@mail.gmail.com>
	<0013520D-74AC-420D-B5CC-7AEE18EC931C@gmail.com>
Message-ID: <CAPk-6T6RVMfA+oNTFv5u+urCs8VsM1bRMDD-wTfGmKsWvFq2_A@mail.gmail.com>

Hello All,

I'd be much more of a fan of an nbconvert preprocessor than an external
dependency (runipy).

Be Well
Anthony


On Wed, Oct 23, 2013 at 3:11 AM, Matthias Bussonnier <
bussonniermatthias at gmail.com> wrote:

> Hi
>
> I'm not aware of such a plugin.
> Definitively interested as we want our doc as notebook in IPython too.
>
> Have a look at runipy (Google is your friend, and is on pypi iirc). It
> runs notebook headless and generate static HTML from that.
> Having a nbconvert preprocessor that run notebook would also be great!
>
> (Sorry no direct link, from my phone)
> --
> M
>
> Envoy? de mon iPhone
>
> > Le 23 oct. 2013 ? 02:41, Nathan Goldbaum <nathan12343 at gmail.com> a
> ?crit :
> >
> > Hi all,
> >
> > Myself and some of the other yt devs are thinking about ways to improve
> cookbook section of our documentation by replacing the scripts we currently
> host with notebooks.
> >
> > Since some of our cookbook recipes store plots, we'd like to track these
> notebooks in version control in an unevaluated state, mainly to avoid
> versioning images.  We have a CI server that already builds our cookbook
> recipes for our dev docs, so something that integrates with sphinx seems to
> be the way to go. I think I could write a sphinx plugin that does the job,
> but it would need to use whatever machinery IPython uses when notebook
> cells get evaluated.
> >
> > Does anyone know if such a plugin is available somewhere?  If not, does
> anyone know where I should look in the IPython codebase for when I try to
> write it myself?
> >
> > Thanks for your help,
> >
> > -Nathan
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131023/d5323a37/attachment.html>

From bussonniermatthias at gmail.com  Wed Oct 23 11:54:59 2013
From: bussonniermatthias at gmail.com (Matthias BUSSONNIER)
Date: Wed, 23 Oct 2013 17:54:59 +0200
Subject: [IPython-dev] Multi-directory support landed in master
In-Reply-To: <52678559.7060103@gmail.com>
References: <CAHNn8BVpCC_0BpueoziL32C-d9=6z5OSkm268GnttLArTXkRfw@mail.gmail.com>
	<52678559.7060103@gmail.com>
Message-ID: <9BE258D5-F5C4-4B20-BC0F-2B6928B16A05@gmail.com>


Le 23 oct. 2013 ? 10:14, Zolt?n V?r?s a ?crit :

> Hi all,
> 
> I have checked out the changes from github, but I seem to have encountered two issues. From the linux command line
> 
> > BROWSER=chromium-browser ipython notebook
> 
> appears to start the server, but in the browser only an "Error connecting to server." message can be seen. 
> 
> If I do this
> 
> > ipython notebook
> 
> then this takes me to the dashbord in firefox (it's OK for now), and I can open notebooks that are listed, but when I try to upload a notebook, I get an 
> 
> "Invalid file format:
> Uploaded notebooks must be .ipynb files"

This one is partially solve in frontend, but you still cannot upload.
https://github.com/ipython/ipython/pull/4425

Need to investigate on server side now, but probably not today for me.
-- 
M

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131023/d7899076/attachment.html>

From ellisonbg at gmail.com  Wed Oct 23 12:17:57 2013
From: ellisonbg at gmail.com (Brian Granger)
Date: Wed, 23 Oct 2013 09:17:57 -0700
Subject: [IPython-dev] Sample ipython notebooks showcasing interactive
	graphics
In-Reply-To: <5267723A.3020805@creativetrax.com>
References: <CAJfJrc=xUwM0w4GNDiidc-gSECVGzzvYsT+dAiMkyB_pANFVVQ@mail.gmail.com>
	<5267723A.3020805@creativetrax.com>
Message-ID: <CAH4pYpQmgB=tvfk=DQgn7F3-g1Em9jyZ-5CN0VKEYisTKrnCBg@mail.gmail.com>

Jason,

Very cool to see these.  Also, thanks for working on the matplotlib stuff.

Have you looked at Jonathan's widget stuff?  The advantage of that
over raw Comm stuff is that widgets can be nested inside one another
for reuse and composition...widgets also have carefully managed
lifecycles and multicell synchronization logic...

Cheers,

Brian


On Tue, Oct 22, 2013 at 11:52 PM, Jason Grout
<jason-sage at creativetrax.com> wrote:
> On 10/21/13 2:02 PM, Abhishek Pratap wrote:
>> *PS: looking for something that can be slickly integrated into a webpage
>> / Ipython notebook*
>>
>
> Since you ask about integrating into a webpage, I'll mention that we're
> doing a lot of interactive stuff with the Sage Cell server (based on
> IPython+Sage [1], which includes lots and lots of other packages), which
> is trivial to embed into a webpage.  Here are some recent examples using
> IPython's new Comm architecture that is currently in review:
>
> http://sagecell.sagemath.org/?q=fyjgmk
>
> http://sagecell.sagemath.org/?q=rdsbja
>
> http://sagecell.sagemath.org/?q=hpjfxz
>
> I was also working on porting matplotlib's interactive backend to the
> Comm framework.
>
> It's easy to embed these things into a webpage.  Just follow the
> directions here: http://sagecell.sagemath.org/static/about.html.  See
> http://buzzard.ups.edu/ for an example.
>
> Also, you might check out Sage interacts, which is our current way of
> doing interactive things: See http://interact.sagemath.org/ and
> http://wiki.sagemath.org/interact/ for examples.
>
> Thanks,
>
> Jason
>
> [1] http://sagemath.org
>
> --
> Jason Grout
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com


From ellisonbg at gmail.com  Wed Oct 23 12:20:13 2013
From: ellisonbg at gmail.com (Brian Granger)
Date: Wed, 23 Oct 2013 09:20:13 -0700
Subject: [IPython-dev] Sample ipython notebooks showcasing interactive
	graphics
In-Reply-To: <CAH4pYpQmgB=tvfk=DQgn7F3-g1Em9jyZ-5CN0VKEYisTKrnCBg@mail.gmail.com>
References: <CAJfJrc=xUwM0w4GNDiidc-gSECVGzzvYsT+dAiMkyB_pANFVVQ@mail.gmail.com>
	<5267723A.3020805@creativetrax.com>
	<CAH4pYpQmgB=tvfk=DQgn7F3-g1Em9jyZ-5CN0VKEYisTKrnCBg@mail.gmail.com>
Message-ID: <CAH4pYpSwTJsksZ02EKbM5GXVh5ouWFtgKLPAo4aXQ2W4XutRWQ@mail.gmail.com>

Oh I should also mention that the widget stuff in includes all of the
basic widgets you would want (checkbox, slider, drop down menu,
textbox, etc.).

Cheers,

Brian

On Wed, Oct 23, 2013 at 9:17 AM, Brian Granger <ellisonbg at gmail.com> wrote:
> Jason,
>
> Very cool to see these.  Also, thanks for working on the matplotlib stuff.
>
> Have you looked at Jonathan's widget stuff?  The advantage of that
> over raw Comm stuff is that widgets can be nested inside one another
> for reuse and composition...widgets also have carefully managed
> lifecycles and multicell synchronization logic...
>
> Cheers,
>
> Brian
>
>
> On Tue, Oct 22, 2013 at 11:52 PM, Jason Grout
> <jason-sage at creativetrax.com> wrote:
>> On 10/21/13 2:02 PM, Abhishek Pratap wrote:
>>> *PS: looking for something that can be slickly integrated into a webpage
>>> / Ipython notebook*
>>>
>>
>> Since you ask about integrating into a webpage, I'll mention that we're
>> doing a lot of interactive stuff with the Sage Cell server (based on
>> IPython+Sage [1], which includes lots and lots of other packages), which
>> is trivial to embed into a webpage.  Here are some recent examples using
>> IPython's new Comm architecture that is currently in review:
>>
>> http://sagecell.sagemath.org/?q=fyjgmk
>>
>> http://sagecell.sagemath.org/?q=rdsbja
>>
>> http://sagecell.sagemath.org/?q=hpjfxz
>>
>> I was also working on porting matplotlib's interactive backend to the
>> Comm framework.
>>
>> It's easy to embed these things into a webpage.  Just follow the
>> directions here: http://sagecell.sagemath.org/static/about.html.  See
>> http://buzzard.ups.edu/ for an example.
>>
>> Also, you might check out Sage interacts, which is our current way of
>> doing interactive things: See http://interact.sagemath.org/ and
>> http://wiki.sagemath.org/interact/ for examples.
>>
>> Thanks,
>>
>> Jason
>>
>> [1] http://sagemath.org
>>
>> --
>> Jason Grout
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu and ellisonbg at gmail.com



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com


From zvoros at gmail.com  Wed Oct 23 12:39:30 2013
From: zvoros at gmail.com (=?ISO-8859-1?Q?Zolt=E1n_V=F6r=F6s?=)
Date: Wed, 23 Oct 2013 18:39:30 +0200
Subject: [IPython-dev] Multi-directory support landed in master
In-Reply-To: <9BE258D5-F5C4-4B20-BC0F-2B6928B16A05@gmail.com>
References: <CAHNn8BVpCC_0BpueoziL32C-d9=6z5OSkm268GnttLArTXkRfw@mail.gmail.com>
	<52678559.7060103@gmail.com>
	<9BE258D5-F5C4-4B20-BC0F-2B6928B16A05@gmail.com>
Message-ID: <5267FBC2.6030406@gmail.com>

Thanks, Matthias for the feedback! I think I can live with it now (I can 
still copy the notebooks into the root directory), I just wanted to make 
sure that this issue is known.

Cheers,
Zolt?n

On 23/10/13 17:54, Matthias BUSSONNIER wrote:
>
> Le 23 oct. 2013 ? 10:14, Zolt?n V?r?s a ?crit :
>
>> Hi all,
>>
>> I have checked out the changes from github, but I seem to have 
>> encountered two issues. From the linux command line
>>
>> > BROWSER=chromium-browser ipython notebook
>>
>> appears to start the server, but in the browser only an "Error 
>> connecting to server." message can be seen.
>>
>> If I do this
>>
>> > ipython notebook
>>
>> then this takes me to the dashbord in firefox (it's OK for now), and 
>> I can open notebooks that are listed, but when I try to upload a 
>> notebook, I get an
>>
>> "Invalid file format:
>> Uploaded notebooks must be .ipynb files"
>
> This one is partially solve in frontend, but you still cannot upload.
> https://github.com/ipython/ipython/pull/4425
>
> Need to investigate on server side now, but probably not today for me.
> -- 
> M
>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131023/4a65ff9b/attachment.html>

From benjaminrk at gmail.com  Wed Oct 23 13:06:04 2013
From: benjaminrk at gmail.com (MinRK)
Date: Wed, 23 Oct 2013 10:06:04 -0700
Subject: [IPython-dev] Embedding IPython Notebook in Flask web app
In-Reply-To: <CAKxBDU8q3r+2E755F77mMFvSeTwFVbTUPmuv=+D4Wx6ugZchfA@mail.gmail.com>
References: <CAKxBDU9hWzpt2bxkuyAYHCtnbBxjxcEdv5Vbc3tAfjemGQnS6w@mail.gmail.com>
	<CAHNn8BVzPj4x0rL5WEQumOR-dpR8bttP4yhSM_aY44aUPHu2KA@mail.gmail.com>
	<CAKxBDU8q3r+2E755F77mMFvSeTwFVbTUPmuv=+D4Wx6ugZchfA@mail.gmail.com>
Message-ID: <CAHNn8BWgeS6AmR+TdEHevFtSK_0a=pD2Z=mJY+PJANr9eDy1Zw@mail.gmail.com>

You should be able to embed an iframe pointed to a particular notebook. You
can also with minor customization execute the code you need at startup.


On Tue, Oct 22, 2013 at 10:48 PM, Yang Zhang <yanghatespam at gmail.com> wrote:

> Right, I wasn't anticipating anything *not* involving spinning up separate
> servers, but I was wondering if there was anything in the way of doing
> that/managing them, and (more importantly) whether I can pre-load the
> session with the right environment (is the best bet to produce and
> somehow load a notebook file?).
>
> On Tue, Oct 22, 2013 at 8:21 PM, MinRK <benjaminrk at gmail.com> wrote:
> > Since all of the existing notebook web handlers are for tornado, you
> would
> > have to either rewrite the web side with django instead of tornado, or
> > *also* run a tornado webserver, and embed that content on your page (via
> > iframe or otherwise).
> >
> >
> > On Tue, Oct 22, 2013 at 7:40 PM, Yang Zhang <yanghatespam at gmail.com>
> wrote:
> >>
> >> I'm interested in embedding IPython Notebook in a Python (Flask) web
> app.
> >>
> >> This web app essentially lets users browse/view datasets.  When
> >> viewing a dataset, it would be great if we could add a button that
> >> starts an IPython Notebook (pre-loaded with the dataset and some
> >> utility libraries) to allow users to deep-dive into that dataset.
> >>
> >> I know this has been brought up a couple times in the past but I'm
> >> just asking again in case the situation has changed, since it's been a
> >> while, and also our situation is slightly different - we're not
> >> looking to provide generic IPython Notebook hosting, and we're not
> >> worried about security (this is an internal web app to just our team,
> >> all of whom have access to the underlying data anyway).
> >>
> >> I'm basically looking for the Notebook server analogy to
> >> IPython.start_ipython().  Any hints on the most straightforward route
> >> would be greatly appreciated.  Thanks in advance!
> >> _______________________________________________
> >> IPython-dev mailing list
> >> IPython-dev at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >
> >
> >
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> >
>
>
>
> --
> Yang Zhang
> http://yz.mit.edu/
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131023/bec4faf6/attachment.html>

From ellisonbg at gmail.com  Wed Oct 23 13:44:03 2013
From: ellisonbg at gmail.com (Brian Granger)
Date: Wed, 23 Oct 2013 10:44:03 -0700
Subject: [IPython-dev] fancyboxes in IPython Notebooks
In-Reply-To: <1730399.HYKpIib2F9@klio>
References: <1730399.HYKpIib2F9@klio>
Message-ID: <CAH4pYpTYujb1uDvotW8LavukgTCFWDmc3m02B2-igyyrXbDiZw@mail.gmail.com>

We should probably have an event that fires after the markdown cell is
rendered that third party extensions can handle for things like this.

On Wed, Oct 23, 2013 at 7:33 AM, Matthias K?mmerer
<matthias at matthias-k.org> wrote:
> Hi all,
>
> I am a PhD student in computational neuroscience and I am using IPython
> Notebooks besides data analysis etc. for keeping my lab journal, where I
> document my results. For that, I save the figures that I want to have in the
> lab journal in a subfolder and include them in the notebook using markdown
> (actually I wrote a small library some to automate this process. It is still
> very alpha, but very useful for me [1]).
>
> For the lab journal, I would prefer to have my plots only as small pictures
> included to make scrolling trough the notebook easier. But of course at some
> point I may need the actual plot in full resolution. Thus I thought it would
> be great, if there is an easy way to make the images clickable with the full
> size image appearing after an click, e.g. using jquery fancybox (see [2] or
> [3] for an older version). Basically this is very easy to use, but I am not
> sure how I could make it usable in the notebook. The easiest way would be just
> to include fancybox somehow and write the html-code in the markdown cells for
> the href:
>
> <a class="fancybox" rel="group" href="big_image_1.jpg"><img
> src="small_image_1.jpg" alt="" /></a>
>
> but then still some javascript code has to deal with creating the fancy box.
> It would probably be more elegant to have some kind of extension in the
> IPython Notebook that deals with this automatically and converts markdown
> images in fancy box links.
>
> I would be very interested in this feature and I am definitely willing to
> invest some time on this if you could give me some hints how this could be
> plugged into IPython Notebook best.
>
> Thanks for your help and the work on IPython!
> Best,
>   Matthias
>
>
>
> [1] https://github.com/matthias-k/ipython-journal
> [2] http://fancyapps.com/fancybox/
> [3] http://fancybox.net/
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com


From pi at berkeley.edu  Wed Oct 23 14:21:03 2013
From: pi at berkeley.edu (Paul Ivanov)
Date: Wed, 23 Oct 2013 11:21:03 -0700
Subject: [IPython-dev] Multi-directory support landed in master
In-Reply-To: <CAHNn8BVpCC_0BpueoziL32C-d9=6z5OSkm268GnttLArTXkRfw@mail.gmail.com>
References: <CAHNn8BVpCC_0BpueoziL32C-d9=6z5OSkm268GnttLArTXkRfw@mail.gmail.com>
Message-ID: <20131023182103.GA16331@HbI-OTOH.berkeley.edu>

Two things:

MinRK, on 2013-10-22 18:58,  wrote:
> Give it a test drive, and let us know what you find.

1. run `iptest` which will run the full IPython test suite
(`iptest --fast` will run the test suite in parallel with as many
cores as you have)

2. If you do 1, you will likely find out that the html test suite
does *not* get run, and the test suite summary will report that
tornado is among the libraries NOT available at test time. That's
because we now depend on tornado 3.1 (even though running the
notebook server with older version of tornado will mostly work
for now). Logic to report and notify users of their outdated
tornado will be put in place in a future PR.

best,
-- 
                   _
                  / \
                A*   \^   -
             ,./   _.`\\ / \
            / ,--.S    \/   \
           /  `"~,_     \    \
     __o           ?
   _ \<,_         /:\
--(_)/-(_)----.../ | \
--------------.......J
Paul Ivanov
http://pirsquared.org


From apratap at sagebase.org  Wed Oct 23 18:59:50 2013
From: apratap at sagebase.org (Abhishek Pratap)
Date: Wed, 23 Oct 2013 15:59:50 -0700
Subject: [IPython-dev] Sample ipython notebooks showcasing interactive
	graphics
In-Reply-To: <CAH4pYpSwTJsksZ02EKbM5GXVh5ouWFtgKLPAo4aXQ2W4XutRWQ@mail.gmail.com>
References: <CAJfJrc=xUwM0w4GNDiidc-gSECVGzzvYsT+dAiMkyB_pANFVVQ@mail.gmail.com>
	<5267723A.3020805@creativetrax.com>
	<CAH4pYpQmgB=tvfk=DQgn7F3-g1Em9jyZ-5CN0VKEYisTKrnCBg@mail.gmail.com>
	<CAH4pYpSwTJsksZ02EKbM5GXVh5ouWFtgKLPAo4aXQ2W4XutRWQ@mail.gmail.com>
Message-ID: <CAJfJrcmzYXJAB8-xS1e10RtT5jDPAqd4iP+gvVe_ihRiGqQ_gg@mail.gmail.com>

Thanks everyone for the pointers so far.

@Zolt?n : I tried doing something similar with NVd3 library but for some
reason it doesn't work. However a simple D3 plot renders.

Here is the summary of what I tried

http://nbviewer.ipython.org/urls/raw.github.com/apratap/appys/master/ipy_notebooks/testing_IPython_D3_n_NVD3-checkpoint.ipynb

Direct link to Nb:
https://raw.github.com/apratap/appys/master/ipy_notebooks/testing_IPython_D3_n_NVD3-checkpoint.ipynb

It will be very helpful if I can get some help to make this work.

Cheers!
-Abhi


On Wed, Oct 23, 2013 at 9:20 AM, Brian Granger <ellisonbg at gmail.com> wrote:

> Oh I should also mention that the widget stuff in includes all of the
> basic widgets you would want (checkbox, slider, drop down menu,
> textbox, etc.).
>
> Cheers,
>
> Brian
>
> On Wed, Oct 23, 2013 at 9:17 AM, Brian Granger <ellisonbg at gmail.com>
> wrote:
> > Jason,
> >
> > Very cool to see these.  Also, thanks for working on the matplotlib
> stuff.
> >
> > Have you looked at Jonathan's widget stuff?  The advantage of that
> > over raw Comm stuff is that widgets can be nested inside one another
> > for reuse and composition...widgets also have carefully managed
> > lifecycles and multicell synchronization logic...
> >
> > Cheers,
> >
> > Brian
> >
> >
> > On Tue, Oct 22, 2013 at 11:52 PM, Jason Grout
> > <jason-sage at creativetrax.com> wrote:
> >> On 10/21/13 2:02 PM, Abhishek Pratap wrote:
> >>> *PS: looking for something that can be slickly integrated into a
> webpage
> >>> / Ipython notebook*
> >>>
> >>
> >> Since you ask about integrating into a webpage, I'll mention that we're
> >> doing a lot of interactive stuff with the Sage Cell server (based on
> >> IPython+Sage [1], which includes lots and lots of other packages), which
> >> is trivial to embed into a webpage.  Here are some recent examples using
> >> IPython's new Comm architecture that is currently in review:
> >>
> >> http://sagecell.sagemath.org/?q=fyjgmk
> >>
> >> http://sagecell.sagemath.org/?q=rdsbja
> >>
> >> http://sagecell.sagemath.org/?q=hpjfxz
> >>
> >> I was also working on porting matplotlib's interactive backend to the
> >> Comm framework.
> >>
> >> It's easy to embed these things into a webpage.  Just follow the
> >> directions here: http://sagecell.sagemath.org/static/about.html.  See
> >> http://buzzard.ups.edu/ for an example.
> >>
> >> Also, you might check out Sage interacts, which is our current way of
> >> doing interactive things: See http://interact.sagemath.org/ and
> >> http://wiki.sagemath.org/interact/ for examples.
> >>
> >> Thanks,
> >>
> >> Jason
> >>
> >> [1] http://sagemath.org
> >>
> >> --
> >> Jason Grout
> >>
> >> _______________________________________________
> >> IPython-dev mailing list
> >> IPython-dev at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >
> >
> >
> > --
> > Brian E. Granger
> > Cal Poly State University, San Luis Obispo
> > bgranger at calpoly.edu and ellisonbg at gmail.com
>
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu and ellisonbg at gmail.com
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131023/812e6897/attachment.html>

From fperez.net at gmail.com  Wed Oct 23 23:42:42 2013
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 23 Oct 2013 20:42:42 -0700
Subject: [IPython-dev] ipython with sync
In-Reply-To: <CACLE5GC5PAnXxw99PJPr_HYAP3KWYdZCmWf=ZpNtK0vZa6yzvw@mail.gmail.com>
References: <CACLE5GDoXVOeEbEKZOJBzVbHAS=71RwhXbLfAkgfw0+U3rtC-w@mail.gmail.com>
	<CAH4pYpS0rEychGGcmu_zmdM-xtpJPqU+DmFtyc_8QP7938SjAw@mail.gmail.com>
	<CACLE5GCM4LAdnGXGXhnE=ssSfU6_4ZNeQ+y0scBYB0gbZrT=Tg@mail.gmail.com>
	<CAH4pYpQSKj83qi7Td7Z8xbpT5nBLqcfWch-9gVZ_gjggy5DgEQ@mail.gmail.com>
	<CACLE5GC5PAnXxw99PJPr_HYAP3KWYdZCmWf=ZpNtK0vZa6yzvw@mail.gmail.com>
Message-ID: <CAHAreOrX=ngtM++2C8zymoNaLzNu312cB-VLsf9JbUdYN0-gLw@mail.gmail.com>

Thanks, William! I'd been on travel and hadn't been monitoring the list, I
just saw this. Much appreciated.

Best,

f


On Sat, Oct 12, 2013 at 3:22 PM, William Stein <wstein at gmail.com> wrote:

> On Fri, Sep 13, 2013 at 10:44 AM, Brian Granger <ellisonbg at gmail.com>
> wrote:
> > Thanks for this link, that is helpful.
>
> Prompted by your message, I just also BSD licensed the IPython
> integration code I wrote for https://cloud.sagemath.com
>
> It's here:
>
> https://gist.github.com/williamstein/6955561
>
> This has all the monkey patching, setting things up in an iframe, the
> other in-memory document format I use that is diff friendly (instead
> of json).  It's everything I used to integrate into my sync framework.
>
> William
>
> >
> > Cheers,
> >
> > Brian
> >
> > On Thu, Sep 12, 2013 at 4:04 PM, William Stein <wstein at gmail.com> wrote:
> >> On Thu, Sep 12, 2013 at 2:53 PM, Brian Granger <ellisonbg at gmail.com>
> wrote:
> >>> William,
> >>>
> >>> Thanks for notes.  This is really exciting and we are very interested
> >>> in getting live sync to work with IPython itself.  I am traveling this
> >>> week, but will try to have a look soon.  Is the code available
> >>> somewhere to look at?
> >>
> >> Unfortunately, this implementation is very entangled as part of
> >> something I'm building as part of a startup company with UW's Center
> >> for commercialization, and I can't just open source everything.  But
> >> the algorithm is here:
> >>
> >>   https://neil.fraser.name/writing/sync/
> >>
> >> and the author of that paper has an open source Python implementation,
> >> I think...
> >>
> >>
> >>>
> >>> Cheers,
> >>>
> >>> Brian
> >>>
> >>> On Tue, Sep 10, 2013 at 9:11 AM, William Stein <wstein at gmail.com>
> wrote:
> >>>> Hi,
> >>>>
> >>>> Somewhat by accident I spent the last two weeks implementing hosted
> >>>> IPython notebooks with sync for https://cloud.sagemath.com.
> >>>> Initially I had just plan to simplify the port forwarding setup, since
> >>>> what Ondrej Certik was doing with multiple forward and reverse port
> >>>> forwards seemed complicated.  But then I became concerned about
> >>>> multiple users (or users with multiple browsers) overwriting each
> >>>> other's notebooks, because cloud.sagemath projects are frequently
> >>>> shared between multiple people, and everything else does realtime
> >>>> sync.    I had planned just to add some very minimal merge-on-save
> >>>> functionality to avoid major issues, but somehow got sucked into
> >>>> realtime sync (even with the other person's cursor showing).
> >>>>
> >>>> It would be enormously helpful to me if a couple of expert IPython
> >>>> users were to try out what I implemented and just ask a bunch of
> >>>> questions.
> >>>>
> >>>> 1. Go to https://cloud.sagemath.com and make an account; this is
> >>>> completely free, and is hosted on computers at University of
> >>>> Washington.
> >>>>
> >>>> 2. Create a new project.
> >>>>
> >>>> 3. Click +New, then click "IPython" (or paste in a link to an ipython
> >>>> notebook, or upload a file).
> >>>>
> >>>> 4. An IPython notebook server will start, the given .ipynb file should
> >>>> load in a same-domain iframe, and then some of the ipython notebook
> >>>> code is and iframe contents are monkey patched, in order to support
> >>>> sync and better integration with https://cloud.sagemath.com.
> >>>>
> >>>> 5. Open the ipynb file in multiple browsers, and see that changes in
> >>>> one appear in the other, including moving cells around, creating new
> >>>> cells, editing markdown (the rendered version appears elsewhere), etc.
> >>>>   Anything that sets the notebook.dirty flag in IPython causes a sync
> >>>> (evaluating a cell that creates no output doesn't set this flag, at
> >>>> least in 1.0.0, which is a bug in IPython, I guess).
> >>>>
> >>>> Since this is all very new and the first (I guess) realtime sync
> >>>> implementation on top of IPython, there are probably a lot of issues.
> >>>>  Note that if you click the "i" info button to the right, you'll get a
> >>>> link to the standard IPython
> >>>>
> >>>> The other thing of interest is a little Python script called
> >>>> "ipython-notebook", which I wrote.  It basically makes it easy to run
> >>>> an IPython notebook server as a daemon, get the port it is running on,
> >>>> etc.  It's pretty simple but satisfies my use case, and has
> >>>> JSON-output, to make it web friendly.    As I've written it, my script
> >>>> passes several base_url options through by default, which are needed
> >>>> for cloud.sagemath.  Anyway, I've attached it to this email (with a
> >>>> BSD license) in case there is any interest.
> >>>>
> >>>> Regarding the monkey patching in 4 above, the right thing to do would
> >>>> be to explain exactly what hooks/changes in the IPython html client I
> >>>> need in order to do sync, etc., make sure these makes sense to the
> >>>> IPython devs, and send a pull request (or have a coding sprint in
> >>>> Seattle or Berkeley?).  As an example, in order to do sync
> >>>> *efficiently*, I have to be able to set a given cell from JSON -- it's
> >>>> critical to do this in place when possible, since the overhead of
> >>>> creating a new cell is huge (due probably to the overhead of creating
> >>>> CodeMirror editors); however, the fromJSON method in IPython assumes
> >>>> that the cell is brand new -- it would be nice to add an option to
> >>>> make a cell fromJSON without assuming it is empty.
> >>>>
> >>>> The ultimate outcome of this could be a clean well-defined way of
> >>>> doing sync for IPython notebooks using any third-party sync
> >>>> implementation.  IPython might provide their own sync service and
> >>>> there are starting to be others available these days -- e.g., Google
> >>>> has one: https://developers.google.com/drive/realtime/, and maybe
> >>>> Guido van Rosum helped write one for Dropbox recently?
> >>>>
> >>>> Subdirectories:   I noticed, incidentally, that the wakari version of
> >>>> the IPython notebook server allows one to load ipynb files that are in
> >>>> any subdirectory, whereas the standard IPython notebook server
> >>>> doesn't.  For cloud.sagemath, I just spawn a new IPython notebook
> >>>> server for each directory that a user accesses files in right now.
> >>>> This seems cludgy, so I'm interested in the situation regarding adding
> >>>> support for subdirectories.
> >>>>
> >>>> -- William
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> William Stein
> >>>> Professor of Mathematics
> >>>> University of Washington
> >>>> http://wstein.org
> >>>>
> >>>> _______________________________________________
> >>>> IPython-dev mailing list
> >>>> IPython-dev at scipy.org
> >>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Brian E. Granger
> >>> Cal Poly State University, San Luis Obispo
> >>> bgranger at calpoly.edu and ellisonbg at gmail.com
> >>> _______________________________________________
> >>> IPython-dev mailing list
> >>> IPython-dev at scipy.org
> >>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>
> >>
> >>
> >> --
> >> William Stein
> >> Professor of Mathematics
> >> University of Washington
> >> http://wstein.org
> >> _______________________________________________
> >> IPython-dev mailing list
> >> IPython-dev at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >
> >
> >
> > --
> > Brian E. Granger
> > Cal Poly State University, San Luis Obispo
> > bgranger at calpoly.edu and ellisonbg at gmail.com
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
>
> --
> William Stein
> Professor of Mathematics
> University of Washington
> http://wstein.org
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131023/ebe863cc/attachment.html>

From fperez.net at gmail.com  Wed Oct 23 23:46:53 2013
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 23 Oct 2013 20:46:53 -0700
Subject: [IPython-dev] nbviewer with private repos
In-Reply-To: <CAH4pYpQ3thwY9qj+=PoFxkc5sagCbVvUJsZn-R-8FRThodh+HQ@mail.gmail.com>
References: <525C1D95.3090102@telenczuk.pl>
	<CAH4pYpSwW27L++8QZHGQPzjtDvZTCXBsp7T8XF-xDD+873YJMA@mail.gmail.com>
	<525C1F73.6020509@telenczuk.pl>
	<CAH4pYpT9Luj6k+RxN2b8u3CWBBKH12ustbivo4MWnV+vcDmMtw@mail.gmail.com>
	<525C2238.8030807@telenczuk.pl>
	<CAH4pYpQ3thwY9qj+=PoFxkc5sagCbVvUJsZn-R-8FRThodh+HQ@mail.gmail.com>
Message-ID: <CAHAreOp6ZypkF4SpFFU-KEhvewx+j-YAP1-Z-puAkYMuGxX1_g@mail.gmail.com>

And likely for a very long time to come: the moment we start messing with
people's private repositories (were we to do so), we're entering territory
where we expose the open source IPython project to potential liability
issues that I am very, very uncomfortable with.

I know several of us have talked about in various venues, I just wanted to
mention it here for the benefit of everyone else...

Cheers,

f


On Mon, Oct 14, 2013 at 9:58 AM, Brian Granger <ellisonbg at gmail.com> wrote:

> The problem with this feature is that it involves authentication with
> those services, which involves *very serious* security risk that we
> are not in a position to tackle at this point.
>
> On Mon, Oct 14, 2013 at 9:56 AM, Bartosz <mail at telenczuk.pl> wrote:
> > I am just asking if you would be interested in a pull request, but from
> > Matthias explanation I see why that might be a non-trivial task.
> > Perhaps I will try running a local copy.
> >
> > Thanks!
> >
> > Bartosz
> >
> > On Mon 14 Oct 2013 06:52:38 PM CEST, Brian Granger wrote:
> >> I don't understand what you mean by "eventual PRs"
> >>
> >> On Mon, Oct 14, 2013 at 9:44 AM, Bartosz <mail at telenczuk.pl> wrote:
> >>> How about eventual PRs? Is it something you would  like to see in
> >>> nbviewer?
> >>>
> >>> Bartosz
> >>>
> >>> On Mon 14 Oct 2013 06:43:35 PM CEST, Brian Granger wrote:
> >>>> We have no immediate plans to do this.
> >>>>
> >>>> On Mon, Oct 14, 2013 at 9:36 AM, Bartosz <mail at telenczuk.pl> wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> Is there any work in progress on using nbviewer with private repos
> (GH
> >>>>> and bitbucket)? The FAQ mentions that it's being worked on, but I did
> >>>>> not find anything in the issues/PRs on Github.
> >>>>>
> >>>>> BTW Bitbucket offers unlimited free private repositories for
> academia,
> >>>>> so eiht nbviewer it might become great collaboration tool.
> >>>>>
> >>>>> Cheers,
> >>>>>
> >>>>> Bartosz
> >>>>> _______________________________________________
> >>>>> IPython-dev mailing list
> >>>>> IPython-dev at scipy.org
> >>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>>>
> >>>>
> >>>>
> >>> _______________________________________________
> >>> IPython-dev mailing list
> >>> IPython-dev at scipy.org
> >>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>
> >>
> >>
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu and ellisonbg at gmail.com
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131023/6e5bcd43/attachment.html>

From zvoros at gmail.com  Thu Oct 24 06:21:11 2013
From: zvoros at gmail.com (=?ISO-8859-1?Q?Zolt=E1n_V=F6r=F6s?=)
Date: Thu, 24 Oct 2013 12:21:11 +0200
Subject: [IPython-dev] Multi-directory support landed in master
In-Reply-To: <20131023182103.GA16331@HbI-OTOH.berkeley.edu>
References: <CAHNn8BVpCC_0BpueoziL32C-d9=6z5OSkm268GnttLArTXkRfw@mail.gmail.com>
	<20131023182103.GA16331@HbI-OTOH.berkeley.edu>
Message-ID: <5268F497.7030505@gmail.com>


On 23/10/13 20:21, Paul Ivanov wrote:
> Two things:
>
> MinRK, on 2013-10-22 18:58,  wrote:
>> Give it a test drive, and let us know what you find.
> 1. run `iptest` which will run the full IPython test suite
> (`iptest --fast` will run the test suite in parallel with as many
> cores as you have)
I have run the test, and it failed 13 times out of 13. In all cases the 
source of the error was a missing package:

 > Traceback (most recent call last):
   File "<string>", line 1, in <module>
   File "IPython/testing/iptest.py", line 519, in run_iptest
ImportError: cannot import name globalipapp

Where should this be gotten from? It seems not to be a standard python 
package. However,

 > iptest all

returns OK. Is this what is supposed to happen? The docs are a bit 
inconsistent on this issue.

> 2. If you do 1, you will likely find out that the html test suite
> does *not* get run, and the test suite summary will report that
> tornado is among the libraries NOT available at test time. That's
> because we now depend on tornado 3.1 (even though running the
> notebook server with older version of tornado will mostly work
> for now). Logic to report and notify users of their outdated
> tornado will be put in place in a future PR.
IPython doesn't work anymore with earlier versions of tornado, but I 
could fix that with

 > pip install tornado

Cheers,
Zolt?n


From jason-sage at creativetrax.com  Thu Oct 24 07:03:03 2013
From: jason-sage at creativetrax.com (Jason Grout)
Date: Thu, 24 Oct 2013 06:03:03 -0500
Subject: [IPython-dev] Sample ipython notebooks showcasing interactive
 graphics
In-Reply-To: <CAH4pYpSwTJsksZ02EKbM5GXVh5ouWFtgKLPAo4aXQ2W4XutRWQ@mail.gmail.com>
References: <CAJfJrc=xUwM0w4GNDiidc-gSECVGzzvYsT+dAiMkyB_pANFVVQ@mail.gmail.com>	<5267723A.3020805@creativetrax.com>	<CAH4pYpQmgB=tvfk=DQgn7F3-g1Em9jyZ-5CN0VKEYisTKrnCBg@mail.gmail.com>
	<CAH4pYpSwTJsksZ02EKbM5GXVh5ouWFtgKLPAo4aXQ2W4XutRWQ@mail.gmail.com>
Message-ID: <5268FE67.3070104@creativetrax.com>

On 10/23/13 11:20 AM, Brian Granger wrote:
> Oh I should also mention that the widget stuff in includes all of the
> basic widgets you would want (checkbox, slider, drop down menu,
> textbox, etc.).
>

I've glanced at the widgets, but haven't had time to look at them 
thoroughly.  I'm pretty excited about them, though.  I want to see how 
our interacts and your widgets might work together.  Maybe it would make 
sense move our interacts over to use your widgets as the underlying 
technology.  Or maybe it would make sense to make our interacts one of 
the widgets.

Thanks,

Jason



From jason-sage at creativetrax.com  Thu Oct 24 07:17:05 2013
From: jason-sage at creativetrax.com (Jason Grout)
Date: Thu, 24 Oct 2013 06:17:05 -0500
Subject: [IPython-dev] Sample ipython notebooks showcasing interactive
 graphics
In-Reply-To: <5268FE67.3070104@creativetrax.com>
References: <CAJfJrc=xUwM0w4GNDiidc-gSECVGzzvYsT+dAiMkyB_pANFVVQ@mail.gmail.com>	<5267723A.3020805@creativetrax.com>	<CAH4pYpQmgB=tvfk=DQgn7F3-g1Em9jyZ-5CN0VKEYisTKrnCBg@mail.gmail.com>	<CAH4pYpSwTJsksZ02EKbM5GXVh5ouWFtgKLPAo4aXQ2W4XutRWQ@mail.gmail.com>
	<5268FE67.3070104@creativetrax.com>
Message-ID: <526901B1.207@creativetrax.com>

On 10/24/13 6:03 AM, Jason Grout wrote:
> I've glanced at the widgets, but haven't had time to look at them
> thoroughly.  I'm pretty excited about them, though.  I want to see how
> our interacts and your widgets might work together.  Maybe it would make
> sense move our interacts over to use your widgets as the underlying
> technology.  Or maybe it would make sense to make our interacts one of
> the widgets.

I should mention there are other things that might make sense for us to 
  make widgets.  For example, we've been developing a three.js renderer 
for 3d graphics in Sage.  I could see that as a widget.

Thanks,

Jason



From alimanfoo at googlemail.com  Thu Oct 24 09:13:24 2013
From: alimanfoo at googlemail.com (Alistair Miles)
Date: Thu, 24 Oct 2013 14:13:24 +0100
Subject: [IPython-dev] remove --script?
Message-ID: <CAMr-JwZyvNjbpdnG9uq8-UH8ALBkoj=iVAeJstsE8fxafq5gTg@mail.gmail.com>

Hi folks,

I was just browsing through the IPython roadmap and spotted this:

   - (M,3) Move .py export to nbconvert and remove --script

I guess this is a while off, but could I make a vote for *not* removing
--script? Currently I use this feature to make it easy to import functions
between notebooks. I.e., Currently I can have two notebooks on the go, one
effectively importing from the other, because each time they are saved the
.py is also automatically saved, which is very convenient. If I had to
manually export a .py via nbconvert each time that would be a pain, and
would mean the .ipynb and corresponding .py would easily get out of sync.

Btw very much looking forward to 2.0.

Cheers,
Alistair
-- 
Alistair Miles
Head of Epidemiological Informatics
Centre for Genomics and Global Health <http://cggh.org>
The Wellcome Trust Centre for Human Genetics
Roosevelt Drive
Oxford
OX3 7BN
United Kingdom
Web: http://purl.org/net/aliman
Email: alimanfoo at gmail.com
Tel: +44 (0)1865 287721 ***new number***
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131024/acdc7c12/attachment.html>

From davidacoder at hotmail.com  Thu Oct 24 09:43:49 2013
From: davidacoder at hotmail.com (davidacoder)
Date: Thu, 24 Oct 2013 09:43:49 -0400
Subject: [IPython-dev] remove --script?
In-Reply-To: <CAMr-JwZyvNjbpdnG9uq8-UH8ALBkoj=iVAeJstsE8fxafq5gTg@mail.gmail.com>
References: <CAMr-JwZyvNjbpdnG9uq8-UH8ALBkoj=iVAeJstsE8fxafq5gTg@mail.gmail.com>
Message-ID: <BLU403-EAS162B3565A9A53C03B9DC2ECAF0C0@phx.gbl>

Here is another vote along the same lines, I also use --script that way.

Having said that, it would be even nicer if %run would work with .ipynb
files, that way I wouldn't need the duplicate .py files generated by
--script and could still have one notebook depend on another.

Cheers,
David


From: ipython-dev-bounces at scipy.org [mailto:ipython-dev-bounces at scipy.org]
On Behalf Of Alistair Miles
Sent: Thursday, October 24, 2013 9:13 AM
To: ipython-dev at scipy.org
Subject: [IPython-dev] remove --script?

Hi folks,

I was just browsing through the IPython roadmap and spotted this:
? (M,3) Move .py export to nbconvert and remove?--script
I guess this is a while off, but could I make a vote for *not* removing
--script? Currently I use this feature to make it easy to import functions
between notebooks. I.e., Currently I can have two notebooks on the go, one
effectively importing from the other, because each time they are saved the
.py is also automatically saved, which is very convenient. If I had to
manually export a .py via nbconvert each time that would be a pain, and
would mean the .ipynb and corresponding .py would easily get out of sync.

Btw very much looking forward to 2.0.

Cheers,
Alistair
-- 
Alistair Miles
Head of Epidemiological Informatics
Centre for Genomics and Global Health <http://cggh.org>
The Wellcome Trust Centre for Human Genetics
Roosevelt Drive
Oxford
OX3 7BN
United Kingdom
Web: http://purl.org/net/aliman
Email: alimanfoo at gmail.com
Tel: +44 (0)1865 287721 ***new number*** 


From zvoros at gmail.com  Thu Oct 24 09:54:21 2013
From: zvoros at gmail.com (=?ISO-8859-1?Q?Zolt=E1n_V=F6r=F6s?=)
Date: Thu, 24 Oct 2013 15:54:21 +0200
Subject: [IPython-dev] remove --script?
In-Reply-To: <BLU403-EAS162B3565A9A53C03B9DC2ECAF0C0@phx.gbl>
References: <CAMr-JwZyvNjbpdnG9uq8-UH8ALBkoj=iVAeJstsE8fxafq5gTg@mail.gmail.com>
	<BLU403-EAS162B3565A9A53C03B9DC2ECAF0C0@phx.gbl>
Message-ID: <5269268D.8060404@gmail.com>


On 24/10/13 15:43, davidacoder wrote:
> Here is another vote along the same lines, I also use --script that way.
>
> Having said that, it would be even nicer if %run would work with .ipynb
> files, that way I wouldn't need the duplicate .py files generated by
> --script and could still have one notebook depend on another.
>
In that case, why not make autoreload aware of this? One wouldn't even 
have to run or import anything, and the two notebooks would always be in 
synch...

Zolt?n


From davidacoder at hotmail.com  Thu Oct 24 10:02:46 2013
From: davidacoder at hotmail.com (davidacoder)
Date: Thu, 24 Oct 2013 10:02:46 -0400
Subject: [IPython-dev] remove --script?
In-Reply-To: <5269268D.8060404@gmail.com>
References: <CAMr-JwZyvNjbpdnG9uq8-UH8ALBkoj=iVAeJstsE8fxafq5gTg@mail.gmail.com>	<BLU403-EAS162B3565A9A53C03B9DC2ECAF0C0@phx.gbl>
	<5269268D.8060404@gmail.com>
Message-ID: <BLU403-EAS32C9E91A2562B2C0446DCAF0C0@phx.gbl>

Hm, that seems a different problem, i.e. when an import happens and how to
trigger that.

I was referring to a situation where I have one notebook where I might
define a function, and then I have another notebook where I want to use that
function. If I could %run the first notebook from the second, there wouldn't
be a need to ever generate a .py file from the first notebook that I then
import in the second (irrespective of whether I do that via autoreload or
not). I might be missing something, though, pretty new to ipython :)

David

-----Original Message-----
From: ipython-dev-bounces at scipy.org [mailto:ipython-dev-bounces at scipy.org]
On Behalf Of Zolt?n V?r?s
Sent: Thursday, October 24, 2013 9:54 AM
To: ipython-dev at scipy.org
Subject: Re: [IPython-dev] remove --script?


On 24/10/13 15:43, davidacoder wrote:
> Here is another vote along the same lines, I also use --script that way.
>
> Having said that, it would be even nicer if %run would work with 
> .ipynb files, that way I wouldn't need the duplicate .py files 
> generated by --script and could still have one notebook depend on another.
>
In that case, why not make autoreload aware of this? One wouldn't even have
to run or import anything, and the two notebooks would always be in synch...

Zolt?n
_______________________________________________
IPython-dev mailing list
IPython-dev at scipy.org
http://mail.scipy.org/mailman/listinfo/ipython-dev


From zvoros at gmail.com  Thu Oct 24 10:14:59 2013
From: zvoros at gmail.com (=?ISO-8859-1?Q?Zolt=E1n_V=F6r=F6s?=)
Date: Thu, 24 Oct 2013 16:14:59 +0200
Subject: [IPython-dev] remove --script?
In-Reply-To: <BLU403-EAS32C9E91A2562B2C0446DCAF0C0@phx.gbl>
References: <CAMr-JwZyvNjbpdnG9uq8-UH8ALBkoj=iVAeJstsE8fxafq5gTg@mail.gmail.com>	<BLU403-EAS162B3565A9A53C03B9DC2ECAF0C0@phx.gbl>	<5269268D.8060404@gmail.com>
	<BLU403-EAS32C9E91A2562B2C0446DCAF0C0@phx.gbl>
Message-ID: <52692B63.2050801@gmail.com>


On 24/10/13 16:02, davidacoder wrote:
> Hm, that seems a different problem, i.e. when an import happens and how to
> trigger that.
>
> I was referring to a situation where I have one notebook where I might
> define a function, and then I have another notebook where I want to use that
> function. If I could %run the first notebook from the second, there wouldn't
> be a need to ever generate a .py file from the first notebook that I then
> import in the second (irrespective of whether I do that via autoreload or
> not). I might be missing something, though, pretty new to ipython :)
I see your point, and that is what I replied to: if you have a function 
in notebook1, and want to use that in notebook2, then before running the 
code in notebook2, one could check, whether notebook1 has changed 
(meaning, it has been saved to disc) since whatever point in time, and 
if so, then re-run that notebook. autoreload does something similar, 
except, it doesn't check, whether the module has changed, it just 
re-loads it before running the code.

Zolt?n


From davidacoder at hotmail.com  Thu Oct 24 10:21:19 2013
From: davidacoder at hotmail.com (davidacoder)
Date: Thu, 24 Oct 2013 10:21:19 -0400
Subject: [IPython-dev] remove --script?
In-Reply-To: <52692B63.2050801@gmail.com>
References: <CAMr-JwZyvNjbpdnG9uq8-UH8ALBkoj=iVAeJstsE8fxafq5gTg@mail.gmail.com>	<BLU403-EAS162B3565A9A53C03B9DC2ECAF0C0@phx.gbl>	<5269268D.8060404@gmail.com>	<BLU403-EAS32C9E91A2562B2C0446DCAF0C0@phx.gbl>
	<52692B63.2050801@gmail.com>
Message-ID: <BLU403-EAS36568E991299B2A2604E8C3AF0C0@phx.gbl>

But right now one cannot run notebook1 from notebook2 at all, right? Or am I
missing something there? %run notebook1.ipynb doesn't seem to work... Or is
there some other way to run notebook1 from notebook2? I looked around for
quite a while and didn't find anything.

-----Original Message-----
From: ipython-dev-bounces at scipy.org [mailto:ipython-dev-bounces at scipy.org]
On Behalf Of Zolt?n V?r?s
Sent: Thursday, October 24, 2013 10:15 AM
To: ipython-dev at scipy.org
Subject: Re: [IPython-dev] remove --script?


On 24/10/13 16:02, davidacoder wrote:
> Hm, that seems a different problem, i.e. when an import happens and 
> how to trigger that.
>
> I was referring to a situation where I have one notebook where I might 
> define a function, and then I have another notebook where I want to 
> use that function. If I could %run the first notebook from the second, 
> there wouldn't be a need to ever generate a .py file from the first 
> notebook that I then import in the second (irrespective of whether I 
> do that via autoreload or not). I might be missing something, though, 
> pretty new to ipython :)
I see your point, and that is what I replied to: if you have a function in
notebook1, and want to use that in notebook2, then before running the code
in notebook2, one could check, whether notebook1 has changed (meaning, it
has been saved to disc) since whatever point in time, and if so, then re-run
that notebook. autoreload does something similar, except, it doesn't check,
whether the module has changed, it just re-loads it before running the code.

Zolt?n
_______________________________________________
IPython-dev mailing list
IPython-dev at scipy.org
http://mail.scipy.org/mailman/listinfo/ipython-dev


From felix at fbreuer.de  Thu Oct 24 11:17:55 2013
From: felix at fbreuer.de (Felix Breuer)
Date: Thu, 24 Oct 2013 17:17:55 +0200
Subject: [IPython-dev] remove --script?
In-Reply-To: <BLU403-EAS162B3565A9A53C03B9DC2ECAF0C0@phx.gbl>
References: <CAMr-JwZyvNjbpdnG9uq8-UH8ALBkoj=iVAeJstsE8fxafq5gTg@mail.gmail.com>
	<BLU403-EAS162B3565A9A53C03B9DC2ECAF0C0@phx.gbl>
Message-ID: <CADGimVjErPoz9dys6GcOi2fJUVSQ39oOiBCmHhVvw1iu+DmBSA@mail.gmail.com>

I also use notebooks as libraries, so to speak, and am dependent on
--script for that.

If there is another way to achieve the same thing, I'd be open to take up
new habits, though. :) As far as I understand, autoreload does not help
with this, as long as I cannot import an .ipynb file.

Cheers,
Felix


On Thu, Oct 24, 2013 at 3:43 PM, davidacoder <davidacoder at hotmail.com>wrote:

> Here is another vote along the same lines, I also use --script that way.
>
> Having said that, it would be even nicer if %run would work with .ipynb
> files, that way I wouldn't need the duplicate .py files generated by
> --script and could still have one notebook depend on another.
>
> Cheers,
> David
>
>
> From: ipython-dev-bounces at scipy.org [mailto:ipython-dev-bounces at scipy.org]
> On Behalf Of Alistair Miles
> Sent: Thursday, October 24, 2013 9:13 AM
> To: ipython-dev at scipy.org
> Subject: [IPython-dev] remove --script?
>
> Hi folks,
>
> I was just browsing through the IPython roadmap and spotted this:
> ? (M,3) Move .py export to nbconvert and remove --script
> I guess this is a while off, but could I make a vote for *not* removing
> --script? Currently I use this feature to make it easy to import functions
> between notebooks. I.e., Currently I can have two notebooks on the go, one
> effectively importing from the other, because each time they are saved the
> .py is also automatically saved, which is very convenient. If I had to
> manually export a .py via nbconvert each time that would be a pain, and
> would mean the .ipynb and corresponding .py would easily get out of sync.
>
> Btw very much looking forward to 2.0.
>
> Cheers,
> Alistair
> --
> Alistair Miles
> Head of Epidemiological Informatics
> Centre for Genomics and Global Health <http://cggh.org>
> The Wellcome Trust Centre for Human Genetics
> Roosevelt Drive
> Oxford
> OX3 7BN
> United Kingdom
> Web: http://purl.org/net/aliman
> Email: alimanfoo at gmail.com
> Tel: +44 (0)1865 287721 ***new number***
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
http://www.felixbreuer.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131024/c06534d9/attachment.html>

From bussonniermatthias at gmail.com  Thu Oct 24 11:43:44 2013
From: bussonniermatthias at gmail.com (Matthias BUSSONNIER)
Date: Thu, 24 Oct 2013 17:43:44 +0200
Subject: [IPython-dev] remove --script?
In-Reply-To: <CADGimVjErPoz9dys6GcOi2fJUVSQ39oOiBCmHhVvw1iu+DmBSA@mail.gmail.com>
References: <CAMr-JwZyvNjbpdnG9uq8-UH8ALBkoj=iVAeJstsE8fxafq5gTg@mail.gmail.com>
	<BLU403-EAS162B3565A9A53C03B9DC2ECAF0C0@phx.gbl>
	<CADGimVjErPoz9dys6GcOi2fJUVSQ39oOiBCmHhVvw1iu+DmBSA@mail.gmail.com>
Message-ID: <6CAFDF40-334C-42ED-9CB4-0DE0018AC2D8@gmail.com>

Just to be clear on 

	-	(M,3) Move .py export to nbconvert and remove --script

If I remember correctly, 
This means that will remove script in favor of a more general mechanism that
would allow to trigger any conversion as save time. Like **always** save an static
html, or a static .tex --script is awfully restrictive to only py files.
This mechanism will use nbconvert.

That being said, it is not guaranteed that, on dev --script will not be removed
before adding this new mechanism. 

And also, notebook are importable thanks to an import hook which is somewhere in 
IPython, but nobody test it, and nobody maintains it. 
It is though cleaner than saving the .py file IMHO. Just saying' 

-- 
M

From ellisonbg at gmail.com  Thu Oct 24 12:54:08 2013
From: ellisonbg at gmail.com (Brian Granger)
Date: Thu, 24 Oct 2013 09:54:08 -0700
Subject: [IPython-dev] Sample ipython notebooks showcasing interactive
	graphics
In-Reply-To: <526901B1.207@creativetrax.com>
References: <CAJfJrc=xUwM0w4GNDiidc-gSECVGzzvYsT+dAiMkyB_pANFVVQ@mail.gmail.com>
	<5267723A.3020805@creativetrax.com>
	<CAH4pYpQmgB=tvfk=DQgn7F3-g1Em9jyZ-5CN0VKEYisTKrnCBg@mail.gmail.com>
	<CAH4pYpSwTJsksZ02EKbM5GXVh5ouWFtgKLPAo4aXQ2W4XutRWQ@mail.gmail.com>
	<5268FE67.3070104@creativetrax.com> <526901B1.207@creativetrax.com>
Message-ID: <CAH4pYpT6t9x=yOnYKQAs_=xJmzTDsT+aLF01Gvx9HTbbYntP8g@mail.gmail.com>

We plan on creating an interact/manipulate style API in a separate PR
after the widget stuff lands and have already done much of the design
(in our heads...). If all goes well, you should just be able to use
that API and possibly wrap it into Sage's custom syntax.

Cheers,

Brian

On Thu, Oct 24, 2013 at 4:17 AM, Jason Grout
<jason-sage at creativetrax.com> wrote:
> On 10/24/13 6:03 AM, Jason Grout wrote:
>> I've glanced at the widgets, but haven't had time to look at them
>> thoroughly.  I'm pretty excited about them, though.  I want to see how
>> our interacts and your widgets might work together.  Maybe it would make
>> sense move our interacts over to use your widgets as the underlying
>> technology.  Or maybe it would make sense to make our interacts one of
>> the widgets.
>
> I should mention there are other things that might make sense for us to
>   make widgets.  For example, we've been developing a three.js renderer
> for 3d graphics in Sage.  I could see that as a widget.
>
> Thanks,
>
> Jason
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com


From zvoros at gmail.com  Thu Oct 24 13:03:29 2013
From: zvoros at gmail.com (=?ISO-8859-1?Q?Zolt=E1n_V=F6r=F6s?=)
Date: Thu, 24 Oct 2013 19:03:29 +0200
Subject: [IPython-dev] remove --script?
In-Reply-To: <CADGimVjErPoz9dys6GcOi2fJUVSQ39oOiBCmHhVvw1iu+DmBSA@mail.gmail.com>
References: <CAMr-JwZyvNjbpdnG9uq8-UH8ALBkoj=iVAeJstsE8fxafq5gTg@mail.gmail.com>	<BLU403-EAS162B3565A9A53C03B9DC2ECAF0C0@phx.gbl>
	<CADGimVjErPoz9dys6GcOi2fJUVSQ39oOiBCmHhVvw1iu+DmBSA@mail.gmail.com>
Message-ID: <526952E1.7020403@gmail.com>


On 24/10/13 17:17, Felix Breuer wrote:
> I also use notebooks as libraries, so to speak, and am dependent on 
> --script for that.
>
> If there is another way to achieve the same thing, I'd be open to take 
> up new habits, though. :) As far as I understand, autoreload does not 
> help with this, as long as I cannot import an .ipynb file.
>
Yes, that's true. In my original e-mail I was merely _suggesting_ that 
autoreload, or another magic could be made to check for changes of an 
ipynb file. I didn't try to imply that that works now!

Zolt?n


From davidacoder at hotmail.com  Thu Oct 24 13:27:25 2013
From: davidacoder at hotmail.com (davidacoder)
Date: Thu, 24 Oct 2013 13:27:25 -0400
Subject: [IPython-dev] remove --script?
In-Reply-To: <6CAFDF40-334C-42ED-9CB4-0DE0018AC2D8@gmail.com>
References: <CAMr-JwZyvNjbpdnG9uq8-UH8ALBkoj=iVAeJstsE8fxafq5gTg@mail.gmail.com>	<BLU403-EAS162B3565A9A53C03B9DC2ECAF0C0@phx.gbl>	<CADGimVjErPoz9dys6GcOi2fJUVSQ39oOiBCmHhVvw1iu+DmBSA@mail.gmail.com>
	<6CAFDF40-334C-42ED-9CB4-0DE0018AC2D8@gmail.com>
Message-ID: <BLU406-EAS291B7EAF79EF28CBB21FAEAAF0C0@phx.gbl>

> If I remember correctly,
> This means that will remove script in favor of a more general mechanism
that
> would allow to trigger any conversion as save time. Like **always** save
an
> static html, or a static .tex --script is awfully restrictive to only py
files.
> This mechanism will use nbconvert.

That sounds great. What I would find even better is if this was a
per-notebook 
setting (if that is something that exists), or maybe there could be a magic
that
switches this on for the current notebook, or something like that?

> And also, notebook are importable thanks to an import hook which is
> somewhere in IPython, but nobody test it, and nobody maintains it.
> It is though cleaner than saving the .py file IMHO. Just saying'

Ha, this is EXACTLY what I need, thanks for pointing me there! For others
that might be interested, this is in 
examples/notebooks/Importing Notebooks.ipynb in the ipython repo.

Is this something that might move from an example to ipython proper
at some point? I believe this could be incredibly useful for many people.
Switching it on by default might be a bit intrusive, but maybe there
could be a magic that enables this?

Cheers,
David


From bussonniermatthias at gmail.com  Fri Oct 25 03:05:18 2013
From: bussonniermatthias at gmail.com (Matthias BUSSONNIER)
Date: Fri, 25 Oct 2013 09:05:18 +0200
Subject: [IPython-dev] remove --script?
In-Reply-To: <BLU406-EAS291B7EAF79EF28CBB21FAEAAF0C0@phx.gbl>
References: <CAMr-JwZyvNjbpdnG9uq8-UH8ALBkoj=iVAeJstsE8fxafq5gTg@mail.gmail.com>	<BLU403-EAS162B3565A9A53C03B9DC2ECAF0C0@phx.gbl>	<CADGimVjErPoz9dys6GcOi2fJUVSQ39oOiBCmHhVvw1iu+DmBSA@mail.gmail.com>
	<6CAFDF40-334C-42ED-9CB4-0DE0018AC2D8@gmail.com>
	<BLU406-EAS291B7EAF79EF28CBB21FAEAAF0C0@phx.gbl>
Message-ID: <413188BA-25D7-4C4A-9B80-B1917D5EB556@gmail.com>


Le 24 oct. 2013 ? 19:27, davidacoder a ?crit :

>> If I remember correctly,
>> This means that will remove script in favor of a more general mechanism
> that
>> would allow to trigger any conversion as save time. Like **always** save
> an
>> static html, or a static .tex --script is awfully restrictive to only py
> files.
>> This mechanism will use nbconvert.
> 
> That sounds great. What I would find even better is if this was a
> per-notebook 
> setting (if that is something that exists), or maybe there could be a magic
> that
> switches this on for the current notebook, or something like that?

Not a magic, but probably, keep in mind, magic live in kernel, ipynb metadata are frontend stuff.
Even if technically it is possible, but it is ugly.
On the other hand, when you send the notebook to someone, you don't want him to 
get theses preferences.

> 
>> And also, notebook are importable thanks to an import hook which is
>> somewhere in IPython, but nobody test it, and nobody maintains it.
>> It is though cleaner than saving the .py file IMHO. Just saying'
> 
> Ha, this is EXACTLY what I need, thanks for pointing me there! For others
> that might be interested, this is in 
> examples/notebooks/Importing Notebooks.ipynb in the ipython repo.
> 
> Is this something that might move from an example to ipython proper
> at some point? I believe this could be incredibly useful for many people.
> Switching it on by default might be a bit intrusive, but maybe there
> could be a magic that enables this?


Probably, if someone take care of it, test it, write doc, 
make it work across notebook format changes... etc.

It would make more sense as a separate package for now that could have monthly releases
with bug fixes.
-- 
M

> Cheers,
> David
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



From hans_meine at gmx.net  Fri Oct 25 09:27:50 2013
From: hans_meine at gmx.net (Hans Meine)
Date: Fri, 25 Oct 2013 15:27:50 +0200
Subject: [IPython-dev] Multi-directory support landed in master
In-Reply-To: <CAHNn8BVpCC_0BpueoziL32C-d9=6z5OSkm268GnttLArTXkRfw@mail.gmail.com>
References: <CAHNn8BVpCC_0BpueoziL32C-d9=6z5OSkm268GnttLArTXkRfw@mail.gmail.com>
Message-ID: <4819063.Rs4xKuWiJh@hmeine-pc>

Am Dienstag, 22. Oktober 2013, 18:58:43 schrieb MinRK:
> Give it a test drive, and let us know what you find.

I have similar problems as Zolt?n, and after upgrading tornado
and this simple fix from PR 4425

-            var file_ext = name_and_ext[-1];
+            var file_ext = name_and_ext[1];

browsing notebooks works again, but I still _cannot open notebooks_:

In the browser, I get an empty message box titled "Error loading notebook", and the server outputs something like:

2013-10-25 15:20:44.842 [tornado.access] 304 GET /notebooks/plot_evaluation.ipynb (127.0.0.1) 2.03ms
2013-10-25 15:20:45.402 [tornado.access] 302 GET /notebooks/undefined?_=1382707244943 (127.0.0.1) 0.38ms

Creating new notebooks and deleting them works somehow, but they cannot be opened either.  Output:

2013-10-25 15:25:43.678 [NotebookApp] Creating new notebook in /
2013-10-25 15:25:43.680 [tornado.access] 201 POST /api/notebooks (127.0.0.1) 2.07ms
2013-10-25 15:25:43.691 [tornado.access] 200 GET /notebooks/Untitled0.ipynb (127.0.0.1) 1.96ms
2013-10-25 15:25:43.970 [tornado.access] 304 GET /static/components/highlight.js/build/highlight.pack.js (127.0.0.1) 0.69ms
2013-10-25 15:25:44.199 [tornado.access] 302 GET /notebooks/undefined?_=1382707543833 (127.0.0.1) 0.38ms
2013-10-25 15:25:44.204 [tornado.access] WARNING | 404 GET /files/undefined (127.0.0.1) 0.51ms
2013-10-25 15:25:46.474 [tornado.access] 200 GET /api/sessions?_=1382707242496 (127.0.0.1) 0.50ms
2013-10-25 15:25:46.482 [tornado.access] 200 GET /clusters?_=1382707242497 (127.0.0.1) 2.28ms
2013-10-25 15:25:46.487 [tornado.access] 200 GET /api/notebooks?_=1382707242498 (127.0.0.1) 1.38ms
2013-10-25 15:25:51.305 [tornado.access] 204 DELETE /api/notebooks/Untitled0.ipynb (127.0.0.1) 0.60ms
2013-10-25 15:25:52.350 [tornado.access] 200 GET /api/sessions?_=1382707242499 (127.0.0.1) 0.78ms
2013-10-25 15:25:52.362 [tornado.access] 200 GET /clusters?_=1382707242500 (127.0.0.1) 3.97ms
2013-10-25 15:25:52.365 [tornado.access] 200 GET /api/notebooks?_=1382707242501 (127.0.0.1) 0.86ms
2013-10-25 15:26:11.116 [tornado.access] 200 GET /api/sessions?_=1382707242502 (127.0.0.1) 0.66ms
2013-10-25 15:26:11.125 [tornado.access] 200 GET /clusters?_=1382707242503 (127.0.0.1) 2.36ms
2013-10-25 15:26:11.131 [tornado.access] 200 GET /api/notebooks?_=1382707242504 (127.0.0.1) 0.92ms
2013-10-25 15:26:12.122 [tornado.access] 200 GET /api/sessions?_=1382707242505 (127.0.0.1) 0.67ms
2013-10-25 15:26:12.130 [tornado.access] 200 GET /clusters?_=1382707242506 (127.0.0.1) 2.23ms
2013-10-25 15:26:12.136 [tornado.access] 200 GET /api/notebooks?_=1382707242507 (127.0.0.1) 0.90ms

Best regards
  Hans


From bussonniermatthias at gmail.com  Fri Oct 25 14:48:22 2013
From: bussonniermatthias at gmail.com (Matthias BUSSONNIER)
Date: Fri, 25 Oct 2013 20:48:22 +0200
Subject: [IPython-dev] Multi-directory support landed in master
In-Reply-To: <4819063.Rs4xKuWiJh@hmeine-pc>
References: <CAHNn8BVpCC_0BpueoziL32C-d9=6z5OSkm268GnttLArTXkRfw@mail.gmail.com>
	<4819063.Rs4xKuWiJh@hmeine-pc>
Message-ID: <D09990C8-E13D-4838-8A3D-DEEA7B5487BA@gmail.com>

Try master (from a few minutes ago)

And try force refreshing the pages (both dashboard and opened notebook where you get error message)

This is probably a cache problem with javascript. 
To be really sure you can even try private browsing and/or another browser.
-- 
M


Le 25 oct. 2013 ? 15:27, Hans Meine a ?crit :

> Am Dienstag, 22. Oktober 2013, 18:58:43 schrieb MinRK:
>> Give it a test drive, and let us know what you find.
> 
> I have similar problems as Zolt?n, and after upgrading tornado
> and this simple fix from PR 4425
> 
> -            var file_ext = name_and_ext[-1];
> +            var file_ext = name_and_ext[1];
> 
> browsing notebooks works again, but I still _cannot open notebooks_:
> 
> In the browser, I get an empty message box titled "Error loading notebook", and the server outputs something like:
> 
> 2013-10-25 15:20:44.842 [tornado.access] 304 GET /notebooks/plot_evaluation.ipynb (127.0.0.1) 2.03ms
> 2013-10-25 15:20:45.402 [tornado.access] 302 GET /notebooks/undefined?_=1382707244943 (127.0.0.1) 0.38ms
> 
> Creating new notebooks and deleting them works somehow, but they cannot be opened either.  Output:
> 
> 2013-10-25 15:25:43.678 [NotebookApp] Creating new notebook in /
> 2013-10-25 15:25:43.680 [tornado.access] 201 POST /api/notebooks (127.0.0.1) 2.07ms
> 2013-10-25 15:25:43.691 [tornado.access] 200 GET /notebooks/Untitled0.ipynb (127.0.0.1) 1.96ms
> 2013-10-25 15:25:43.970 [tornado.access] 304 GET /static/components/highlight.js/build/highlight.pack.js (127.0.0.1) 0.69ms
> 2013-10-25 15:25:44.199 [tornado.access] 302 GET /notebooks/undefined?_=1382707543833 (127.0.0.1) 0.38ms
> 2013-10-25 15:25:44.204 [tornado.access] WARNING | 404 GET /files/undefined (127.0.0.1) 0.51ms
> 2013-10-25 15:25:46.474 [tornado.access] 200 GET /api/sessions?_=1382707242496 (127.0.0.1) 0.50ms
> 2013-10-25 15:25:46.482 [tornado.access] 200 GET /clusters?_=1382707242497 (127.0.0.1) 2.28ms
> 2013-10-25 15:25:46.487 [tornado.access] 200 GET /api/notebooks?_=1382707242498 (127.0.0.1) 1.38ms
> 2013-10-25 15:25:51.305 [tornado.access] 204 DELETE /api/notebooks/Untitled0.ipynb (127.0.0.1) 0.60ms
> 2013-10-25 15:25:52.350 [tornado.access] 200 GET /api/sessions?_=1382707242499 (127.0.0.1) 0.78ms
> 2013-10-25 15:25:52.362 [tornado.access] 200 GET /clusters?_=1382707242500 (127.0.0.1) 3.97ms
> 2013-10-25 15:25:52.365 [tornado.access] 200 GET /api/notebooks?_=1382707242501 (127.0.0.1) 0.86ms
> 2013-10-25 15:26:11.116 [tornado.access] 200 GET /api/sessions?_=1382707242502 (127.0.0.1) 0.66ms
> 2013-10-25 15:26:11.125 [tornado.access] 200 GET /clusters?_=1382707242503 (127.0.0.1) 2.36ms
> 2013-10-25 15:26:11.131 [tornado.access] 200 GET /api/notebooks?_=1382707242504 (127.0.0.1) 0.92ms
> 2013-10-25 15:26:12.122 [tornado.access] 200 GET /api/sessions?_=1382707242505 (127.0.0.1) 0.67ms
> 2013-10-25 15:26:12.130 [tornado.access] 200 GET /clusters?_=1382707242506 (127.0.0.1) 2.23ms
> 2013-10-25 15:26:12.136 [tornado.access] 200 GET /api/notebooks?_=1382707242507 (127.0.0.1) 0.90ms
> 
> Best regards
>  Hans
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



From thomas.robitaille at gmail.com  Sat Oct 26 14:40:53 2013
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Sat, 26 Oct 2013 20:40:53 +0200
Subject: [IPython-dev] slideshow 'themes'
Message-ID: <CAGMHX_2qSZ=J063q60R8grr36Fyp3GQBVvnK-50Xn5oX_kHDQw@mail.gmail.com>

Hi everyone,

I am currently using the IPython notebook to prepare slideshows, and I
was wondering if there exists a repository of 'themes' for the
slideshow mode. I want to customize the slideshows beyond the simple
changes that can be made to reveal.js, and I thought it might make
sense to set up a repository to collect polished themes? (i.e.
custom.css files). Maybe this already exists?

Thanks,
Tom


From damianavila at gmail.com  Mon Oct 28 20:17:11 2013
From: damianavila at gmail.com (=?ISO-8859-1?Q?Dami=E1n_Avila?=)
Date: Mon, 28 Oct 2013 22:17:11 -0200
Subject: [IPython-dev] slideshow 'themes'
In-Reply-To: <CAGMHX_2qSZ=J063q60R8grr36Fyp3GQBVvnK-50Xn5oX_kHDQw@mail.gmail.com>
References: <CAGMHX_2qSZ=J063q60R8grr36Fyp3GQBVvnK-50Xn5oX_kHDQw@mail.gmail.com>
Message-ID: <CAH+mRR3WPM8Lq9zUjXwp6dhMxGocb5R8=ndCFXELUGF=7LvPjw@mail.gmail.com>

It is an interesting idea... AFAIK there is no repository for IPython
slides (reveal) themes... maybe we can create one to push new themes.
I do not know if the repo has to live inside the IPython project (we can
ask to the core devs about that), but if not, we can easily setup one to
collect them.

Cheers.


2013/10/26 Thomas Robitaille <thomas.robitaille at gmail.com>

> Hi everyone,
>
> I am currently using the IPython notebook to prepare slideshows, and I
> was wondering if there exists a repository of 'themes' for the
> slideshow mode. I want to customize the slideshows beyond the simple
> changes that can be made to reveal.js, and I thought it might make
> sense to set up a repository to collect polished themes? (i.e.
> custom.css files). Maybe this already exists?
>
> Thanks,
> Tom
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Dami?n Avila
Scientific Python Developer
Quantitative Finance Analyst
Statistics, Biostatistics and Econometrics Consultant
Biochemist
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131028/5d2221cc/attachment.html>

From nathan12343 at gmail.com  Tue Oct 29 06:16:32 2013
From: nathan12343 at gmail.com (Nathan Goldbaum)
Date: Tue, 29 Oct 2013 03:16:32 -0700
Subject: [IPython-dev] Using sphinx to evaluate notebook cells?
In-Reply-To: <0013520D-74AC-420D-B5CC-7AEE18EC931C@gmail.com>
References: <CAJXewOnbwmyw5VzPtW2pSGjDFOdO1YHyrEffLGw_9q241xPQQg@mail.gmail.com>
	<0013520D-74AC-420D-B5CC-7AEE18EC931C@gmail.com>
Message-ID: <etPan.526f8b00.66334873.10c@ROUS>

Quick update on this. ?I managed to create the notebook extension I was asking about in my initial message to the list. I did end up using runipy, as Matthias suggested.

Much of hard work for the extension was originally done by Anthony Scopatz, who wrote a similar notebook sphinx plugin for pyne (http://pynesim.org/) based on evaluated notebooks.

Using Anthony's extension, I generalized it to evaluate and embed the notebook in our docs. As a proof-of-concept, I transferred the yt bootcamp, which we had displayed in the past using static nbviewer links, to use the new notebook directive.

The result is here: http://ngoldbaum.net/docs_build/bootcamp/index.html

If you're interested in the details of how this works, the code for the plugin is here. One issue is that I had to monkeypatch the CSS I got back from nbconvert to avoid mangling our docs theme.

I've also created a similar notebook-cell extension that transforms inline .rst code snippets into evaluated notebook cells in the docs build.

For now these extensions are part of the yt documentation, but if there's interest I'll happily package up the extensions and do a standalone release for them.

-Nathan

On October 23, 2013 at 1:13:08 AM, Matthias Bussonnier (bussonniermatthias at gmail.com) wrote:

Hi

I'm not aware of such a plugin. Definitively interested as we want our doc as notebook in IPython too.

Have a look at runipy (Google is your friend, and is on pypi iirc). It runs notebook headless and generate static HTML from that. Having a nbconvert preprocessor that run notebook would also be great!

(Sorry no direct link, from my phone)

M

Envoy? de mon iPhone

Le 23 oct. 2013 ? 02:41, Nathan Goldbaum nathan12343 at gmail.com a ?crit :

Hi all,

Myself and some of the other yt devs are thinking about ways to improve cookbook section of our documentation by replacing the scripts we currently host with notebooks.

Since some of our cookbook recipes store plots, we'd like to track these notebooks in version control in an unevaluated state, mainly to avoid versioning images. We have a CI server that already builds our cookbook recipes for our dev docs, so something that integrates with sphinx seems to be the way to go. I think I could write a sphinx plugin that does the job, but it would need to use whatever machinery IPython uses when notebook cells get evaluated.

Does anyone know if such a plugin is available somewhere? If not, does anyone know where I should look in the IPython codebase for when I try to write it myself?

Thanks for your help,

-Nathan

IPython-dev mailing list IPython-dev at scipy.org http://mail.scipy.org/mailman/listinfo/ipython-dev

IPython-dev mailing list IPython-dev at scipy.org http://mail.scipy.org/mailman/listinfo/ipython-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131029/0fd884af/attachment.html>

From bussonniermatthias at gmail.com  Tue Oct 29 07:05:31 2013
From: bussonniermatthias at gmail.com (Matthias Bussonnier)
Date: Tue, 29 Oct 2013 12:05:31 +0100
Subject: [IPython-dev] Using sphinx to evaluate notebook cells?
In-Reply-To: <etPan.526f8b00.66334873.10c@ROUS>
References: <CAJXewOnbwmyw5VzPtW2pSGjDFOdO1YHyrEffLGw_9q241xPQQg@mail.gmail.com>
	<0013520D-74AC-420D-B5CC-7AEE18EC931C@gmail.com>
	<etPan.526f8b00.66334873.10c@ROUS>
Message-ID: <BBD7765C-B598-4BFB-9A11-125F211DBE3C@gmail.com>

Will comment more later:

Yes interested, a lot. Don't use HTML full, use 'basic' it will give you only the inner body. 

We have 2 CSS one of which should not conflict. Feedback welcomed.

Envoy? de mon iPhone

> Le 29 oct. 2013 ? 11:16, Nathan Goldbaum <nathan12343 at gmail.com> a ?crit :
> 
> Quick update on this.  I managed to create the notebook extension I was asking about in my initial message to the list. I did end up using runipy, as Matthias suggested.
> 
> Much of hard work for the extension was originally done by Anthony Scopatz, who wrote a similar notebook sphinx plugin for pyne (http://pynesim.org/) based on evaluated notebooks.
> 
> Using Anthony's extension, I generalized it to evaluate and embed the notebook in our docs. As a proof-of-concept, I transferred the yt bootcamp, which we had displayed in the past using static nbviewer links, to use the new notebook directive.
> 
> The result is here: http://ngoldbaum.net/docs_build/bootcamp/index.html
> 
> If you're interested in the details of how this works, the code for the plugin is here. One issue is that I had to monkeypatch the CSS I got back from nbconvert to avoid mangling our docs theme.
> 
> I've also created a similar notebook-cell extension that transforms inline .rst code snippets into evaluated notebook cells in the docs build.
> 
> For now these extensions are part of the yt documentation, but if there's interest I'll happily package up the extensions and do a standalone release for them.
> 
> -Nathan
> 
> On October 23, 2013 at 1:13:08 AM, Matthias Bussonnier (bussonniermatthias at gmail.com) wrote:
> 
> Hi
> 
> I'm not aware of such a plugin. Definitively interested as we want our doc as notebook in IPython too.
> 
> Have a look at runipy (Google is your friend, and is on pypi iirc). It runs notebook headless and generate static HTML from that. Having a nbconvert preprocessor that run notebook would also be great!
> 
> (Sorry no direct link, from my phone)
> 
> M
> 
> Envoy? de mon iPhone
> 
> Le 23 oct. 2013 ? 02:41, Nathan Goldbaum nathan12343 at gmail.com a ?crit :
> 
> Hi all,
> 
> Myself and some of the other yt devs are thinking about ways to improve cookbook section of our documentation by replacing the scripts we currently host with notebooks.
> 
> Since some of our cookbook recipes store plots, we'd like to track these notebooks in version control in an unevaluated state, mainly to avoid versioning images. We have a CI server that already builds our cookbook recipes for our dev docs, so something that integrates with sphinx seems to be the way to go. I think I could write a sphinx plugin that does the job, but it would need to use whatever machinery IPython uses when notebook cells get evaluated.
> 
> Does anyone know if such a plugin is available somewhere? If not, does anyone know where I should look in the IPython codebase for when I try to write it myself?
> 
> Thanks for your help,
> 
> -Nathan
> 
> IPython-dev mailing list IPython-dev at scipy.org http://mail.scipy.org/mailman/listinfo/ipython-dev
> 
> IPython-dev mailing list IPython-dev at scipy.org http://mail.scipy.org/mailman/listinfo/ipython-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131029/f6961141/attachment.html>

From wagnerfl at student.ethz.ch  Tue Oct 29 12:19:01 2013
From: wagnerfl at student.ethz.ch (Florian M. Wagner)
Date: Tue, 29 Oct 2013 17:19:01 +0100
Subject: [IPython-dev] Numpy with OpenBLAS vs. IPython
Message-ID: <526FDFF5.30304@student.ethz.ch>

Dear all,

I recently compiled numpy with OpenBlas for faster matrix-matrix 
multiplication. Everything works fine, but IPython seems to dislike it. 
I get a Segmentation Fault error when trying this (I reinstalled IPython 
1.1.0 after numpy compilation):

    fwagner at fwagner-notebook ~ $ ipython -c "import numpy as np; print
    np.__version__; import IPython; print IPython.__version__; A =
    np.random.randn(600, 600); print A[20,53]; print A"
    /usr/local/bin/ipython:5: UserWarning: Module dap was already
    imported from None, but /usr/lib/python2.7/dist-packages is being
    added to sys.path
       from pkg_resources import load_entry_point
    1.9.0.dev-54d3559
    1.1.0
    -2.1004055886
    Speicherzugriffsfehler

In comparison, this works fine (just python instead of ipython):

    fwagner at fwagner-notebook ~ $ python -c "import numpy as np; print
    np.__version__; import IPython; print IPython.__version__; A =
    np.random.randn(600, 600); print A[20,53]; print A"
    1.9.0.dev-54d3559
    1.1.0
    -1.10282239744
    [[ 0.13798084 -0.39195796 -0.15309986 ...,  1.47471232 -0.9158455
        0.97060671]
      [ 0.25720169  0.51895478  0.55175787 ..., -0.02010573  0.78047754
       -1.07891961]
      [ 1.59478156  0.81245486 -0.03959768 ..., -0.04816659 -0.03356907
       -0.11860379]
      ...,
      [-0.06299817 -0.0956477  -0.32987518 ..., -1.47714386  1.66736916
       -0.47704276]
      [-0.93769589  1.50006542  0.97782803 ..., -0.5034154   1.31592011
       -0.74482995]
      [-0.24661336 -0.98979706 -0.39366363 ...,  0.20507632  0.8701609
       -1.10449957]]

Any ideas what might cause this problem?

Thanks,

Florian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131029/4b15b6d4/attachment.html>

From takowl at gmail.com  Tue Oct 29 12:33:56 2013
From: takowl at gmail.com (Thomas Kluyver)
Date: Tue, 29 Oct 2013 09:33:56 -0700
Subject: [IPython-dev] Numpy with OpenBLAS vs. IPython
In-Reply-To: <526FDFF5.30304@student.ethz.ch>
References: <526FDFF5.30304@student.ethz.ch>
Message-ID: <CAOvn4qgkBjrNzberM0HhRQOmJaWFnTX=p-wtOuZmRftrCN_RSg@mail.gmail.com>

I wonder if this warning has anything to do with it:

On 29 October 2013 09:19, Florian M. Wagner <wagnerfl at student.ethz.ch>wrote:

> /usr/local/bin/ipython:5: UserWarning: Module dap was already imported
> from None, but /usr/lib/python2.7/dist-packages is being added to sys.path
>
>
I don't know what the dap module is, but if the imports are coming from
different places, that could cause a difference.

Interestingly, it only appears to fail when you print the array, not when
you construct it or access it.

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131029/ad8a1945/attachment.html>

From nathan12343 at gmail.com  Tue Oct 29 13:17:41 2013
From: nathan12343 at gmail.com (Nathan Goldbaum)
Date: Tue, 29 Oct 2013 10:17:41 -0700
Subject: [IPython-dev] Using sphinx to evaluate notebook cells?
In-Reply-To: <BBD7765C-B598-4BFB-9A11-125F211DBE3C@gmail.com>
References: <CAJXewOnbwmyw5VzPtW2pSGjDFOdO1YHyrEffLGw_9q241xPQQg@mail.gmail.com>
	<0013520D-74AC-420D-B5CC-7AEE18EC931C@gmail.com>
	<etPan.526f8b00.66334873.10c@ROUS>
	<BBD7765C-B598-4BFB-9A11-125F211DBE3C@gmail.com>
Message-ID: <etPan.526fedb5.19495cff.10c@ROUS>

Hi Matthias,

Thanks for the suggestion. ?I did try the ?basic? HTML template but found that it gave, well, basic results. ?I guess I want *part* of the notebook CSS but not all of it so the notebook cells appear like notebook cells in the document. Likely there?s a better way to do that.

-Nathan

On October 29, 2013 at 4:05:35 AM, Matthias Bussonnier (bussonniermatthias at gmail.com) wrote:

Will comment more later:

Yes interested, a lot. Don't use HTML full, use 'basic' it will give you only the inner body.?

We have 2 CSS one of which should not conflict. Feedback welcomed.

Envoy? de mon iPhone

Le 29 oct. 2013 ? 11:16, Nathan Goldbaum <nathan12343 at gmail.com> a ?crit?:

Quick update on this. ?I managed to create the notebook extension I was asking about in my initial message to the list. I did end up using runipy, as Matthias suggested.

Much of hard work for the extension was originally done by Anthony Scopatz, who wrote a similar notebook sphinx plugin for pyne (http://pynesim.org/) based on evaluated notebooks.

Using Anthony's extension, I generalized it to evaluate and embed the notebook in our docs. As a proof-of-concept, I transferred the yt bootcamp, which we had displayed in the past using static nbviewer links, to use the new notebook directive.

The result is here: http://ngoldbaum.net/docs_build/bootcamp/index.html

If you're interested in the details of how this works, the code for the plugin is here. One issue is that I had to monkeypatch the CSS I got back from nbconvert to avoid mangling our docs theme.

I've also created a similar notebook-cell extension that transforms inline .rst code snippets into evaluated notebook cells in the docs build.

For now these extensions are part of the yt documentation, but if there's interest I'll happily package up the extensions and do a standalone release for them.

-Nathan

On October 23, 2013 at 1:13:08 AM, Matthias Bussonnier (bussonniermatthias at gmail.com) wrote:

Hi

I'm not aware of such a plugin. Definitively interested as we want our doc as notebook in IPython too.

Have a look at runipy (Google is your friend, and is on pypi iirc). It runs notebook headless and generate static HTML from that. Having a nbconvert preprocessor that run notebook would also be great!

(Sorry no direct link, from my phone)

M

Envoy? de mon iPhone

Le 23 oct. 2013 ? 02:41, Nathan Goldbaum nathan12343 at gmail.com a ?crit :

Hi all,

Myself and some of the other yt devs are thinking about ways to improve cookbook section of our documentation by replacing the scripts we currently host with notebooks.

Since some of our cookbook recipes store plots, we'd like to track these notebooks in version control in an unevaluated state, mainly to avoid versioning images. We have a CI server that already builds our cookbook recipes for our dev docs, so something that integrates with sphinx seems to be the way to go. I think I could write a sphinx plugin that does the job, but it would need to use whatever machinery IPython uses when notebook cells get evaluated.

Does anyone know if such a plugin is available somewhere? If not, does anyone know where I should look in the IPython codebase for when I try to write it myself?

Thanks for your help,

-Nathan

IPython-dev mailing list IPython-dev at scipy.org http://mail.scipy.org/mailman/listinfo/ipython-dev

IPython-dev mailing list IPython-dev at scipy.org http://mail.scipy.org/mailman/listinfo/ipython-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131029/27a922bd/attachment.html>

From bussonniermatthias at gmail.com  Tue Oct 29 13:47:40 2013
From: bussonniermatthias at gmail.com (Matthias Bussonnier)
Date: Tue, 29 Oct 2013 18:47:40 +0100
Subject: [IPython-dev] Using sphinx to evaluate notebook cells?
In-Reply-To: <etPan.526fedb5.19495cff.10c@ROUS>
References: <CAJXewOnbwmyw5VzPtW2pSGjDFOdO1YHyrEffLGw_9q241xPQQg@mail.gmail.com>
	<0013520D-74AC-420D-B5CC-7AEE18EC931C@gmail.com>
	<etPan.526f8b00.66334873.10c@ROUS>
	<BBD7765C-B598-4BFB-9A11-125F211DBE3C@gmail.com>
	<etPan.526fedb5.19495cff.10c@ROUS>
Message-ID: <F2BF5E7C-884A-47EA-A032-B944C8336286@gmail.com>

Gave to see, but once you use basic, you should be able to "just" include mathjax and Ipython.css in all the pages. 

You can even pass custom templates to the html exporter.

Will have a look and open PRs when more time.

Envoy? de mon iPhone

> Le 29 oct. 2013 ? 18:17, Nathan Goldbaum <nathan12343 at gmail.com> a ?crit :
> 
> Hi Matthias,
> 
> Thanks for the suggestion.  I did try the ?basic? HTML template but found that it gave, well, basic results.  I guess I want *part* of the notebook CSS but not all of it so the notebook cells appear like notebook cells in the document. Likely there?s a better way to do that.
> 
> -Nathan
> 
>> On October 29, 2013 at 4:05:35 AM, Matthias Bussonnier (bussonniermatthias at gmail.com) wrote:
>> 
>> Will comment more later:
>> 
>> Yes interested, a lot. Don't use HTML full, use 'basic' it will give you only the inner body. 
>> 
>> We have 2 CSS one of which should not conflict. Feedback welcomed.
>> 
>> Envoy? de mon iPhone
>> 
>> Le 29 oct. 2013 ? 11:16, Nathan Goldbaum <nathan12343 at gmail.com> a ?crit :
>> 
>>> Quick update on this.  I managed to create the notebook extension I was asking about in my initial message to the list. I did end up using runipy, as Matthias suggested.
>>> 
>>> Much of hard work for the extension was originally done by Anthony Scopatz, who wrote a similar notebook sphinx plugin for pyne (http://pynesim.org/) based on evaluated notebooks.
>>> 
>>> Using Anthony's extension, I generalized it to evaluate and embed the notebook in our docs. As a proof-of-concept, I transferred the yt bootcamp, which we had displayed in the past using static nbviewer links, to use the new notebook directive.
>>> 
>>> The result is here: http://ngoldbaum.net/docs_build/bootcamp/index.html
>>> 
>>> If you're interested in the details of how this works, the code for the plugin is here. One issue is that I had to monkeypatch the CSS I got back from nbconvert to avoid mangling our docs theme.
>>> 
>>> I've also created a similar notebook-cell extension that transforms inline .rst code snippets into evaluated notebook cells in the docs build.
>>> 
>>> For now these extensions are part of the yt documentation, but if there's interest I'll happily package up the extensions and do a standalone release for them.
>>> 
>>> -Nathan
>>> 
>>> On October 23, 2013 at 1:13:08 AM, Matthias Bussonnier (bussonniermatthias at gmail.com) wrote:
>>> 
>>> Hi
>>> 
>>> I'm not aware of such a plugin. Definitively interested as we want our doc as notebook in IPython too.
>>> 
>>> Have a look at runipy (Google is your friend, and is on pypi iirc). It runs notebook headless and generate static HTML from that. Having a nbconvert preprocessor that run notebook would also be great!
>>> 
>>> (Sorry no direct link, from my phone)
>>> 
>>> M
>>> 
>>> Envoy? de mon iPhone
>>> 
>>> Le 23 oct. 2013 ? 02:41, Nathan Goldbaum nathan12343 at gmail.com a ?crit :
>>> 
>>> Hi all,
>>> 
>>> Myself and some of the other yt devs are thinking about ways to improve cookbook section of our documentation by replacing the scripts we currently host with notebooks.
>>> 
>>> Since some of our cookbook recipes store plots, we'd like to track these notebooks in version control in an unevaluated state, mainly to avoid versioning images. We have a CI server that already builds our cookbook recipes for our dev docs, so something that integrates with sphinx seems to be the way to go. I think I could write a sphinx plugin that does the job, but it would need to use whatever machinery IPython uses when notebook cells get evaluated.
>>> 
>>> Does anyone know if such a plugin is available somewhere? If not, does anyone know where I should look in the IPython codebase for when I try to write it myself?
>>> 
>>> Thanks for your help,
>>> 
>>> -Nathan
>>> 
>>> IPython-dev mailing list IPython-dev at scipy.org http://mail.scipy.org/mailman/listinfo/ipython-dev
>>> 
>>> IPython-dev mailing list IPython-dev at scipy.org http://mail.scipy.org/mailman/listinfo/ipython-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131029/178c5e20/attachment.html>

From jtaylor.debian at googlemail.com  Tue Oct 29 14:39:44 2013
From: jtaylor.debian at googlemail.com (Julian Taylor)
Date: Tue, 29 Oct 2013 19:39:44 +0100
Subject: [IPython-dev] Numpy with OpenBLAS vs. IPython
In-Reply-To: <526FDFF5.30304@student.ethz.ch>
References: <526FDFF5.30304@student.ethz.ch>
Message-ID: <527000F0.20704@googlemail.com>

does this also happen if you do this before starting ipython?

export OPENBLAS_NUM_THREADS=1
(assuming bash shell)

On 29.10.2013 17:19, Florian M. Wagner wrote:
> Dear all,
> 
> I recently compiled numpy with OpenBlas for faster matrix-matrix
> multiplication. Everything works fine, but IPython seems to dislike it.
> I get a Segmentation Fault error when trying this (I reinstalled IPython
> 1.1.0 after numpy compilation):
> 
>     fwagner at fwagner-notebook ~ $ ipython -c "import numpy as np; print
>     np.__version__; import IPython; print IPython.__version__; A =
>     np.random.randn(600, 600); print A[20,53]; print A"
>     /usr/local/bin/ipython:5: UserWarning: Module dap was already
>     imported from None, but /usr/lib/python2.7/dist-packages is being
>     added to sys.path
>       from pkg_resources import load_entry_point
>     1.9.0.dev-54d3559
>     1.1.0
>     -2.1004055886
>     Speicherzugriffsfehler
> 
> In comparison, this works fine (just python instead of ipython):
> 
>     fwagner at fwagner-notebook ~ $ python -c "import numpy as np; print
>     np.__version__; import IPython; print IPython.__version__; A =
>     np.random.randn(600, 600); print A[20,53]; print A"
>     1.9.0.dev-54d3559
>     1.1.0
>     -1.10282239744
>     [[ 0.13798084 -0.39195796 -0.15309986 ...,  1.47471232 -0.9158455
>        0.97060671]
>      [ 0.25720169  0.51895478  0.55175787 ..., -0.02010573  0.78047754
>       -1.07891961]
>      [ 1.59478156  0.81245486 -0.03959768 ..., -0.04816659 -0.03356907
>       -0.11860379]
>      ...,
>      [-0.06299817 -0.0956477  -0.32987518 ..., -1.47714386  1.66736916
>       -0.47704276]
>      [-0.93769589  1.50006542  0.97782803 ..., -0.5034154   1.31592011
>       -0.74482995]
>      [-0.24661336 -0.98979706 -0.39366363 ...,  0.20507632  0.8701609
>       -1.10449957]]
> 
> Any ideas what might cause this problem?
> 
> Thanks,
> 
> Florian
> 
> 
> 
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
> 



From takowl at gmail.com  Tue Oct 29 14:53:15 2013
From: takowl at gmail.com (Thomas Kluyver)
Date: Tue, 29 Oct 2013 11:53:15 -0700
Subject: [IPython-dev] Python 3 single codebase - merged
Message-ID: <CAOvn4qidXrsSdNazukSoeZk6YEe+xhtij7EbLE3YNCfL5QtL5w@mail.gmail.com>

We've just merged the switch to single codebase Python 3 support into
master. This means that installing IPython on Python 3 should be much
quicker.

This is a major set of changes, so if you're about to give a critical
presentation or something using IPython, you might want to hold off pulling
from master until it's over. We've tested and reviewed the code, naturally,
but errors can always sneak in.

We've discovered one issue: if you use setup.py develop with both Python 2
and Python 3 from the same source directory, the entry points will
overwrite each other, so only the most recently set-up one will work. We're
thinking about how to fix this, but for now, use setup.py install for at
least one Python version.

Thanks,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131029/7dcecaf2/attachment.html>

From scopatz at gmail.com  Tue Oct 29 15:19:35 2013
From: scopatz at gmail.com (Anthony Scopatz)
Date: Tue, 29 Oct 2013 14:19:35 -0500
Subject: [IPython-dev] Using sphinx to evaluate notebook cells?
In-Reply-To: <F2BF5E7C-884A-47EA-A032-B944C8336286@gmail.com>
References: <CAJXewOnbwmyw5VzPtW2pSGjDFOdO1YHyrEffLGw_9q241xPQQg@mail.gmail.com>
	<0013520D-74AC-420D-B5CC-7AEE18EC931C@gmail.com>
	<etPan.526f8b00.66334873.10c@ROUS>
	<BBD7765C-B598-4BFB-9A11-125F211DBE3C@gmail.com>
	<etPan.526fedb5.19495cff.10c@ROUS>
	<F2BF5E7C-884A-47EA-A032-B944C8336286@gmail.com>
Message-ID: <CAPk-6T4bB-F69zeZFMp1Yyy6mdPKxQabnGY3ggruVERWbMADLg@mail.gmail.com>

Thanks for the improvement suggestions Matthias.  Including the ipython.css
is a good idea and would hopefully allow us to remove that replace hacks
that are in their now.  More suggestions are definitely appreciated.

Thanks for bring this up again Nathan.

Be Well
Anthony


On Tue, Oct 29, 2013 at 12:47 PM, Matthias Bussonnier <
bussonniermatthias at gmail.com> wrote:

> Gave to see, but once you use basic, you should be able to "just" include
> mathjax and Ipython.css in all the pages.
>
> You can even pass custom templates to the html exporter.
>
> Will have a look and open PRs when more time.
>
> Envoy? de mon iPhone
>
> Le 29 oct. 2013 ? 18:17, Nathan Goldbaum <nathan12343 at gmail.com> a ?crit :
>
> Hi Matthias,
>
> Thanks for the suggestion.  I did try the ?basic? HTML template but found
> that it gave, well, basic results.  I guess I want *part* of the notebook
> CSS but not all of it so the notebook cells appear like notebook cells in
> the document. Likely there?s a better way to do that.
>
> -Nathan
>
> On October 29, 2013 at 4:05:35 AM, Matthias Bussonnier (
> bussonniermatthias at gmail.com <//bussonniermatthias at gmail.com>) wrote:
>
>  Will comment more later:
>
> Yes interested, a lot. Don't use HTML full, use 'basic' it will give you
> only the inner body.
>
> We have 2 CSS one of which should not conflict. Feedback welcomed.
>
> Envoy? de mon iPhone
>
> Le 29 oct. 2013 ? 11:16, Nathan Goldbaum <nathan12343 at gmail.com> a ?crit :
>
>  Quick update on this.  I managed to create the notebook extension I was
> asking about in my initial message to the list. I did end up using runipy,
> as Matthias suggested.
>
> Much of hard work for the extension was originally done by Anthony
> Scopatz, who wrote a similar notebook sphinx plugin for pyne (
> http://pynesim.org/) based on evaluated notebooks.
>
> Using Anthony's extension, I generalized it to evaluate and embed the
> notebook in our docs. As a proof-of-concept, I transferred the yt bootcamp,
> which we had displayed in the past using static nbviewer links, to use the
> new notebook directive.
>
> The result is here: http://ngoldbaum.net/docs_build/bootcamp/index.html
>
> If you're interested in the details of how this works, the code for the
> plugin is here<https://bitbucket.org/ngoldbaum/yt-doc/src/tip/extensions/notebook_sphinxext.py>.
> One issue is that I had to monkeypatch the CSS I got back from nbconvert to
> avoid mangling our docs theme.
>
> I've also created a similar notebook-cell extension that transforms
> inline .rst code snippets into evaluated notebook cells in the docs build.
>
> For now these extensions are part of the yt documentation, but if there's
> interest I'll happily package up the extensions and do a standalone release
> for them.
>
> -Nathan
>
> On October 23, 2013 at 1:13:08 AM, Matthias Bussonnier (
> bussonniermatthias at gmail.com) wrote:
>
> Hi
>
> I'm not aware of such a plugin. Definitively interested as we want our doc
> as notebook in IPython too.
>
> Have a look at runipy (Google is your friend, and is on pypi iirc). It
> runs notebook headless and generate static HTML from that. Having a
> nbconvert preprocessor that run notebook would also be great!
> (Sorry no direct link, from my phone)
>
> M
>
> Envoy? de mon iPhone
>
> Le 23 oct. 2013 ? 02:41, Nathan Goldbaum nathan12343 at gmail.com a ?crit :
>
> Hi all,
>
> Myself and some of the other yt devs are thinking about ways to improve
> cookbook section of our documentation by replacing the scripts we currently
> host with notebooks.
>
> Since some of our cookbook recipes store plots, we'd like to track these
> notebooks in version control in an unevaluated state, mainly to avoid
> versioning images. We have a CI server that already builds our cookbook
> recipes for our dev docs, so something that integrates with sphinx seems to
> be the way to go. I think I could write a sphinx plugin that does the job,
> but it would need to use whatever machinery IPython uses when notebook
> cells get evaluated.
>
> Does anyone know if such a plugin is available somewhere? If not, does
> anyone know where I should look in the IPython codebase for when I try to
> write it myself?
>
> Thanks for your help,
>
> -Nathan
> ------------------------------
>
> IPython-dev mailing list IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
> ------------------------------
>
> IPython-dev mailing list IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131029/2d78e73e/attachment.html>

From asmeurer at gmail.com  Tue Oct 29 17:26:45 2013
From: asmeurer at gmail.com (Aaron Meurer)
Date: Tue, 29 Oct 2013 15:26:45 -0600
Subject: [IPython-dev] Python 3 single codebase - merged
In-Reply-To: <CAOvn4qidXrsSdNazukSoeZk6YEe+xhtij7EbLE3YNCfL5QtL5w@mail.gmail.com>
References: <CAOvn4qidXrsSdNazukSoeZk6YEe+xhtij7EbLE3YNCfL5QtL5w@mail.gmail.com>
Message-ID: <CAKgW=6LSuzALB=Fp6WKUVkHO1Nz+N_EbqYWVSgvH3HaR_kKQmg@mail.gmail.com>

On Tue, Oct 29, 2013 at 12:53 PM, Thomas Kluyver <takowl at gmail.com> wrote:
> We've just merged the switch to single codebase Python 3 support into
> master. This means that installing IPython on Python 3 should be much
> quicker.

Great to hear this! So does this also mean that you're getting rid of
the ipython3 nonsense?

>
> This is a major set of changes, so if you're about to give a critical
> presentation or something using IPython, you might want to hold off pulling
> from master until it's over. We've tested and reviewed the code, naturally,
> but errors can always sneak in.
>
> We've discovered one issue: if you use setup.py develop with both Python 2
> and Python 3 from the same source directory, the entry points will overwrite
> each other, so only the most recently set-up one will work. We're thinking
> about how to fix this, but for now, use setup.py install for at least one
> Python version.

This seems to be a general problem with setup.py develop. It only
supports developing into one Python environment at a time, which is
annoying if you have a ton of environments (e.g., with conda). I'm
very interested in how you end up fixing this.

Aaron Meurer

>
> Thanks,
> Thomas
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>


From p.f.moore at gmail.com  Tue Oct 29 17:43:06 2013
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 29 Oct 2013 21:43:06 +0000
Subject: [IPython-dev] Python 3 single codebase - merged
In-Reply-To: <CAKgW=6LSuzALB=Fp6WKUVkHO1Nz+N_EbqYWVSgvH3HaR_kKQmg@mail.gmail.com>
References: <CAOvn4qidXrsSdNazukSoeZk6YEe+xhtij7EbLE3YNCfL5QtL5w@mail.gmail.com>
	<CAKgW=6LSuzALB=Fp6WKUVkHO1Nz+N_EbqYWVSgvH3HaR_kKQmg@mail.gmail.com>
Message-ID: <CACac1F9kvnrnSb4_ZO76p7zKW81WDEb9hsryTekHBrJGAPVZ2w@mail.gmail.com>

On 29 October 2013 21:26, Aaron Meurer <asmeurer at gmail.com> wrote:
> On Tue, Oct 29, 2013 at 12:53 PM, Thomas Kluyver <takowl at gmail.com> wrote:
>> We've just merged the switch to single codebase Python 3 support into
>> master. This means that installing IPython on Python 3 should be much
>> quicker.
>
> Great to hear this! So does this also mean that you're getting rid of
> the ipython3 nonsense?

+1

Paul


From takowl at gmail.com  Tue Oct 29 17:43:19 2013
From: takowl at gmail.com (Thomas Kluyver)
Date: Tue, 29 Oct 2013 14:43:19 -0700
Subject: [IPython-dev] Python 3 single codebase - merged
In-Reply-To: <CAKgW=6LSuzALB=Fp6WKUVkHO1Nz+N_EbqYWVSgvH3HaR_kKQmg@mail.gmail.com>
References: <CAOvn4qidXrsSdNazukSoeZk6YEe+xhtij7EbLE3YNCfL5QtL5w@mail.gmail.com>
	<CAKgW=6LSuzALB=Fp6WKUVkHO1Nz+N_EbqYWVSgvH3HaR_kKQmg@mail.gmail.com>
Message-ID: <CAOvn4qg1NM8oEW8ESZr8K4asbBxoTgxNgXq4J4wSBmiz82at7Q@mail.gmail.com>

On 29 October 2013 14:26, Aaron Meurer <asmeurer at gmail.com> wrote:

> Great to hear this! So does this also mean that you're getting rid of
> the ipython3 nonsense?
>

Not just yet, but I've put the naming question on our agenda for Thursday's
dev meeting:
https://hackpad.com/IPython-dev-meetings-6wTSjJt7TZK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131029/1a6bddc9/attachment.html>

From benjaminrk at gmail.com  Tue Oct 29 17:56:47 2013
From: benjaminrk at gmail.com (MinRK)
Date: Tue, 29 Oct 2013 14:56:47 -0700
Subject: [IPython-dev] Python 3 single codebase - merged
In-Reply-To: <CAOvn4qg1NM8oEW8ESZr8K4asbBxoTgxNgXq4J4wSBmiz82at7Q@mail.gmail.com>
References: <CAOvn4qidXrsSdNazukSoeZk6YEe+xhtij7EbLE3YNCfL5QtL5w@mail.gmail.com>
	<CAKgW=6LSuzALB=Fp6WKUVkHO1Nz+N_EbqYWVSgvH3HaR_kKQmg@mail.gmail.com>
	<CAOvn4qg1NM8oEW8ESZr8K4asbBxoTgxNgXq4J4wSBmiz82at7Q@mail.gmail.com>
Message-ID: <CAHNn8BXXRQt0SP=mRUqGxCc8nbuKZSx07bAnQJ5qjUtWAjVqsw@mail.gmail.com>

The suffix / develop conversation is an interesting one for the use case of
multiple Pythons - if anyone has any pointers to other people discussing
either aspect, it would be much appreciated.

-MinRK


On Tue, Oct 29, 2013 at 2:43 PM, Thomas Kluyver <takowl at gmail.com> wrote:

> On 29 October 2013 14:26, Aaron Meurer <asmeurer at gmail.com> wrote:
>
>> Great to hear this! So does this also mean that you're getting rid of
>> the ipython3 nonsense?
>>
>
> Not just yet, but I've put the naming question on our agenda for
> Thursday's dev meeting:
> https://hackpad.com/IPython-dev-meetings-6wTSjJt7TZK
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131029/a99bac2b/attachment.html>

From asmeurer at gmail.com  Tue Oct 29 18:36:54 2013
From: asmeurer at gmail.com (Aaron Meurer)
Date: Tue, 29 Oct 2013 16:36:54 -0600
Subject: [IPython-dev] Python 3 single codebase - merged
In-Reply-To: <CAHNn8BXXRQt0SP=mRUqGxCc8nbuKZSx07bAnQJ5qjUtWAjVqsw@mail.gmail.com>
References: <CAOvn4qidXrsSdNazukSoeZk6YEe+xhtij7EbLE3YNCfL5QtL5w@mail.gmail.com>
	<CAKgW=6LSuzALB=Fp6WKUVkHO1Nz+N_EbqYWVSgvH3HaR_kKQmg@mail.gmail.com>
	<CAOvn4qg1NM8oEW8ESZr8K4asbBxoTgxNgXq4J4wSBmiz82at7Q@mail.gmail.com>
	<CAHNn8BXXRQt0SP=mRUqGxCc8nbuKZSx07bAnQJ5qjUtWAjVqsw@mail.gmail.com>
Message-ID: <CAKgW=6J3-BJXm2-77kLrfMKHW3uYr_OOo0BXD0UqgaPwqCHJog@mail.gmail.com>

There's the thread I started on this mailing list a while back, which
actually continued a bit on the two other mailing lists I CCd (SymPy
and PuDB).

Aaron Meurer

On Tue, Oct 29, 2013 at 3:56 PM, MinRK <benjaminrk at gmail.com> wrote:
> The suffix / develop conversation is an interesting one for the use case of
> multiple Pythons - if anyone has any pointers to other people discussing
> either aspect, it would be much appreciated.
>
> -MinRK
>
>
> On Tue, Oct 29, 2013 at 2:43 PM, Thomas Kluyver <takowl at gmail.com> wrote:
>>
>> On 29 October 2013 14:26, Aaron Meurer <asmeurer at gmail.com> wrote:
>>>
>>> Great to hear this! So does this also mean that you're getting rid of
>>> the ipython3 nonsense?
>>
>>
>> Not just yet, but I've put the naming question on our agenda for
>> Thursday's dev meeting:
>> https://hackpad.com/IPython-dev-meetings-6wTSjJt7TZK
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>


From fperez.net at gmail.com  Tue Oct 29 20:11:22 2013
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 29 Oct 2013 17:11:22 -0700
Subject: [IPython-dev] Python 3 single codebase - merged
In-Reply-To: <CAKgW=6LSuzALB=Fp6WKUVkHO1Nz+N_EbqYWVSgvH3HaR_kKQmg@mail.gmail.com>
References: <CAOvn4qidXrsSdNazukSoeZk6YEe+xhtij7EbLE3YNCfL5QtL5w@mail.gmail.com>
	<CAKgW=6LSuzALB=Fp6WKUVkHO1Nz+N_EbqYWVSgvH3HaR_kKQmg@mail.gmail.com>
Message-ID: <CAHAreOqag8CSxm+MQhwbA4qBzMFdw-5h=De8nCgJdYKfC=iPwg@mail.gmail.com>

On Tue, Oct 29, 2013 at 2:26 PM, Aaron Meurer <asmeurer at gmail.com> wrote:

> This seems to be a general problem with setup.py develop. It only
> supports developing into one Python environment at a time, which is
> annoying if you have a ton of environments (e.g., with conda). I'm
> very interested in how you end up fixing this.
>

One alternative (what I do) is to *not* use `setup.py develop` and instead
just manually symlink the IPython directory somewhere in $PYTHONPATH and
the `ipython` entry point somewhere in $PATH.  Then it's a trivial matter
of aliasing

ipy3 = python3 `which ipython`

and you're off to the races, always running from source.

Cheers,

f


-- 
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131029/e8a73ce7/attachment.html>

From takowl at gmail.com  Tue Oct 29 20:12:54 2013
From: takowl at gmail.com (Thomas Kluyver)
Date: Tue, 29 Oct 2013 17:12:54 -0700
Subject: [IPython-dev] Python 3 single codebase - merged
In-Reply-To: <CAHAreOqag8CSxm+MQhwbA4qBzMFdw-5h=De8nCgJdYKfC=iPwg@mail.gmail.com>
References: <CAOvn4qidXrsSdNazukSoeZk6YEe+xhtij7EbLE3YNCfL5QtL5w@mail.gmail.com>
	<CAKgW=6LSuzALB=Fp6WKUVkHO1Nz+N_EbqYWVSgvH3HaR_kKQmg@mail.gmail.com>
	<CAHAreOqag8CSxm+MQhwbA4qBzMFdw-5h=De8nCgJdYKfC=iPwg@mail.gmail.com>
Message-ID: <CAOvn4qheADp=9a0ZorpeY-WK4OBsfW7D3g6NP3av=cid1FVHdQ@mail.gmail.com>

Or don't even bother with the entry point, and alias it to python3 -m
IPython ;-)


On 29 October 2013 17:11, Fernando Perez <fperez.net at gmail.com> wrote:

>
> On Tue, Oct 29, 2013 at 2:26 PM, Aaron Meurer <asmeurer at gmail.com> wrote:
>
>> This seems to be a general problem with setup.py develop. It only
>> supports developing into one Python environment at a time, which is
>> annoying if you have a ton of environments (e.g., with conda). I'm
>> very interested in how you end up fixing this.
>>
>
> One alternative (what I do) is to *not* use `setup.py develop` and instead
> just manually symlink the IPython directory somewhere in $PYTHONPATH and
> the `ipython` entry point somewhere in $PATH.  Then it's a trivial matter
> of aliasing
>
> ipy3 = python3 `which ipython`
>
> and you're off to the races, always running from source.
>
> Cheers,
>
> f
>
>
> --
> Fernando Perez (@fperez_org; http://fperez.org)
> fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
> fernando.perez-at-berkeley: contact me here for any direct mail
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131029/9598434f/attachment.html>

From fperez.net at gmail.com  Tue Oct 29 20:17:19 2013
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 29 Oct 2013 17:17:19 -0700
Subject: [IPython-dev] Python 3 single codebase - merged
In-Reply-To: <CAOvn4qheADp=9a0ZorpeY-WK4OBsfW7D3g6NP3av=cid1FVHdQ@mail.gmail.com>
References: <CAOvn4qidXrsSdNazukSoeZk6YEe+xhtij7EbLE3YNCfL5QtL5w@mail.gmail.com>
	<CAKgW=6LSuzALB=Fp6WKUVkHO1Nz+N_EbqYWVSgvH3HaR_kKQmg@mail.gmail.com>
	<CAHAreOqag8CSxm+MQhwbA4qBzMFdw-5h=De8nCgJdYKfC=iPwg@mail.gmail.com>
	<CAOvn4qheADp=9a0ZorpeY-WK4OBsfW7D3g6NP3av=cid1FVHdQ@mail.gmail.com>
Message-ID: <CAHAreOpx91g86uVR=bzDk7j-rMkf=tWeTrafX3dUCuUjHhhx4Q@mail.gmail.com>

Ah, I didn't realize that would work even for subcommands. I thought it
would do only the console.  Great!!


On Tue, Oct 29, 2013 at 5:12 PM, Thomas Kluyver <takowl at gmail.com> wrote:

> Or don't even bother with the entry point, and alias it to python3 -m
> IPython ;-)
>
>
> On 29 October 2013 17:11, Fernando Perez <fperez.net at gmail.com> wrote:
>
>>
>> On Tue, Oct 29, 2013 at 2:26 PM, Aaron Meurer <asmeurer at gmail.com> wrote:
>>
>>> This seems to be a general problem with setup.py develop. It only
>>> supports developing into one Python environment at a time, which is
>>> annoying if you have a ton of environments (e.g., with conda). I'm
>>> very interested in how you end up fixing this.
>>>
>>
>> One alternative (what I do) is to *not* use `setup.py develop` and
>> instead just manually symlink the IPython directory somewhere in
>> $PYTHONPATH and the `ipython` entry point somewhere in $PATH.  Then it's a
>> trivial matter of aliasing
>>
>> ipy3 = python3 `which ipython`
>>
>> and you're off to the races, always running from source.
>>
>> Cheers,
>>
>> f
>>
>>
>> --
>> Fernando Perez (@fperez_org; http://fperez.org)
>> fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
>> fernando.perez-at-berkeley: contact me here for any direct mail
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>


-- 
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131029/b51f8000/attachment.html>

From fperez.net at gmail.com  Tue Oct 29 20:18:46 2013
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 29 Oct 2013 17:18:46 -0700
Subject: [IPython-dev] Python 3 single codebase - merged
In-Reply-To: <CAHAreOpx91g86uVR=bzDk7j-rMkf=tWeTrafX3dUCuUjHhhx4Q@mail.gmail.com>
References: <CAOvn4qidXrsSdNazukSoeZk6YEe+xhtij7EbLE3YNCfL5QtL5w@mail.gmail.com>
	<CAKgW=6LSuzALB=Fp6WKUVkHO1Nz+N_EbqYWVSgvH3HaR_kKQmg@mail.gmail.com>
	<CAHAreOqag8CSxm+MQhwbA4qBzMFdw-5h=De8nCgJdYKfC=iPwg@mail.gmail.com>
	<CAOvn4qheADp=9a0ZorpeY-WK4OBsfW7D3g6NP3av=cid1FVHdQ@mail.gmail.com>
	<CAHAreOpx91g86uVR=bzDk7j-rMkf=tWeTrafX3dUCuUjHhhx4Q@mail.gmail.com>
Message-ID: <CAHAreOqMEwP2uotdoCEbLKKePzXODC3+wMdFKj9p5ZphZaXbeg@mail.gmail.com>

Ah, there's still the issue of that approach producing python2 kernels in a
notebook... Need to look at that more closely, but I have to run now.


On Tue, Oct 29, 2013 at 5:17 PM, Fernando Perez <fperez.net at gmail.com>wrote:

> Ah, I didn't realize that would work even for subcommands. I thought it
> would do only the console.  Great!!
>
>
> On Tue, Oct 29, 2013 at 5:12 PM, Thomas Kluyver <takowl at gmail.com> wrote:
>
>> Or don't even bother with the entry point, and alias it to python3 -m
>> IPython ;-)
>>
>>
>> On 29 October 2013 17:11, Fernando Perez <fperez.net at gmail.com> wrote:
>>
>>>
>>> On Tue, Oct 29, 2013 at 2:26 PM, Aaron Meurer <asmeurer at gmail.com>wrote:
>>>
>>>> This seems to be a general problem with setup.py develop. It only
>>>> supports developing into one Python environment at a time, which is
>>>> annoying if you have a ton of environments (e.g., with conda). I'm
>>>> very interested in how you end up fixing this.
>>>>
>>>
>>> One alternative (what I do) is to *not* use `setup.py develop` and
>>> instead just manually symlink the IPython directory somewhere in
>>> $PYTHONPATH and the `ipython` entry point somewhere in $PATH.  Then it's a
>>> trivial matter of aliasing
>>>
>>> ipy3 = python3 `which ipython`
>>>
>>> and you're off to the races, always running from source.
>>>
>>> Cheers,
>>>
>>> f
>>>
>>>
>>> --
>>> Fernando Perez (@fperez_org; http://fperez.org)
>>> fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
>>> fernando.perez-at-berkeley: contact me here for any direct mail
>>>
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>
>>>
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>>
>
>
> --
> Fernando Perez (@fperez_org; http://fperez.org)
> fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
> fernando.perez-at-berkeley: contact me here for any direct mail
>



-- 
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131029/3807c03a/attachment.html>

From takowl at gmail.com  Tue Oct 29 20:20:49 2013
From: takowl at gmail.com (Thomas Kluyver)
Date: Tue, 29 Oct 2013 17:20:49 -0700
Subject: [IPython-dev] Python 3 single codebase - merged
In-Reply-To: <CAHAreOqMEwP2uotdoCEbLKKePzXODC3+wMdFKj9p5ZphZaXbeg@mail.gmail.com>
References: <CAOvn4qidXrsSdNazukSoeZk6YEe+xhtij7EbLE3YNCfL5QtL5w@mail.gmail.com>
	<CAKgW=6LSuzALB=Fp6WKUVkHO1Nz+N_EbqYWVSgvH3HaR_kKQmg@mail.gmail.com>
	<CAHAreOqag8CSxm+MQhwbA4qBzMFdw-5h=De8nCgJdYKfC=iPwg@mail.gmail.com>
	<CAOvn4qheADp=9a0ZorpeY-WK4OBsfW7D3g6NP3av=cid1FVHdQ@mail.gmail.com>
	<CAHAreOpx91g86uVR=bzDk7j-rMkf=tWeTrafX3dUCuUjHhhx4Q@mail.gmail.com>
	<CAHAreOqMEwP2uotdoCEbLKKePzXODC3+wMdFKj9p5ZphZaXbeg@mail.gmail.com>
Message-ID: <CAOvn4qiqJb2-3h1Jj27H0KmhKTcCvYB5Ns=3NSEUK5ntkAL2_A@mail.gmail.com>

On 29 October 2013 17:18, Fernando Perez <fperez.net at gmail.com> wrote:

> Ah, there's still the issue of that approach producing python2 kernels in
> a notebook... Need to look at that more closely, but I have to run now.


I though we used sys.executable for that. Odd.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131029/217e027c/attachment.html>

From fperez.net at gmail.com  Tue Oct 29 20:22:15 2013
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 29 Oct 2013 17:22:15 -0700
Subject: [IPython-dev] Numbered lines after using nbconvert?
In-Reply-To: <CAH-3OQ7SHarzvnLuFTEdBZPA=Y-js2tZWQe81Rfki8AnPZqGCw@mail.gmail.com>
References: <CAH-3OQ7SHarzvnLuFTEdBZPA=Y-js2tZWQe81Rfki8AnPZqGCw@mail.gmail.com>
Message-ID: <CAHAreOrPAkWBTdAJN5uq+qrTgK7rHed3Cuzw536_VAN5-j695w@mail.gmail.com>

Hi Eric,

I don't think we have any out-of-the-box flags for this, but if I recall
correctly, pygments does have line numbering support. So a bit of playing
with the templates should easily do it.

You can find some nbconvert customization examples here:

https://github.com/ipython/nbconvert-examples

Best

f


On Sun, Oct 20, 2013 at 4:05 PM, Eric Matthes <ehmatthes at gmail.com> wrote:

> I just realized you can use Ctrl-M L to turn line numbering on in a cell,
> but I notice that those numbers are not visible when I view a notebook
> through IPython Notebook Viewer. After I use nbconvert on a notebook with
> the numbers visible, the resulting html file does not have line numbers.
>
> Is there a way to have the line numbers included in the html output when
> using nbconvert?
>
> Eric
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>


-- 
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131029/4f87a1cb/attachment.html>

From asmeurer at gmail.com  Tue Oct 29 20:22:29 2013
From: asmeurer at gmail.com (Aaron Meurer)
Date: Tue, 29 Oct 2013 18:22:29 -0600
Subject: [IPython-dev] Python 3 single codebase - merged
In-Reply-To: <CAHAreOqag8CSxm+MQhwbA4qBzMFdw-5h=De8nCgJdYKfC=iPwg@mail.gmail.com>
References: <CAOvn4qidXrsSdNazukSoeZk6YEe+xhtij7EbLE3YNCfL5QtL5w@mail.gmail.com>
	<CAKgW=6LSuzALB=Fp6WKUVkHO1Nz+N_EbqYWVSgvH3HaR_kKQmg@mail.gmail.com>
	<CAHAreOqag8CSxm+MQhwbA4qBzMFdw-5h=De8nCgJdYKfC=iPwg@mail.gmail.com>
Message-ID: <CAKgW=6JOuDL3TMEs_WumCJtK58g=W6FnVM3ZKOnKgtvSWfagqw@mail.gmail.com>

I think an even better way is to use a .pth file
(http://docs.python.org/2/library/site.html#module-site). This has the
advantage that they are environment specific, so, for instance, I can
put IPython dev in one environment and IPython stable in another. If
you modify $PYTHONPATH and $PATH globally, it's a mess.

I personally use conda environments, and so I think this strategy is
the best in that situation (hopefully conda will gain the ability to
manage this stuff soon too). If it works with virtualenv, it would
probably be the best there too.

Aaron Meurer


On Tue, Oct 29, 2013 at 6:11 PM, Fernando Perez <fperez.net at gmail.com> wrote:
>
> On Tue, Oct 29, 2013 at 2:26 PM, Aaron Meurer <asmeurer at gmail.com> wrote:
>>
>> This seems to be a general problem with setup.py develop. It only
>> supports developing into one Python environment at a time, which is
>> annoying if you have a ton of environments (e.g., with conda). I'm
>> very interested in how you end up fixing this.
>
>
> One alternative (what I do) is to *not* use `setup.py develop` and instead
> just manually symlink the IPython directory somewhere in $PYTHONPATH and the
> `ipython` entry point somewhere in $PATH.  Then it's a trivial matter of
> aliasing
>
> ipy3 = python3 `which ipython`
>
> and you're off to the races, always running from source.
>
> Cheers,
>
> f
>
>
> --
> Fernando Perez (@fperez_org; http://fperez.org)
> fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
> fernando.perez-at-berkeley: contact me here for any direct mail
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>


From fperez.net at gmail.com  Tue Oct 29 20:23:31 2013
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 29 Oct 2013 17:23:31 -0700
Subject: [IPython-dev] Python 3 single codebase - merged
In-Reply-To: <CAOvn4qiqJb2-3h1Jj27H0KmhKTcCvYB5Ns=3NSEUK5ntkAL2_A@mail.gmail.com>
References: <CAOvn4qidXrsSdNazukSoeZk6YEe+xhtij7EbLE3YNCfL5QtL5w@mail.gmail.com>
	<CAKgW=6LSuzALB=Fp6WKUVkHO1Nz+N_EbqYWVSgvH3HaR_kKQmg@mail.gmail.com>
	<CAHAreOqag8CSxm+MQhwbA4qBzMFdw-5h=De8nCgJdYKfC=iPwg@mail.gmail.com>
	<CAOvn4qheADp=9a0ZorpeY-WK4OBsfW7D3g6NP3av=cid1FVHdQ@mail.gmail.com>
	<CAHAreOpx91g86uVR=bzDk7j-rMkf=tWeTrafX3dUCuUjHhhx4Q@mail.gmail.com>
	<CAHAreOqMEwP2uotdoCEbLKKePzXODC3+wMdFKj9p5ZphZaXbeg@mail.gmail.com>
	<CAOvn4qiqJb2-3h1Jj27H0KmhKTcCvYB5Ns=3NSEUK5ntkAL2_A@mail.gmail.com>
Message-ID: <CAHAreOpJuiR0rMW17o5iOfgBytQtf0nFv+iNRn+EzzGp9bV4OA@mail.gmail.com>

Ah, never mind. I wrote 'print 1' and it worked, and I thought I had a 2
kernel. In fact, it was autocall fixing it for me, which in the notebook
happens silently.

Yes, the kernel is py3, all is well.

Cheers,

f


On Tue, Oct 29, 2013 at 5:20 PM, Thomas Kluyver <takowl at gmail.com> wrote:

> On 29 October 2013 17:18, Fernando Perez <fperez.net at gmail.com> wrote:
>
>> Ah, there's still the issue of that approach producing python2 kernels in
>> a notebook... Need to look at that more closely, but I have to run now.
>
>
> I though we used sys.executable for that. Odd.
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>


-- 
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131029/3f52c514/attachment.html>

From asmeurer at gmail.com  Tue Oct 29 20:36:07 2013
From: asmeurer at gmail.com (Aaron Meurer)
Date: Tue, 29 Oct 2013 18:36:07 -0600
Subject: [IPython-dev] Python 3 single codebase - merged
In-Reply-To: <CAHAreOpJuiR0rMW17o5iOfgBytQtf0nFv+iNRn+EzzGp9bV4OA@mail.gmail.com>
References: <CAOvn4qidXrsSdNazukSoeZk6YEe+xhtij7EbLE3YNCfL5QtL5w@mail.gmail.com>
	<CAKgW=6LSuzALB=Fp6WKUVkHO1Nz+N_EbqYWVSgvH3HaR_kKQmg@mail.gmail.com>
	<CAHAreOqag8CSxm+MQhwbA4qBzMFdw-5h=De8nCgJdYKfC=iPwg@mail.gmail.com>
	<CAOvn4qheADp=9a0ZorpeY-WK4OBsfW7D3g6NP3av=cid1FVHdQ@mail.gmail.com>
	<CAHAreOpx91g86uVR=bzDk7j-rMkf=tWeTrafX3dUCuUjHhhx4Q@mail.gmail.com>
	<CAHAreOqMEwP2uotdoCEbLKKePzXODC3+wMdFKj9p5ZphZaXbeg@mail.gmail.com>
	<CAOvn4qiqJb2-3h1Jj27H0KmhKTcCvYB5Ns=3NSEUK5ntkAL2_A@mail.gmail.com>
	<CAHAreOpJuiR0rMW17o5iOfgBytQtf0nFv+iNRn+EzzGp9bV4OA@mail.gmail.com>
Message-ID: <CAKgW=6LFJxpJtWSiMas1qKLusGt6TeXFHM+6WGFsZjwEMvX4Ng@mail.gmail.com>

I guess a more reliable way (and faster to type) to check if you are
in Python 3 is to type "01". In Python 2 this gives octal 1, in Python
3, it is a syntax error.

Aaron Meurer

On Tue, Oct 29, 2013 at 6:23 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> Ah, never mind. I wrote 'print 1' and it worked, and I thought I had a 2
> kernel. In fact, it was autocall fixing it for me, which in the notebook
> happens silently.
>
> Yes, the kernel is py3, all is well.
>
> Cheers,
>
> f
>
>
> On Tue, Oct 29, 2013 at 5:20 PM, Thomas Kluyver <takowl at gmail.com> wrote:
>>
>> On 29 October 2013 17:18, Fernando Perez <fperez.net at gmail.com> wrote:
>>>
>>> Ah, there's still the issue of that approach producing python2 kernels in
>>> a notebook... Need to look at that more closely, but I have to run now.
>>
>>
>> I though we used sys.executable for that. Odd.
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
>
>
> --
> Fernando Perez (@fperez_org; http://fperez.org)
> fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
> fernando.perez-at-berkeley: contact me here for any direct mail
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>


From ellisonbg at gmail.com  Tue Oct 29 20:45:49 2013
From: ellisonbg at gmail.com (Brian Granger)
Date: Tue, 29 Oct 2013 17:45:49 -0700
Subject: [IPython-dev] Confusion about dev docs...
Message-ID: <CAH4pYpST-99eP9H3LfBu0vo7s6ajpSWbO=9FrcYV7UTCt_pdgQ@mail.gmail.com>

Here is what our sphinx based dev docs say:


-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com


From ellisonbg at gmail.com  Tue Oct 29 20:48:21 2013
From: ellisonbg at gmail.com (Brian Granger)
Date: Tue, 29 Oct 2013 17:48:21 -0700
Subject: [IPython-dev] Confusion about dev docs...take 2...
Message-ID: <CAH4pYpSRAVh2ZNYHgEr=i-m2KhPOkSU7ZurdhPFFj5g_oLcc6w@mail.gmail.com>

OK, let me try this again...

Here is what our Sphinx docs say about "Development related docs":

###
This are two categories of developer focused documentation:

Documentation for developers of IPython itself.
Documentation for developers of third party tools and libraries that
use IPython.

This part of our documentation only contains information in the second category.

Developers interested in working on IPython itself should consult our
developer information on the IPython GitHub wiki.
###

To me this suggests that anything related to writing code for IPython
should go in the GitHub wiki. That is what I thought we were doing.
OK, all of that makes sense to me.

But then I just saw the Python 2+3 dev docs were put into the Sphinx docs:

http://ipython.org/ipython-doc/dev/development/pycompat.html

Shouldn't this be on Github as it only really relates to people
writing code for IPython?

Cheers,

Brian


-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com


From takowl at gmail.com  Tue Oct 29 21:09:12 2013
From: takowl at gmail.com (Thomas Kluyver)
Date: Tue, 29 Oct 2013 18:09:12 -0700
Subject: [IPython-dev] Confusion about dev docs...take 2...
In-Reply-To: <CAH4pYpSRAVh2ZNYHgEr=i-m2KhPOkSU7ZurdhPFFj5g_oLcc6w@mail.gmail.com>
References: <CAH4pYpSRAVh2ZNYHgEr=i-m2KhPOkSU7ZurdhPFFj5g_oLcc6w@mail.gmail.com>
Message-ID: <CAOvn4qjf9mUJk4y28eEiO0_0pZxyR8H-hTc_v0QB29Ff6ET1wA@mail.gmail.com>

I'm not sure that the distinction is that clear - all of the docs already
in that section seem potentially useful to people working on IPython
itself, as well as on related projects. The version compatibility stuff
could also be useful to developers of related projects, although there's
plenty of other such advice out there on the net.

But ultimately, I just preferred to do this as a Sphinx doc than a wiki
page.

Thomas


On 29 October 2013 17:48, Brian Granger <ellisonbg at gmail.com> wrote:

> OK, let me try this again...
>
> Here is what our Sphinx docs say about "Development related docs":
>
> ###
> This are two categories of developer focused documentation:
>
> Documentation for developers of IPython itself.
> Documentation for developers of third party tools and libraries that
> use IPython.
>
> This part of our documentation only contains information in the second
> category.
>
> Developers interested in working on IPython itself should consult our
> developer information on the IPython GitHub wiki.
> ###
>
> To me this suggests that anything related to writing code for IPython
> should go in the GitHub wiki. That is what I thought we were doing.
> OK, all of that makes sense to me.
>
> But then I just saw the Python 2+3 dev docs were put into the Sphinx docs:
>
> http://ipython.org/ipython-doc/dev/development/pycompat.html
>
> Shouldn't this be on Github as it only really relates to people
> writing code for IPython?
>
> Cheers,
>
> Brian
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu and ellisonbg at gmail.com
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131029/d41acf26/attachment.html>

From ellisonbg at gmail.com  Tue Oct 29 21:19:04 2013
From: ellisonbg at gmail.com (Brian Granger)
Date: Tue, 29 Oct 2013 18:19:04 -0700
Subject: [IPython-dev] Confusion about dev docs...take 2...
In-Reply-To: <CAOvn4qjf9mUJk4y28eEiO0_0pZxyR8H-hTc_v0QB29Ff6ET1wA@mail.gmail.com>
References: <CAH4pYpSRAVh2ZNYHgEr=i-m2KhPOkSU7ZurdhPFFj5g_oLcc6w@mail.gmail.com>
	<CAOvn4qjf9mUJk4y28eEiO0_0pZxyR8H-hTc_v0QB29Ff6ET1wA@mail.gmail.com>
Message-ID: <CAH4pYpQ7oR2=aKmF=CT=o6Fq9EinHk-CY+JnbJ-jL54GQumLWA@mail.gmail.com>

The problem is that next time someone adds dev related docs, they
won't know where to put it. Some of them will put it into Sphinx and
we will be back to having our dev docs all over the place. This
experiment in the past has shown that this process converges to having
>=2, out of synch copies, of all our dev docs in different places.

I am fine if we want to revisit the location of our dev docs, but
until then, I think we should keep everything on Github...

If the issue is that you personally don't want to move it over to
GitHub, I don't mind doing that. But I don't want to be the only one
who *thinks* we are trying to keep things on GitHub.

Cheers,

Brian

On Tue, Oct 29, 2013 at 6:09 PM, Thomas Kluyver <takowl at gmail.com> wrote:
> I'm not sure that the distinction is that clear - all of the docs already in
> that section seem potentially useful to people working on IPython itself, as
> well as on related projects. The version compatibility stuff could also be
> useful to developers of related projects, although there's plenty of other
> such advice out there on the net.
>
> But ultimately, I just preferred to do this as a Sphinx doc than a wiki
> page.
>
> Thomas
>
>
> On 29 October 2013 17:48, Brian Granger <ellisonbg at gmail.com> wrote:
>>
>> OK, let me try this again...
>>
>> Here is what our Sphinx docs say about "Development related docs":
>>
>> ###
>> This are two categories of developer focused documentation:
>>
>> Documentation for developers of IPython itself.
>> Documentation for developers of third party tools and libraries that
>> use IPython.
>>
>> This part of our documentation only contains information in the second
>> category.
>>
>> Developers interested in working on IPython itself should consult our
>> developer information on the IPython GitHub wiki.
>> ###
>>
>> To me this suggests that anything related to writing code for IPython
>> should go in the GitHub wiki. That is what I thought we were doing.
>> OK, all of that makes sense to me.
>>
>> But then I just saw the Python 2+3 dev docs were put into the Sphinx docs:
>>
>> http://ipython.org/ipython-doc/dev/development/pycompat.html
>>
>> Shouldn't this be on Github as it only really relates to people
>> writing code for IPython?
>>
>> Cheers,
>>
>> Brian
>>
>>
>> --
>> Brian E. Granger
>> Cal Poly State University, San Luis Obispo
>> bgranger at calpoly.edu and ellisonbg at gmail.com
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com


From takowl at gmail.com  Tue Oct 29 21:30:33 2013
From: takowl at gmail.com (Thomas Kluyver)
Date: Tue, 29 Oct 2013 18:30:33 -0700
Subject: [IPython-dev] Confusion about dev docs...take 2...
In-Reply-To: <CAH4pYpQ7oR2=aKmF=CT=o6Fq9EinHk-CY+JnbJ-jL54GQumLWA@mail.gmail.com>
References: <CAH4pYpSRAVh2ZNYHgEr=i-m2KhPOkSU7ZurdhPFFj5g_oLcc6w@mail.gmail.com>
	<CAOvn4qjf9mUJk4y28eEiO0_0pZxyR8H-hTc_v0QB29Ff6ET1wA@mail.gmail.com>
	<CAH4pYpQ7oR2=aKmF=CT=o6Fq9EinHk-CY+JnbJ-jL54GQumLWA@mail.gmail.com>
Message-ID: <CAOvn4qi-wwkCZtL+1d_MMMFs_rMmNCHXDdJDccLVOe6eLmX8=A@mail.gmail.com>

On 29 October 2013 18:19, Brian Granger <ellisonbg at gmail.com> wrote:

> I am fine if we want to revisit the location of our dev docs, but
> until then, I think we should keep everything on Github...
>

I've rather gone off wiki-based docs. I think the model leads to poorly
curated information dumps, where nobody feels responsibility for the page
as a whole, and every bit of information is left there in case it's useful
to someone somewhere. Plus, for documenting code, Sphinx is just a much
nicer and more powerful system.

> If the issue is that you personally don't want to move it over to
> GitHub, I don't mind doing that.

Please don't. I think it's much better rendered in the docs, and has a
better chance of being kept up to date if changes are needed.

Thanks,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131029/c350b94e/attachment.html>

From darcamo at gmail.com  Wed Oct 30 00:12:25 2013
From: darcamo at gmail.com (Darlan Cavalcante Moreira)
Date: Wed, 30 Oct 2013 01:12:25 -0300
Subject: [IPython-dev] newcommand in Markdown cells and nbconver
Message-ID: <87mwlrz9au.fsf@gmail.com>


Hi list,

I wonder what is the best way to define newcommand in an IPython
notebook. The documentation says I should define them between dollar
signs, such as
$\newcommand{\Mt}[1]{\mathbf{#1}}$.

This is required so that they are interpreted by mathjax, which works as
expected in the notebook. However, when converting the notebook with
nbconvert to latex this is passed unchanged and latex won't compile the
generated tex.

Is there a better way for this?

In my use case, I have a single cell with many newcommands. It would
work for me if this cell could be ignored by nbconvert. Even better if
nbconvert could add a package such as \usepackage{mymathdefinitions},
since all these commands are in a mymathdefinitions.sty file in the same
folder.


Cheers,
Darlan


From bussonniermatthias at gmail.com  Wed Oct 30 04:10:03 2013
From: bussonniermatthias at gmail.com (Matthias Bussonnier)
Date: Wed, 30 Oct 2013 09:10:03 +0100
Subject: [IPython-dev] newcommand in Markdown cells and nbconver
In-Reply-To: <87mwlrz9au.fsf@gmail.com>
References: <87mwlrz9au.fsf@gmail.com>
Message-ID: <73F91D7A-79B6-401F-AD23-4B194274CB19@gmail.com>

You can use a raw cell that will be passed untouched by nbconvert to tex. The ability to exclude can be done using custom templates and preprocessor right now, but is still a little involved.

Envoy? de mon iPhone

> Le 30 oct. 2013 ? 05:12, Darlan Cavalcante Moreira <darcamo at gmail.com> a ?crit :
> 
> 
> Hi list,
> 
> I wonder what is the best way to define newcommand in an IPython
> notebook. The documentation says I should define them between dollar
> signs, such as
> $\newcommand{\Mt}[1]{\mathbf{#1}}$.
> 
> This is required so that they are interpreted by mathjax, which works as
> expected in the notebook. However, when converting the notebook with
> nbconvert to latex this is passed unchanged and latex won't compile the
> generated tex.
> 
> Is there a better way for this?
> 
> In my use case, I have a single cell with many newcommands. It would
> work for me if this cell could be ignored by nbconvert. Even better if
> nbconvert could add a package such as \usepackage{mymathdefinitions},
> since all these commands are in a mymathdefinitions.sty file in the same
> folder.
> 
> 
> Cheers,
> Darlan
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev


From wagnerfl at student.ethz.ch  Wed Oct 30 04:33:41 2013
From: wagnerfl at student.ethz.ch (Florian M. Wagner)
Date: Wed, 30 Oct 2013 09:33:41 +0100
Subject: [IPython-dev] Numpy with OpenBLAS vs. IPython
In-Reply-To: <527000F0.20704@googlemail.com>
References: <526FDFF5.30304@student.ethz.ch> <527000F0.20704@googlemail.com>
Message-ID: <5270C465.1000107@student.ethz.ch>

Thanks guys,

@Julian: Reducing the thread number did not help
@Thomas: dap is mpl-basemap dependency, fixed the import issue, but the 
error still occurs

It is really weird that it is occuring only when printing the array, or 
slicing the array. And whats more weird, that it works in plain Python 
as I understood that IPython has no numpy dependency?

Thanks and regards
Florian

Am 29.10.2013 19:39, schrieb Julian Taylor:
> does this also happen if you do this before starting ipython?
>
> export OPENBLAS_NUM_THREADS=1
> (assuming bash shell)
>
> On 29.10.2013 17:19, Florian M. Wagner wrote:
>> Dear all,
>>
>> I recently compiled numpy with OpenBlas for faster matrix-matrix
>> multiplication. Everything works fine, but IPython seems to dislike it.
>> I get a Segmentation Fault error when trying this (I reinstalled IPython
>> 1.1.0 after numpy compilation):
>>
>>      fwagner at fwagner-notebook ~ $ ipython -c "import numpy as np; print
>>      np.__version__; import IPython; print IPython.__version__; A =
>>      np.random.randn(600, 600); print A[20,53]; print A"
>>      /usr/local/bin/ipython:5: UserWarning: Module dap was already
>>      imported from None, but /usr/lib/python2.7/dist-packages is being
>>      added to sys.path
>>        from pkg_resources import load_entry_point
>>      1.9.0.dev-54d3559
>>      1.1.0
>>      -2.1004055886
>>      Speicherzugriffsfehler
>>
>> In comparison, this works fine (just python instead of ipython):
>>
>>      fwagner at fwagner-notebook ~ $ python -c "import numpy as np; print
>>      np.__version__; import IPython; print IPython.__version__; A =
>>      np.random.randn(600, 600); print A[20,53]; print A"
>>      1.9.0.dev-54d3559
>>      1.1.0
>>      -1.10282239744
>>      [[ 0.13798084 -0.39195796 -0.15309986 ...,  1.47471232 -0.9158455
>>         0.97060671]
>>       [ 0.25720169  0.51895478  0.55175787 ..., -0.02010573  0.78047754
>>        -1.07891961]
>>       [ 1.59478156  0.81245486 -0.03959768 ..., -0.04816659 -0.03356907
>>        -0.11860379]
>>       ...,
>>       [-0.06299817 -0.0956477  -0.32987518 ..., -1.47714386  1.66736916
>>        -0.47704276]
>>       [-0.93769589  1.50006542  0.97782803 ..., -0.5034154   1.31592011
>>        -0.74482995]
>>       [-0.24661336 -0.98979706 -0.39366363 ...,  0.20507632  0.8701609
>>        -1.10449957]]
>>
>> Any ideas what might cause this problem?
>>
>> Thanks,
>>
>> Florian
>>
>>
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>



From wagnerfl at student.ethz.ch  Wed Oct 30 04:46:11 2013
From: wagnerfl at student.ethz.ch (Florian M. Wagner)
Date: Wed, 30 Oct 2013 09:46:11 +0100
Subject: [IPython-dev] Numpy with OpenBLAS vs. IPython
In-Reply-To: <5270C465.1000107@student.ethz.ch>
References: <526FDFF5.30304@student.ethz.ch> <527000F0.20704@googlemail.com>
	<5270C465.1000107@student.ethz.ch>
Message-ID: <5270C753.30805@student.ethz.ch>

I reproduced the error with the latest IPython source:

    fwagner at fwagner-notebook ~/Downloads/ipython $ ipython
    Python 2.7.4 (default, Sep 26 2013, 03:20:26)
    Type "copyright", "credits" or "license" for more information.

    IPython 2.0.0-dev -- An enhanced Interactive Python.
    ?         -> Introduction and overview of IPython's features.
    %quickref -> Quick reference.
    help      -> Python's own help system.
    object?   -> Details about 'object', use 'object??' for extra details.

    In [1]: A = np.random.randn(50,50)

    In [2]: A[0,0]
    Out[2]: 0.62268531821589967

    In [3]: A.T.dot(A)
    Speicherzugriffsfehler

Compared to:

    Python 2.7.4 (default, Sep 26 2013, 03:20:26)
    [GCC 4.7.3] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
     >>> import numpy as np
     >>> A = np.random.randn(50,50)
     >>> A.T.dot(A)
    array([[  4.61866860e+01,   1.97714469e+00, 8.78842173e+00, ...,
              -9.65143259e+00,   4.74312877e+00, -1.85163266e+01],
            [  1.97714469e+00,   4.50113072e+01, -1.13105045e+01, ...,
               2.31604581e+00,   4.93068512e+00, 1.29316267e+01],
            [  8.78842173e+00,  -1.13105045e+01, 6.02859864e+01, ...,
              -2.65040891e+00,   3.98374437e+00, -1.54860323e+01],
            ...,
            [ -9.65143259e+00,   2.31604581e+00, -2.65040891e+00, ...,
               3.81774984e+01,   1.63768677e+00, 1.16681961e+01],
            [  4.74312877e+00,   4.93068512e+00, 3.98374437e+00, ...,
               1.63768677e+00,   5.11159138e+01, 6.56039753e-02],
            [ -1.85163266e+01,   1.29316267e+01, -1.54860323e+01, ...,
               1.16681961e+01,   6.56039753e-02, 6.61061915e+01]])



Am 30.10.2013 09:33, schrieb Florian M. Wagner:
> Thanks guys,
>
> @Julian: Reducing the thread number did not help
> @Thomas: dap is mpl-basemap dependency, fixed the import issue, but the
> error still occurs
>
> It is really weird that it is occuring only when printing the array, or
> slicing the array. And whats more weird, that it works in plain Python
> as I understood that IPython has no numpy dependency?
>
> Thanks and regards
> Florian
>
> Am 29.10.2013 19:39, schrieb Julian Taylor:
>> does this also happen if you do this before starting ipython?
>>
>> export OPENBLAS_NUM_THREADS=1
>> (assuming bash shell)
>>
>> On 29.10.2013 17:19, Florian M. Wagner wrote:
>>> Dear all,
>>>
>>> I recently compiled numpy with OpenBlas for faster matrix-matrix
>>> multiplication. Everything works fine, but IPython seems to dislike it.
>>> I get a Segmentation Fault error when trying this (I reinstalled IPython
>>> 1.1.0 after numpy compilation):
>>>
>>>       fwagner at fwagner-notebook ~ $ ipython -c "import numpy as np; print
>>>       np.__version__; import IPython; print IPython.__version__; A =
>>>       np.random.randn(600, 600); print A[20,53]; print A"
>>>       /usr/local/bin/ipython:5: UserWarning: Module dap was already
>>>       imported from None, but /usr/lib/python2.7/dist-packages is being
>>>       added to sys.path
>>>         from pkg_resources import load_entry_point
>>>       1.9.0.dev-54d3559
>>>       1.1.0
>>>       -2.1004055886
>>>       Speicherzugriffsfehler
>>>
>>> In comparison, this works fine (just python instead of ipython):
>>>
>>>       fwagner at fwagner-notebook ~ $ python -c "import numpy as np; print
>>>       np.__version__; import IPython; print IPython.__version__; A =
>>>       np.random.randn(600, 600); print A[20,53]; print A"
>>>       1.9.0.dev-54d3559
>>>       1.1.0
>>>       -1.10282239744
>>>       [[ 0.13798084 -0.39195796 -0.15309986 ...,  1.47471232 -0.9158455
>>>          0.97060671]
>>>        [ 0.25720169  0.51895478  0.55175787 ..., -0.02010573  0.78047754
>>>         -1.07891961]
>>>        [ 1.59478156  0.81245486 -0.03959768 ..., -0.04816659 -0.03356907
>>>         -0.11860379]
>>>        ...,
>>>        [-0.06299817 -0.0956477  -0.32987518 ..., -1.47714386  1.66736916
>>>         -0.47704276]
>>>        [-0.93769589  1.50006542  0.97782803 ..., -0.5034154   1.31592011
>>>         -0.74482995]
>>>        [-0.24661336 -0.98979706 -0.39366363 ...,  0.20507632  0.8701609
>>>         -1.10449957]]
>>>
>>> Any ideas what might cause this problem?
>>>
>>> Thanks,
>>>
>>> Florian
>>>
>>>
>>>
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131030/d2cd662f/attachment.html>

From zvoros at gmail.com  Wed Oct 30 06:48:18 2013
From: zvoros at gmail.com (=?ISO-8859-1?Q?Zolt=E1n_V=F6r=F6s?=)
Date: Wed, 30 Oct 2013 11:48:18 +0100
Subject: [IPython-dev] cursor is ahead of true position in markdown cell
Message-ID: <5270E3F2.20404@gmail.com>

Hi all,

In the latest version from master I encountered the following problem: 
if I do this in a markdown cell of an HTML notebook,



then the cursor will always be ahead of the actual position, once the 
marked up text is longer than one line (meaning that the text is wrapped 
around, and not that there is a newline character somewhere). In the 
example above, the cursor is immediately after 's' in the word laboris, 
there is really no space. (If I press backspace, 's' will be removed.) 
The same would happen with **boldface**, or if the text was closed with 
a star.

Is this a problem in ipython, or the roots of the problem are actually 
deeper?

Cheers,

Zolt?n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131030/16e4adcb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ghgfcied.png
Type: image/png
Size: 10186 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131030/16e4adcb/attachment.png>

From bussonniermatthias at gmail.com  Wed Oct 30 07:37:53 2013
From: bussonniermatthias at gmail.com (Matthias Bussonnier)
Date: Wed, 30 Oct 2013 12:37:53 +0100
Subject: [IPython-dev] cursor is ahead of true position in markdown cell
In-Reply-To: <5270E3F2.20404@gmail.com>
References: <5270E3F2.20404@gmail.com>
Message-ID: <611870E0-41D3-4FAA-B33C-B4C728B245BC@gmail.com>

This ?
https://github.com/ipython/ipython/issues/3361


Envoy? de mon iPhone

> Le 30 oct. 2013 ? 11:48, Zolt?n V?r?s <zvoros at gmail.com> a ?crit :
> 
> Hi all,
> 
> In the latest version from master I encountered the following problem: if I do this in a markdown cell of an HTML notebook, 
> 
> <ghgfcied.png>
> 
> then the cursor will always be ahead of the actual position, once the marked up text is longer than one line (meaning that the text is wrapped around, and not that there is a newline character somewhere). In the example above, the cursor is immediately after 's' in the word laboris, there is really no space. (If I press backspace, 's' will be removed.) The same would happen with **boldface**, or if the text was closed with a star.
> 
> Is this a problem in ipython, or the roots of the problem are actually deeper?
> 
> Cheers,
> 
> Zolt?n
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131030/d9077161/attachment.html>

From zvoros at gmail.com  Wed Oct 30 07:56:55 2013
From: zvoros at gmail.com (=?ISO-8859-1?Q?Zolt=E1n_V=F6r=F6s?=)
Date: Wed, 30 Oct 2013 12:56:55 +0100
Subject: [IPython-dev] cursor is ahead of true position in markdown cell
In-Reply-To: <611870E0-41D3-4FAA-B33C-B4C728B245BC@gmail.com>
References: <5270E3F2.20404@gmail.com>
	<611870E0-41D3-4FAA-B33C-B4C728B245BC@gmail.com>
Message-ID: <5270F407.4030204@gmail.com>

Hi Matthias,

Thanks for the info! I will try to update the chromium browser.

Cheers,
Zolt?n


On 30/10/13 12:37, Matthias Bussonnier wrote:
> This ?
> https://github.com/ipython/ipython/issues/3361
>
>
> Envoy? de mon iPhone
>
> Le 30 oct. 2013 ? 11:48, Zolt?n V?r?s <zvoros at gmail.com 
> <mailto:zvoros at gmail.com>> a ?crit :
>
>> Hi all,
>>
>> In the latest version from master I encountered the following 
>> problem: if I do this in a markdown cell of an HTML notebook,
>>
>> <ghgfcied.png>
>>
>> then the cursor will always be ahead of the actual position, once the 
>> marked up text is longer than one line (meaning that the text is 
>> wrapped around, and not that there is a newline character somewhere). 
>> In the example above, the cursor is immediately after 's' in the word 
>> laboris, there is really no space. (If I press backspace, 's' will be 
>> removed.) The same would happen with **boldface**, or if the text was 
>> closed with a star.
>>
>> Is this a problem in ipython, or the roots of the problem are 
>> actually deeper?
>>
>> Cheers,
>>
>> Zolt?n
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org <mailto:IPython-dev at scipy.org>
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131030/19aa63e6/attachment.html>

From gaitan at phasety.com  Wed Oct 30 09:30:33 2013
From: gaitan at phasety.com (=?UTF-8?B?TWFydMOtbiBHYWl0w6Fu?=)
Date: Wed, 30 Oct 2013 11:30:33 -0200
Subject: [IPython-dev] Django ORM magic
Message-ID: <CAP-GCvmm85ZOF1fx=CyxXsi+1e_V64f23UaDP0kCp50DxMXqrA@mail.gmail.com>

Try to do some data analysis on resultados.gob.ar (the portal with official
data of the elections in Argentina) [1]  I've done a **fast and dirty**
cell magic to define django's models dynamically.

https://gist.github.com/mgaitan/7207448

usage example can be seen here:

http://nbviewer.ipython.org/7224431#modelando-resultados.gob.ar-en-una-base-de-datos


as a short rationale:

It's clear that django is not conceived for this use case, but I love its
ORM. The problem is that it needs some setup (configure "apps", databases,
etc. ). This magic handle that, and then import every model.

of course, there are tons of things to improve, but would be great some
early feedback .

cheers.
m.


[1]  In my province (C?rdoba) there was an "affair" with the last
congressman seat, due the difference is very short (<0.06%) and some people
found not computed votes in the telegrams (particularly, for the Left Union
Party). I'm hacking a bit trying to find more "suspicious" cases:
http://nbviewer.ipython.org/7224431
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131030/2f986b8e/attachment.html>

From darcamo at gmail.com  Wed Oct 30 16:51:34 2013
From: darcamo at gmail.com (Darlan Cavalcante Moreira)
Date: Wed, 30 Oct 2013 17:51:34 -0300
Subject: [IPython-dev] newcommand in Markdown cells and nbconver
In-Reply-To: <73F91D7A-79B6-401F-AD23-4B194274CB19@gmail.com>
References: <87mwlrz9au.fsf@gmail.com>
	<73F91D7A-79B6-401F-AD23-4B194274CB19@gmail.com>
Message-ID: <878uxascrt.fsf@gmail.com>


Thanks Matthias,

I'll have a look on custom templates and the preprocessor. Although it
would be nice to have the ability to tag cells for various purposes
(such as "ignore during export", "only/not on Latex/HTML export", etc).

Darlan

bussonniermatthias at gmail.com writes:

> You can use a raw cell that will be passed untouched by nbconvert to tex. The ability to exclude can be done using custom templates and preprocessor right now, but is still a little involved.
>
> Envoy? de mon iPhone
>
>> Le 30 oct. 2013 ? 05:12, Darlan Cavalcante Moreira <darcamo at gmail.com> a ?crit :
>> 
>> 
>> Hi list,
>> 
>> I wonder what is the best way to define newcommand in an IPython
>> notebook. The documentation says I should define them between dollar
>> signs, such as
>> $\newcommand{\Mt}[1]{\mathbf{#1}}$.
>> 
>> This is required so that they are interpreted by mathjax, which works as
>> expected in the notebook. However, when converting the notebook with
>> nbconvert to latex this is passed unchanged and latex won't compile the
>> generated tex.
>> 
>> Is there a better way for this?
>> 
>> In my use case, I have a single cell with many newcommands. It would
>> work for me if this cell could be ignored by nbconvert. Even better if
>> nbconvert could add a package such as \usepackage{mymathdefinitions},
>> since all these commands are in a mymathdefinitions.sty file in the same
>> folder.
>> 
>> 
>> Cheers,
>> Darlan
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev


-- 
Darlan Cavalcante Moreira
darcamo at gmail.com


From asadovsky at gmail.com  Wed Oct 30 23:28:19 2013
From: asadovsky at gmail.com (Adam Sadovsky)
Date: Wed, 30 Oct 2013 20:28:19 -0700
Subject: [IPython-dev] How to preconfigure notebook environment in v1.1?
Message-ID: <CADh3F_Urqt491PbgpACthrqU4chvus269p3k7hJu2q211xRCQw@mail.gmail.com>

Hi,

I recently upgraded from IPython 0.13 to 1.1.
In 0.13, I was able to execute code in each notebook at startup, but the
kernel code has changed and I can't figure out how to do it anymore. Could
someone point me in the right direction?

Here's my code that worked in 0.13:
----------------------------------------------------------------------------------
import os
import textwrap

from IPython.frontend.html.notebook.notebookapp import NotebookApp
from IPython.zmq.blockingkernelmanager import BlockingKernelManager
from IPython.zmq.entry_point import base_launch_kernel

class CustomKernelManager(BlockingKernelManager):
  """Runs custom code in each notebook when it starts."""

  def start_kernel(self, *args, **kwargs):
    kernel = super(CustomKernelManager, self).start_kernel(*args, **kwargs)

    # Initialize the communication channels and run custom code.
    self.start_channels()
    prepare_notebook = textwrap.dedent("""\
      %pylab inline
      from custom.module.path import foo
    """)
    self.shell_channel.execute(prepare_notebook)
    return kernel

  def start_channels(self, *args, **kwargs):
    """Checks if the channels are running before starting them."""
    # IPython will try to start the channels after launching the kernel,
    # without checking if they had already been started, which will cause
    # a double initialization problem.
    # This problem exists because IPython does not expect start_channels to
be
    # invoked by start_kernel, which is something that our custom
start_kernel
    # does.
    # Adding this check solves the issue.
    if not self.channels_running:
      super(CustomKernelManager, self).start_channels(*args, **kwargs)


notebookapp = NotebookApp.instance()
notebookapp.config_file_name = os.environ['HOME'] + '/.my_notebookrc'
notebookapp.initialize()
notebookapp.kernel_manager.kernel_manager_factory = CustomKernelManager
notebookapp.start()

----------------------------------------------------------------------------------

Thanks!
--Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131030/62fe4770/attachment.html>

From pi at berkeley.edu  Thu Oct 31 00:11:09 2013
From: pi at berkeley.edu (Paul Ivanov)
Date: Wed, 30 Oct 2013 21:11:09 -0700
Subject: [IPython-dev] How to preconfigure notebook environment in v1.1?
In-Reply-To: <CADh3F_Urqt491PbgpACthrqU4chvus269p3k7hJu2q211xRCQw@mail.gmail.com>
References: <CADh3F_Urqt491PbgpACthrqU4chvus269p3k7hJu2q211xRCQw@mail.gmail.com>
Message-ID: <20131031041109.GS12247@HbI-OTOH.berkeley.edu>

Adam Sadovsky, on 2013-10-30 20:28,  wrote:
> I recently upgraded from IPython 0.13 to 1.1.
> In 0.13, I was able to execute code in each notebook at startup, but the
> kernel code has changed and I can't figure out how to do it anymore. Could
> someone point me in the right direction?

Hi Adam,

why not just use a file in the startup directory?

$ echo `ipython locate profile`/startup/
/home/pi/.ipython/profile_default/startup/
$ cat `ipython locate profile`/startup/README
This is the IPython startup directory

.py and .ipy files in this directory will be run *prior* to any
code or files specified
via the exec_lines or exec_files configurables whenever you load
this profile.

Files will be run in lexicographical order, so you can control
the execution order of files
with a prefix, e.g.::

  00-first.py
  50-middle.py
  99-last.ipy
  
best,
-- 
                   _
                  / \
                A*   \^   -
             ,./   _.`\\ / \
            / ,--.S    \/   \
           /  `"~,_     \    \
     __o           ?
   _ \<,_         /:\
--(_)/-(_)----.../ | \
--------------.......J
Paul Ivanov
http://pirsquared.org


From fperez.net at gmail.com  Thu Oct 31 00:47:19 2013
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 30 Oct 2013 21:47:19 -0700
Subject: [IPython-dev] Django ORM magic
In-Reply-To: <CAP-GCvmm85ZOF1fx=CyxXsi+1e_V64f23UaDP0kCp50DxMXqrA@mail.gmail.com>
References: <CAP-GCvmm85ZOF1fx=CyxXsi+1e_V64f23UaDP0kCp50DxMXqrA@mail.gmail.com>
Message-ID: <CAHAreOrBvPBaFeNQ5rHXueQKdA-=3SwkfSQEeOh45bPSQVTZBg@mail.gmail.com>

great! Feel free to list it on the extensions index at the wiki:

https://github.com/ipython/ipython/wiki/Extensions-Index

Cheers,

f


On Wed, Oct 30, 2013 at 6:30 AM, Mart?n Gait?n <gaitan at phasety.com> wrote:

> Try to do some data analysis on resultados.gob.ar (the portal with
> official data of the elections in Argentina) [1]  I've done a **fast and
> dirty** cell magic to define django's models dynamically.
>
> https://gist.github.com/mgaitan/7207448
>
> usage example can be seen here:
>
>
> http://nbviewer.ipython.org/7224431#modelando-resultados.gob.ar-en-una-base-de-datos
>
>
> as a short rationale:
>
> It's clear that django is not conceived for this use case, but I love its
> ORM. The problem is that it needs some setup (configure "apps", databases,
> etc. ). This magic handle that, and then import every model.
>
> of course, there are tons of things to improve, but would be great some
> early feedback .
>
> cheers.
> m.
>
>
> [1]  In my province (C?rdoba) there was an "affair" with the last
> congressman seat, due the difference is very short (<0.06%) and some people
> found not computed votes in the telegrams (particularly, for the Left Union
> Party). I'm hacking a bit trying to find more "suspicious" cases:
> http://nbviewer.ipython.org/7224431
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>


-- 
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131030/a6848b37/attachment.html>

From asadovsky at gmail.com  Thu Oct 31 01:32:52 2013
From: asadovsky at gmail.com (Adam Sadovsky)
Date: Wed, 30 Oct 2013 22:32:52 -0700
Subject: [IPython-dev] How to preconfigure notebook environment in v1.1?
In-Reply-To: <20131031041109.GS12247@HbI-OTOH.berkeley.edu>
References: <CADh3F_Urqt491PbgpACthrqU4chvus269p3k7hJu2q211xRCQw@mail.gmail.com>
	<20131031041109.GS12247@HbI-OTOH.berkeley.edu>
Message-ID: <CADh3F_US-YKZR4eeD4LQ9s-KsxbP756OhUz9mH1AWLTp2cRFCw@mail.gmail.com>

Hi Paul,

Thanks for the reply! The reason I'd like to avoid startup files is that
I'm trying to provide a library for others to use. As part of this library,
I want it to be possible for people to start a notebook server where any
new notebook has a certain set of things pre-imported for convenience. I
suppose I could provide a startup file for users to place in their own
startup dirs, but I'd like to avoid making users do any extra work. Ideally
I'd like an option similar to what's offered in the interactive shell API,
which allows users to pass in a user_ns object. Does that make sense?

I should say, I'm relatively new to IPython/notebook and not very familiar
with its architecture, so I certainly may be missing something obvious. :)


--Adam


On Wed, Oct 30, 2013 at 9:11 PM, Paul Ivanov <pi at berkeley.edu> wrote:

> Adam Sadovsky, on 2013-10-30 20:28,  wrote:
> > I recently upgraded from IPython 0.13 to 1.1.
> > In 0.13, I was able to execute code in each notebook at startup, but the
> > kernel code has changed and I can't figure out how to do it anymore.
> Could
> > someone point me in the right direction?
>
> Hi Adam,
>
> why not just use a file in the startup directory?
>
> $ echo `ipython locate profile`/startup/
> /home/pi/.ipython/profile_default/startup/
> $ cat `ipython locate profile`/startup/README
> This is the IPython startup directory
>
> .py and .ipy files in this directory will be run *prior* to any
> code or files specified
> via the exec_lines or exec_files configurables whenever you load
> this profile.
>
> Files will be run in lexicographical order, so you can control
> the execution order of files
> with a prefix, e.g.::
>
>   00-first.py
>   50-middle.py
>   99-last.ipy
>
> best,
> --
>                    _
>                   / \
>                 A*   \^   -
>              ,./   _.`\\ / \
>             / ,--.S    \/   \
>            /  `"~,_     \    \
>      __o           ?
>    _ \<,_         /:\
> --(_)/-(_)----.../ | \
> --------------.......J
> Paul Ivanov
> http://pirsquared.org
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20131030/24fcbf7c/attachment.html>