From rjtskolasinski at gmail.com Fri Jan 2 12:43:48 2015
From: rjtskolasinski at gmail.com (=?UTF-8?Q?Rafa=C5=82_Skolasi=C5=84ski?=)
Date: Fri, 2 Jan 2015 18:43:48 +0100
Subject: [IPython-dev] Making custom converter/template with nbconvert
In-Reply-To:
References:
<17558727-CFFE-4B0F-87F9-B0C7B5C58799@gmail.com>
Message-ID:
Hi guys,
My converter starts to take the final form. I am now working on handling
used figures in some clever way.
All of them that are generated in notebooks and are in output fields go in
smooth way.
I have some problem with figures that are put inside text in markdowns,
i.ex. as
![some_caption](files/dot.png)
which goes in html into caption
(as a template very similar to basic one).
How can force converter to not skip 'files/' to have src="files/dot.png"?
Probably it lies somewhere in template but I couldn't localize it.
Cheers,
Rafa?
2014-12-19 17:57 GMT+01:00 Rafa? Skolasi?ski :
> Ok. I found it.
> Now the corresponding line should be
> exportHtml =
> HTMLExporter(config=Config({'HTMLExporter':{'template_file':'basic'}}))
> instead of
> exportHtml =
> HTMLExporter(config=Config({'HTMLExporter':{'default_template':'basic'}}))
>
>
> 2014-12-19 17:12 GMT+01:00 Rafa? Skolasi?ski :
>>
>> Hi guys,
>>
>> I got some kind of working version. It almost do what I want from it (at
>> least for first working version).
>> http://pastebin.com/bi0003LS
>>
>> Of course later there will come more functionality and polishing.
>>
>> Although I got strange problem. It looks like my converter ignores fact I
>> ask it for using 'basic' template.
>>
>> Does the syntax for it changed? I was basing on this old tutorial:
>>
>> http://nbviewer.ipython.org/github/ipython/ipython-in-depth/blob/master/examples/Notebook/Using%20nbconvert%20as%20a%20Library.ipynb
>>
>> Best,
>> Rafal
>>
>> 2014-12-18 22:38 GMT+01:00 Rafa? Skolasi?ski :
>>>
>>> I will ; - )
>>>
>>> 2014-12-18 22:36 GMT+01:00 Fernando Perez :
>>>
>>>>
>>>> On Thu, Dec 18, 2014 at 9:06 AM, Rafa? Skolasi?ski <
>>>> rjtskolasinski at gmail.com> wrote:
>>>>>
>>>>> I will let you know if I will encounter any problems.
>>>>
>>>>
>>>> And please post here on the list once you have something up and
>>>> running. It's very important for the project to show how others use it not
>>>> only as an interactive environment, but also as infrastructure to build
>>>> upon. That's the kind of clear value that helps us secure resources to
>>>> sustain its development.
>>>>
>>>> Best
>>>>
>>>> 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:
From dsdale24 at gmail.com Sat Jan 3 10:45:41 2015
From: dsdale24 at gmail.com (Darren Dale)
Date: Sat, 03 Jan 2015 15:45:41 +0000
Subject: [IPython-dev] embedding ipython, namespace question
References:
Message-ID:
Hi Ray,
On Sat Dec 27 2014 at 8:48:20 PM Osborn, Raymond wrote:
> I don?t really understand what you are trying to achieve, but the
> ?user_ns? dictionary isn?t an isolated namespace - it?s the namespace that
> is used by the console, and I would have thought you would have to do some
> kind of injection to add other objects from within the application.
>
What I am trying to achieve is explicitly documented at
http://ipython.org/ipython-doc/dev/interactive/reference.html#embedding-ipython
:
---
It is also possible to embed an IPython shell in a namespace in your
Python code. This allows you to evaluate dynamically the state of your
code, operate with your variables, analyze them, etc. Note however that any
changes you make to values while in the shell do not propagate back to the
running code, so it is safe to modify your values because you won?t break
your code in bizarre ways by doing so.
Note
At present, embedding IPython cannot be done from inside IPython. Run the
code samples below outside IPython.
[DD: I am not attempting to embed ipython from inside ipython]
This feature allows you to easily have a fully functional python
environment for doing object introspection anywhere in your code with a
simple function call. In some cases a simple print statement is enough, but
if you need to do more detailed analysis of a code fragment this feature
can be very valuable.
It can also be useful in scientific computing situations where it is common
to need to do some automatic, computationally intensive part and then stop
to look at data, plots, etc. Opening an IPython instance will give you full
access to your data and functions, and you can resume program execution
once you are done with the interactive part (perhaps to stop again later,
as many times as needed).
The following code snippet is the bare minimum you need to include in your
Python programs for this to work (detailed examples follow later):
from IPython import embed
embed() # this call anywhere in your program will start IPython
You can also embed an IPython kernel, for use with qtconsole, etc. via
IPython.embed_kernel(). This should function work the same way, but you can
connect an external frontend (ipython qtconsole or ipython console), rather
than interacting with it in the terminal.
---
This is impressively simple for the embed function:
---
C:\Users\darren> python
Python 2.7.8 |Continuum Analytics, Inc.| (default, Jul 2 2014, 15:12:11)
[MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
Anaconda is brought to you by Continuum Analytics.
Please check out: http://continuum.io/thanks and https://binstar.org
>>> from IPython import embed
>>> a=1
>>> embed()
Python 2.7.8 |Continuum Analytics, Inc.| (default, Jul 2 2014, 15:12:11)
[MSC v.1500 64 bit (AMD64)]
Type "copyright", "credits" or "license" for more information.
IPython 2.3.1 -- An enhanced Interactive Python.
Anaconda is brought to you by Continuum Analytics.
Please check out: http://continuum.io/thanks and https://binstar.org
? -> 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
Out[1]: 1
---
But I have not been able to achieve the same behavior with the qt
in-process console.
Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ra092767 at ime.unicamp.br Sat Jan 3 21:27:02 2015
From: ra092767 at ime.unicamp.br (Raniere Silva)
Date: Sun, 4 Jan 2015 00:27:02 -0200
Subject: [IPython-dev] Making custom converter/template with nbconvert
In-Reply-To:
References:
<17558727-CFFE-4B0F-87F9-B0C7B5C58799@gmail.com>
Message-ID: <20150104022702.GM1209@buriti.rgaiacs.com>
Hi Rafa?,
> I have some problem with figures that are put inside text in markdowns,
> i.ex. as
> ![some_caption](files/dot.png)
> which goes in html into class="caption">caption
> (as a template very similar to basic one).
>
> How can force converter to not skip 'files/' to have src="files/dot.png"?
> Probably it lies somewhere in template but I couldn't localize it.
I couldn't reproduce your problem.
$ cat sample.ipynb
{
"cells": [
{
"cell_type": "markdown",
"metadata": {},
"source": [
"![foo](folder/bar.jpg)"
]
},
{
"cell_type": "code",
"execution_count": null,
"metadata": {
"collapsed": true
},
"outputs": [],
"source": []
}
],
"metadata": {
"kernelspec": {
"display_name": "IPython (Python 3)",
"name": "python3"
},
"language_info": {
"codemirror_mode": {
"name": "ipython",
"version": 3
},
"file_extension": ".py",
"mimetype": "text/x-python",
"name": "python",
"nbconvert_exporter": "python",
"pygments_lexer": "ipython3"
},
"signature": "sha256:5c8cb31d4083cbf815d3e1dff7a3cc229fa54b9c02cff82af4548cef72581573"
},
"nbformat": 4,
"nbformat_minor": 0
}
$ ipython nbconvert --to html sample.ipynb
[NbConvertApp] Using existing profile dir: '/home/raniere/.ipython/profile_default'
[NbConvertApp] Converting notebook sample.ipynb to html
[NbConvertApp] Support files will be in sample_files/
[NbConvertApp] Loaded template full.tpl
[NbConvertApp] Writing 223380 bytes to sample.html
$ grep '
What version of IPython/Jupyter are you using? I tested with
$ ipython --version
3.0.0-dev
Cheers,
Raniere
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
From fperez.net at gmail.com Sat Jan 3 22:29:50 2015
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 3 Jan 2015 19:29:50 -0800
Subject: [IPython-dev] Welcoming Kyle Kelley and Nick Bollweg to the core
Jupyter/IPython team
Message-ID:
We'd like to welcome Kyle Kelley and Nick Bollweg to the core development
team. In Kyle's case this is a long-overdue announcement, as Kyle has been
a core dev for quite a while now, we just hadn't been very good about
communicating that on-list. Kyle, thanks to Racksspace's generous support
for the project,
Trying to redress that lack of communication, in Nick's case we're not
waiting :) Nick has been making great contributions to nbviewer, widgets,
and overall discussions in the project, and accepted to be a core developer
moving forward, as his other obligations allow.
Welcome (if belatedly) to both!
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:
From rjtskolasinski at gmail.com Sun Jan 4 08:19:01 2015
From: rjtskolasinski at gmail.com (=?UTF-8?Q?Rafa=C5=82_Skolasi=C5=84ski?=)
Date: Sun, 4 Jan 2015 14:19:01 +0100
Subject: [IPython-dev] Making custom converter/template with nbconvert
In-Reply-To: <20150104022702.GM1209@buriti.rgaiacs.com>
References:
<17558727-CFFE-4B0F-87F9-B0C7B5C58799@gmail.com>
<20150104022702.GM1209@buriti.rgaiacs.com>
Message-ID:
Hi Raniere,
The problem occurred when folder was named 'files'. When I renamed it to
'figures' it behaves as in your example. I must say that this very weird
behavior but there must be some reason for that probably.
Cheers,
Rafa?
2015-01-04 3:27 GMT+01:00 Raniere Silva :
> Hi Rafa?,
>
> > I have some problem with figures that are put inside text in markdowns,
> > i.ex. as
> > ![some_caption](files/dot.png)
> > which goes in html into > class="caption">caption
> > (as a template very similar to basic one).
> >
> > How can force converter to not skip 'files/' to have src="files/dot.png"?
> > Probably it lies somewhere in template but I couldn't localize it.
>
> I couldn't reproduce your problem.
>
> $ cat sample.ipynb
> {
> "cells": [
> {
> "cell_type": "markdown",
> "metadata": {},
> "source": [
> "![foo](folder/bar.jpg)"
> ]
> },
> {
> "cell_type": "code",
> "execution_count": null,
> "metadata": {
> "collapsed": true
> },
> "outputs": [],
> "source": []
> }
> ],
> "metadata": {
> "kernelspec": {
> "display_name": "IPython (Python 3)",
> "name": "python3"
> },
> "language_info": {
> "codemirror_mode": {
> "name": "ipython",
> "version": 3
> },
> "file_extension": ".py",
> "mimetype": "text/x-python",
> "name": "python",
> "nbconvert_exporter": "python",
> "pygments_lexer": "ipython3"
> },
> "signature":
> "sha256:5c8cb31d4083cbf815d3e1dff7a3cc229fa54b9c02cff82af4548cef72581573"
> },
> "nbformat": 4,
> "nbformat_minor": 0
> }
> $ ipython nbconvert --to html sample.ipynb
> [NbConvertApp] Using existing profile dir:
> '/home/raniere/.ipython/profile_default'
> [NbConvertApp] Converting notebook sample.ipynb to html
> [NbConvertApp] Support files will be in sample_files/
> [NbConvertApp] Loaded template full.tpl
> [NbConvertApp] Writing 223380 bytes to sample.html
> $ grep '
>
> What version of IPython/Jupyter are you using? I tested with
>
> $ ipython --version
> 3.0.0-dev
>
> Cheers,
> Raniere
>
> _______________________________________________
> 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:
From schueller at phimeca.com Sun Jan 4 12:31:00 2015
From: schueller at phimeca.com (Julien Schueller)
Date: Sun, 4 Jan 2015 18:31:00 +0100 (CET)
Subject: [IPython-dev] graph displayed twice while overloading _repr_svg_
for notebook
In-Reply-To: <2107085751.5438082.1418729306654.JavaMail.zimbra@phimeca.com>
References: <2107085751.5438082.1418729306654.JavaMail.zimbra@phimeca.com>
Message-ID: <1095968995.59454.1420392660687.JavaMail.zimbra@phimeca.com>
Hello,
I'm having trouble overloading _repr_svg_ for graph inlining in the notebook; my object is displayed twice if I call plt.plot just before.
I assumed a figure was left open or something, but even if I call plt.close('all') between the matplotlib calls, the result remains the same.
I did some imports first:
import numpy as np
import matplotlib.pyplot as plt
import matplotlib
from scipy.stats import norm
import sys
import io
print('matplotlib version %s' % matplotlib.__version__)
import IPython
print('IPython version %s' % IPython.__version__)
Here'my object:
class NormGraph(object):
def __init__(self):
super(NormGraph, self).__init__()
def _repr_svg_(self):
if sys.version_info[0] >= 3:
output = io.StringIO()
else:
output = io.BytesIO()
self._fig = plt.figure()
axes_kwargs = {}
plot_kwargs = {}
self._ax = [self._fig.add_subplot(111, **axes_kwargs)]
x = np.arange(-10, 10, 0.001)
y = norm.pdf(x,0,2)
self._ax[0].plot(x, y, **plot_kwargs)
self._fig.savefig(output, format='svg')
return output.getvalue()
Then a basic call to pyplot:
%matplotlib inline
plt.plot(0, 1)
Then if I try to inline my object it's displayed twice:
NormGraph()
I atached the complete notebook.
--
Julien Schueller
Phimeca Engineering
www.phimeca.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Untitled0.ipynb
Type: application/octet-stream
Size: 40341 bytes
Desc: not available
URL:
From ssanderson at quantopian.com Sun Jan 4 13:01:24 2015
From: ssanderson at quantopian.com (ssanderson)
Date: Sun, 4 Jan 2015 10:01:24 -0800 (PST)
Subject: [IPython-dev] Welcoming Kyle Kelley and Nick Bollweg to the
core Jupyter/IPython team
In-Reply-To:
References:
Message-ID: <1420394484530-5082155.post@n6.nabble.com>
Congrats!
--
View this message in context: http://python.6.x6.nabble.com/Welcoming-Kyle-Kelley-and-Nick-Bollweg-to-the-core-Jupyter-IPython-team-tp5082131p5082155.html
Sent from the IPython - Development mailing list archive at Nabble.com.
From takowl at gmail.com Mon Jan 5 12:43:57 2015
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 5 Jan 2015 17:43:57 +0000
Subject: [IPython-dev] graph displayed twice while overloading
_repr_svg_ for notebook
In-Reply-To: <1095968995.59454.1420392660687.JavaMail.zimbra@phimeca.com>
References: <2107085751.5438082.1418729306654.JavaMail.zimbra@phimeca.com>
<1095968995.59454.1420392660687.JavaMail.zimbra@phimeca.com>
Message-ID:
If you've done '%matplotlib inline' previously, when you create a figure
inside a cell, it will automatically be displayed at the end of that cell,
separately from the regular repr system. So your _repr_svg_ method is
getting called once, and the figure you create in that is being displayed
again. I'm not sure what the best way to deal with that is.
Thomas
On 4 January 2015 at 17:31, Julien Schueller wrote:
>
>
>
> Hello,
>
> I'm having trouble overloading _repr_svg_ for graph inlining in the
> notebook; my object is displayed twice if I call plt.plot just before.
> I assumed a figure was left open or something, but even if I call
> plt.close('all') between the matplotlib calls, the result remains the same.
>
> I did some imports first:
> import numpy as np
> import matplotlib.pyplot as plt
> import matplotlib
> from scipy.stats import norm
> import sys
> import io
> print('matplotlib version %s' % matplotlib.__version__)
> import IPython
> print('IPython version %s' % IPython.__version__)
>
>
> Here'my object:
> class NormGraph(object):
> def __init__(self):
> super(NormGraph, self).__init__()
> def _repr_svg_(self):
> if sys.version_info[0] >= 3:
> output = io.StringIO()
> else:
> output = io.BytesIO()
> self._fig = plt.figure()
> axes_kwargs = {}
> plot_kwargs = {}
> self._ax = [self._fig.add_subplot(111, **axes_kwargs)]
> x = np.arange(-10, 10, 0.001)
> y = norm.pdf(x,0,2)
> self._ax[0].plot(x, y, **plot_kwargs)
> self._fig.savefig(output, format='svg')
>
> return output.getvalue()
>
>
> Then a basic call to pyplot:
> %matplotlib inline
> plt.plot(0, 1)
>
> Then if I try to inline my object it's displayed twice:
> NormGraph()
>
> I atached the complete notebook.
>
> --
> Julien Schueller
> Phimeca Engineering
> www.phimeca.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:
From tritemio at gmail.com Mon Jan 5 14:06:50 2015
From: tritemio at gmail.com (Antonino Ingargiola)
Date: Mon, 5 Jan 2015 11:06:50 -0800
Subject: [IPython-dev] graph displayed twice while overloading
_repr_svg_ for notebook
In-Reply-To:
References: <2107085751.5438082.1418729306654.JavaMail.zimbra@phimeca.com>
<1095968995.59454.1420392660687.JavaMail.zimbra@phimeca.com>
Message-ID:
Hi,
I don't know if it helps but with plain matplotlib you can close the figure
and call display(fig) on the closed figure. I use this trick to plot
several figures in a loop (closing them at each iteration) or for updating
plots via widgets.
Antonio
On Mon, Jan 5, 2015 at 9:43 AM, Thomas Kluyver wrote:
> If you've done '%matplotlib inline' previously, when you create a figure
> inside a cell, it will automatically be displayed at the end of that cell,
> separately from the regular repr system. So your _repr_svg_ method is
> getting called once, and the figure you create in that is being displayed
> again. I'm not sure what the best way to deal with that is.
>
> Thomas
>
> On 4 January 2015 at 17:31, Julien Schueller
> wrote:
>
>>
>>
>>
>> Hello,
>>
>> I'm having trouble overloading _repr_svg_ for graph inlining in the
>> notebook; my object is displayed twice if I call plt.plot just before.
>> I assumed a figure was left open or something, but even if I call
>> plt.close('all') between the matplotlib calls, the result remains the same.
>>
>> I did some imports first:
>> import numpy as np
>> import matplotlib.pyplot as plt
>> import matplotlib
>> from scipy.stats import norm
>> import sys
>> import io
>> print('matplotlib version %s' % matplotlib.__version__)
>> import IPython
>> print('IPython version %s' % IPython.__version__)
>>
>>
>> Here'my object:
>> class NormGraph(object):
>> def __init__(self):
>> super(NormGraph, self).__init__()
>> def _repr_svg_(self):
>> if sys.version_info[0] >= 3:
>> output = io.StringIO()
>> else:
>> output = io.BytesIO()
>> self._fig = plt.figure()
>> axes_kwargs = {}
>> plot_kwargs = {}
>> self._ax = [self._fig.add_subplot(111, **axes_kwargs)]
>> x = np.arange(-10, 10, 0.001)
>> y = norm.pdf(x,0,2)
>> self._ax[0].plot(x, y, **plot_kwargs)
>> self._fig.savefig(output, format='svg')
>>
>> return output.getvalue()
>>
>>
>> Then a basic call to pyplot:
>> %matplotlib inline
>> plt.plot(0, 1)
>>
>> Then if I try to inline my object it's displayed twice:
>> NormGraph()
>>
>> I atached the complete notebook.
>>
>> --
>> Julien Schueller
>> Phimeca Engineering
>> www.phimeca.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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From darcamo at gmail.com Mon Jan 5 14:14:56 2015
From: darcamo at gmail.com (darcamo at gmail.com)
Date: Mon, 05 Jan 2015 19:14:56 +0000
Subject: [IPython-dev] graph displayed twice while overloading
_repr_svg_ for notebook
References: <2107085751.5438082.1418729306654.JavaMail.zimbra@phimeca.com>
<1095968995.59454.1420392660687.JavaMail.zimbra@phimeca.com>
Message-ID:
Call plt.close(self._fig) after savefig and the inline plot should not be
shown. Since you are using the figure only to convert to svg with savefig
and you need to close it to avoid the inline plot, then there is no reason
to keep it as an instance attribute.
It might also be a good idea to disable matplotlib interactive mode by
calling plt.ioff() before creating the figure object and reenabling it
after the figure is closed by calling plt.ion().
--
Darlan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ellisonbg at gmail.com Mon Jan 5 17:01:53 2015
From: ellisonbg at gmail.com (Brian Granger)
Date: Mon, 5 Jan 2015 14:01:53 -0800
Subject: [IPython-dev] Welcoming Kyle Kelley and Nick Bollweg to the
core Jupyter/IPython team
In-Reply-To: <1420394484530-5082155.post@n6.nabble.com>
References:
<1420394484530-5082155.post@n6.nabble.com>
Message-ID:
Thanks so much for your work Kyle and Nick!
Cheers,
Brian
On Sun, Jan 4, 2015 at 10:01 AM, ssanderson
wrote:
> Congrats!
>
>
>
> --
> View this message in context:
> http://python.6.x6.nabble.com/Welcoming-Kyle-Kelley-and-Nick-Bollweg-to-the-core-Jupyter-IPython-team-tp5082131p5082155.html
> Sent from the IPython - Development mailing list archive at Nabble.com.
> _______________________________________________
> 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
@ellisonbg on Twitter and GitHub
bgranger at calpoly.edu and ellisonbg at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From schueller at phimeca.com Tue Jan 6 04:20:52 2015
From: schueller at phimeca.com (Julien Schueller)
Date: Tue, 6 Jan 2015 10:20:52 +0100 (CET)
Subject: [IPython-dev] graph displayed twice while overloading
_repr_svg_ for notebook
In-Reply-To:
References: <2107085751.5438082.1418729306654.JavaMail.zimbra@phimeca.com>
<1095968995.59454.1420392660687.JavaMail.zimbra@phimeca.com>
Message-ID: <1463575469.219037.1420536052858.JavaMail.zimbra@phimeca.com>
----- Mail original -----
> De: darcamo at gmail.com
> ?: "IPython developers list"
> Envoy?: Lundi 5 Janvier 2015 20:14:56
> Objet: Re: [IPython-dev] graph displayed twice while overloading _repr_svg_ for notebook
>
> Call plt.close(self._fig) after savefig and the inline plot should not be
> shown. Since you are using the figure only to convert to svg with savefig
> and you need to close it to avoid the inline plot, then there is no reason
> to keep it as an instance attribute.
>
> It might also be a good idea to disable matplotlib interactive mode by
> calling plt.ioff() before creating the figure object and reenabling it after
> the figure is closed by calling plt.ion().
>
> --
> Darlan
>
That was it, thanks!
From ellisonbg at gmail.com Tue Jan 6 13:53:06 2015
From: ellisonbg at gmail.com (Brian Granger)
Date: Tue, 6 Jan 2015 10:53:06 -0800
Subject: [IPython-dev] Change in weekly dev meeting times
Message-ID:
Hi all!
In the past we have had two weekly dev meetings:
* Tuesday 9:30-11am PST = special topics as needed
* Thursday 9:30-11am PST = general topics, always happens
Because of some scheduling conflicts, we are going to swap those starting
this week:
* Tuesday 9:30-11am PST = general topics, always happens
* Thursday 9:30-11am PST = special topics as needed
Thus, this Th, we will not have a regular, general meeting. We may have a
special topics meeting if needed, but we aren't sure yet. Out next general
meeting will be next Tuesday 9:30am PST.
Se you all soon!
Cheers,
Brian
--
Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger at calpoly.edu and ellisonbg at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From benjaminrk at gmail.com Thu Jan 8 13:04:10 2015
From: benjaminrk at gmail.com (MinRK)
Date: Thu, 8 Jan 2015 10:04:10 -0800
Subject: [IPython-dev] Notebook websocket change
Message-ID:
Alternative notebook frontend authors:
There is an upcoming change
to websocket connections to the notebook server. Instead of three
websockets per notebook, one for each zmq channel, there is a single
websocket connection between the server and client. The channel associated
with each message is identified by a channel key in the message dict itself.
Relevant changes:
- url is /channels instead of /shell, etc.
- when sending a message, add a channel key with the channel name ('shell',
'stdin')
- when receiving a message, check the channel key for routing
-MinRK
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From wstein at gmail.com Thu Jan 8 13:10:10 2015
From: wstein at gmail.com (William Stein)
Date: Thu, 8 Jan 2015 10:10:10 -0800
Subject: [IPython-dev] Notebook websocket change
In-Reply-To:
References:
Message-ID:
On Thu, Jan 8, 2015 at 10:04 AM, MinRK wrote:
> Alternative notebook frontend authors:
>
> There is an upcoming change to websocket connections to the notebook server.
> Instead of three websockets per notebook, one for each zmq channel, there is
> a single websocket connection between the server and client. The channel
> associated with each message is identified by a channel key in the message
> dict itself.
>
> Relevant changes:
>
> url is /channels instead of /shell, etc.
> when sending a message, add a channel key with the channel name ('shell',
> 'stdin')
> when receiving a message, check the channel key for routing
>
> -MinRK
Thanks.
Of related interest, what the situation involving providing a fallback
to websockets?
I tried to only support websockets connections with SageMathCloud for
a few weeks, and immediately ran into many complaints from users who
couldn't connect as a result. This is even with https and so on --
it's just a sad fact that in some corporate or otherwise constrained
environments that websockets don't work. By far the best approach I
found was to use Primus + Engine.io, which uses websockets if
possible, but will fallback to polling. So this is what SMC does
now, and everything works, even for people that don't have websockets
as an option... except for IPython-in-SMC of course, which doesn't
work.
Another unrelated issue is that I'm now hardcoding making this change
around line 171 of IPython/html/notebookapp.py, since I want to serve
the purely static html of IPython from a completely different web
server:
#static_url_prefix = url_path_join(base_url,'/static/'),
static_url_prefix = '/static/ipython/',
(Sorry for derailing the thread.)
-- William
>
>
> _______________________________________________
> 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 ellisonbg at gmail.com Thu Jan 8 13:19:19 2015
From: ellisonbg at gmail.com (Brian Granger)
Date: Thu, 8 Jan 2015 10:19:19 -0800
Subject: [IPython-dev] Notebook websocket change
In-Reply-To:
References:
Message-ID:
So far we have felt that it isn't worth the complexity cost for us to
support people that deliberately choose to break the internet. It is not
like WebSockets is some crazy, insecure, unsupported hack over a weird
port. It is just different bytes going over the same HTTP/HTTPS socket
connection and is essentially a formal standard (I know you know this -
this is our messaging to companies who complain).
Our situation is a bit different though than SMC because most of our
current users run the notebook on their own computers. This may be
something that we eventually want to rethink as more people run this in the
cloud. However, I would like to push back on the companies choosing to
break the internet really hard before giving in. I am guessing that in most
cases, WebSockets are broken in enterprise setting not because of some
important deliberate choice, but rather because people don't understand it
and are using default settings that disable them (I could be wrong
though)....
Cheers,
Brian
On Thu, Jan 8, 2015 at 10:10 AM, William Stein wrote:
> On Thu, Jan 8, 2015 at 10:04 AM, MinRK wrote:
> > Alternative notebook frontend authors:
> >
> > There is an upcoming change to websocket connections to the notebook
> server.
> > Instead of three websockets per notebook, one for each zmq channel,
> there is
> > a single websocket connection between the server and client. The channel
> > associated with each message is identified by a channel key in the
> message
> > dict itself.
> >
> > Relevant changes:
> >
> > url is /channels instead of /shell, etc.
> > when sending a message, add a channel key with the channel name ('shell',
> > 'stdin')
> > when receiving a message, check the channel key for routing
> >
> > -MinRK
>
> Thanks.
>
> Of related interest, what the situation involving providing a fallback
> to websockets?
>
> I tried to only support websockets connections with SageMathCloud for
> a few weeks, and immediately ran into many complaints from users who
> couldn't connect as a result. This is even with https and so on --
> it's just a sad fact that in some corporate or otherwise constrained
> environments that websockets don't work. By far the best approach I
> found was to use Primus + Engine.io, which uses websockets if
> possible, but will fallback to polling. So this is what SMC does
> now, and everything works, even for people that don't have websockets
> as an option... except for IPython-in-SMC of course, which doesn't
> work.
>
> Another unrelated issue is that I'm now hardcoding making this change
> around line 171 of IPython/html/notebookapp.py, since I want to serve
> the purely static html of IPython from a completely different web
> server:
>
> #static_url_prefix = url_path_join(base_url,'/static/'),
> static_url_prefix = '/static/ipython/',
>
> (Sorry for derailing the thread.)
>
> -- William
>
> >
> >
> > _______________________________________________
> > 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
@ellisonbg on Twitter and GitHub
bgranger at calpoly.edu and ellisonbg at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From wstein at gmail.com Thu Jan 8 13:55:53 2015
From: wstein at gmail.com (William Stein)
Date: Thu, 8 Jan 2015 10:55:53 -0800
Subject: [IPython-dev] Notebook websocket change
In-Reply-To:
References:
Message-ID:
On Thu, Jan 8, 2015 at 10:19 AM, Brian Granger wrote:
> So far we have felt that it isn't worth the complexity cost for us to
> support people that deliberately choose to break the internet. It is not
> like WebSockets is some crazy, insecure, unsupported hack over a weird port.
> It is just different bytes going over the same HTTP/HTTPS socket connection
> and is essentially a formal standard (I know you know this - this is our
> messaging to companies who complain).
I know -- that's why I switched SMC to pure websockets for a while.
Then I received complaints at a rate of about 2 very desperate users
per week, and these were the people who cared enough to complain
repeatedly.
> Our situation is a bit different though than SMC because most of our current
> users run the notebook on their own computers. This may be something that we
> eventually want to rethink as more people run this in the cloud. However, I
> would like to push back on the companies choosing to break the internet
> really hard before giving in. I am guessing that in most cases, WebSockets
> are broken in enterprise setting not because of some important deliberate
> choice, but rather because people don't understand it and are using default
> settings that disable them (I could be wrong though)....
In my experience, for some people that's exactly the problem. For one
person I helped it turned out their specific problem was the Windows
install they had access to had websockets explicitly disabled --
perhaps that was an IT policy. For other people the problem is
further along the stack (e.g., possibly involving caching).
Anyway, this change so that "there is a single websocket connection
between the server and client. " makes implementing an alternative to
WebSocket as a fallback dramatically easier, which I greatly
appreciate.
> Our situation is a bit different though than SMC because most of our current
> users run the notebook on their own computers. This may be something that we
Just curious -- how do you know that most people using IPython aren't
already using it through SMC?
William
>
> Cheers,
>
> Brian
>
>
>
> On Thu, Jan 8, 2015 at 10:10 AM, William Stein wrote:
>>
>> On Thu, Jan 8, 2015 at 10:04 AM, MinRK wrote:
>> > Alternative notebook frontend authors:
>> >
>> > There is an upcoming change to websocket connections to the notebook
>> > server.
>> > Instead of three websockets per notebook, one for each zmq channel,
>> > there is
>> > a single websocket connection between the server and client. The channel
>> > associated with each message is identified by a channel key in the
>> > message
>> > dict itself.
>> >
>> > Relevant changes:
>> >
>> > url is /channels instead of /shell, etc.
>> > when sending a message, add a channel key with the channel name
>> > ('shell',
>> > 'stdin')
>> > when receiving a message, check the channel key for routing
>> >
>> > -MinRK
>>
>> Thanks.
>>
>> Of related interest, what the situation involving providing a fallback
>> to websockets?
>>
>> I tried to only support websockets connections with SageMathCloud for
>> a few weeks, and immediately ran into many complaints from users who
>> couldn't connect as a result. This is even with https and so on --
>> it's just a sad fact that in some corporate or otherwise constrained
>> environments that websockets don't work. By far the best approach I
>> found was to use Primus + Engine.io, which uses websockets if
>> possible, but will fallback to polling. So this is what SMC does
>> now, and everything works, even for people that don't have websockets
>> as an option... except for IPython-in-SMC of course, which doesn't
>> work.
>>
>> Another unrelated issue is that I'm now hardcoding making this change
>> around line 171 of IPython/html/notebookapp.py, since I want to serve
>> the purely static html of IPython from a completely different web
>> server:
>>
>> #static_url_prefix = url_path_join(base_url,'/static/'),
>> static_url_prefix = '/static/ipython/',
>>
>> (Sorry for derailing the thread.)
>>
>> -- William
>>
>> >
>> >
>> > _______________________________________________
>> > 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
> @ellisonbg on Twitter and GitHub
> 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 Thu Jan 8 14:18:43 2015
From: benjaminrk at gmail.com (MinRK)
Date: Thu, 8 Jan 2015 11:18:43 -0800
Subject: [IPython-dev] Notebook websocket change
In-Reply-To:
References:
Message-ID:
Some time ago, I made a PR to IPython switching to socket.io, which
required the same basic changes since it only allowed a single connection
per page, so I know it's not too hard. We may start to see more pressure as
hosted instances, and reconsider the fallback in the future, but at this
point, we don't feel that pressure. Wind proper websockets to be
sufficiently preferable that we will wait as long as we can before
appeasing old, broken, or misconfigured network environments that prevent
websockets from working.
The majority of notebook users seem to be running as a desktop app via
localhost, where websockets are rarely a problem (The nightmare of Sophos
AV/firewall on Windows excluded).
-MinRK
On Thu, Jan 8, 2015 at 10:55 AM, William Stein wrote:
> On Thu, Jan 8, 2015 at 10:19 AM, Brian Granger
> wrote:
> > So far we have felt that it isn't worth the complexity cost for us to
> > support people that deliberately choose to break the internet. It is not
> > like WebSockets is some crazy, insecure, unsupported hack over a weird
> port.
> > It is just different bytes going over the same HTTP/HTTPS socket
> connection
> > and is essentially a formal standard (I know you know this - this is our
> > messaging to companies who complain).
>
> I know -- that's why I switched SMC to pure websockets for a while.
> Then I received complaints at a rate of about 2 very desperate users
> per week, and these were the people who cared enough to complain
> repeatedly.
>
> > Our situation is a bit different though than SMC because most of our
> current
> > users run the notebook on their own computers. This may be something
> that we
> > eventually want to rethink as more people run this in the cloud.
> However, I
> > would like to push back on the companies choosing to break the internet
> > really hard before giving in. I am guessing that in most cases,
> WebSockets
> > are broken in enterprise setting not because of some important deliberate
> > choice, but rather because people don't understand it and are using
> default
> > settings that disable them (I could be wrong though)....
>
> In my experience, for some people that's exactly the problem. For one
> person I helped it turned out their specific problem was the Windows
> install they had access to had websockets explicitly disabled --
> perhaps that was an IT policy. For other people the problem is
> further along the stack (e.g., possibly involving caching).
>
> Anyway, this change so that "there is a single websocket connection
> between the server and client. " makes implementing an alternative to
> WebSocket as a fallback dramatically easier, which I greatly
> appreciate.
>
> > Our situation is a bit different though than SMC because most of our
> current
> > users run the notebook on their own computers. This may be something
> that we
>
> Just curious -- how do you know that most people using IPython aren't
> already using it through SMC?
>
> William
>
> >
> > Cheers,
> >
> > Brian
> >
> >
> >
> > On Thu, Jan 8, 2015 at 10:10 AM, William Stein wrote:
> >>
> >> On Thu, Jan 8, 2015 at 10:04 AM, MinRK wrote:
> >> > Alternative notebook frontend authors:
> >> >
> >> > There is an upcoming change to websocket connections to the notebook
> >> > server.
> >> > Instead of three websockets per notebook, one for each zmq channel,
> >> > there is
> >> > a single websocket connection between the server and client. The
> channel
> >> > associated with each message is identified by a channel key in the
> >> > message
> >> > dict itself.
> >> >
> >> > Relevant changes:
> >> >
> >> > url is /channels instead of /shell, etc.
> >> > when sending a message, add a channel key with the channel name
> >> > ('shell',
> >> > 'stdin')
> >> > when receiving a message, check the channel key for routing
> >> >
> >> > -MinRK
> >>
> >> Thanks.
> >>
> >> Of related interest, what the situation involving providing a fallback
> >> to websockets?
> >>
> >> I tried to only support websockets connections with SageMathCloud for
> >> a few weeks, and immediately ran into many complaints from users who
> >> couldn't connect as a result. This is even with https and so on --
> >> it's just a sad fact that in some corporate or otherwise constrained
> >> environments that websockets don't work. By far the best approach I
> >> found was to use Primus + Engine.io, which uses websockets if
> >> possible, but will fallback to polling. So this is what SMC does
> >> now, and everything works, even for people that don't have websockets
> >> as an option... except for IPython-in-SMC of course, which doesn't
> >> work.
> >>
> >> Another unrelated issue is that I'm now hardcoding making this change
> >> around line 171 of IPython/html/notebookapp.py, since I want to serve
> >> the purely static html of IPython from a completely different web
> >> server:
> >>
> >> #static_url_prefix = url_path_join(base_url,'/static/'),
> >> static_url_prefix = '/static/ipython/',
> >>
> >> (Sorry for derailing the thread.)
> >>
> >> -- William
> >>
> >> >
> >> >
> >> > _______________________________________________
> >> > 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
> > @ellisonbg on Twitter and GitHub
> > 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:
From rgbkrk at gmail.com Thu Jan 8 14:33:52 2015
From: rgbkrk at gmail.com (Kyle Kelley)
Date: Thu, 8 Jan 2015 13:33:52 -0600
Subject: [IPython-dev] Notebook websocket change
In-Reply-To:
References:
Message-ID:
You're right Brian, it's about them buying some
$FIREWALL_IPS_SUPER_PRICEY_DEVICE that doesn't proxy websockets
appropriately and the person purchasing having no clue other than the fact
that $VENDOR gave them a neat trinket at a conference.
Firewalls and proxies that do handle websockets appropriately do exist. I'd
be tempted to make a list of ones that do it well and display them
prominently, if only for the benefit of our own users.
I have witnessed these flavors of IPython in the wild (not including our
own recent stunts):
* Corporate entities using an Anaconda server (websockets not a problem
internally but were externally)
* People of all backgrounds using Anaconda's IPython notebook bundling
* Vanilla installations from package managers or pip
* Hosted instance of their own flavor
* DIT4C
Most users that we hear from are using a local installation and there's
probably a large amount of confirmation bias. It would be great if we had
actual shared metrics between us but we only know:
* Unique viewers/users of the Nature demo (> 14,000 total, according to GA)
* Viewers on the notebook viewer (> 200k per month, also according to GA)
* Downloads on PyPI (skewed, not unique)
* Clones from github (also skewed)
We could actually be tracking who has websocket support of those hitting
the notebook viewer for a bigger sense of potential users (since viewers
are not necessarily IPython/Jupyter users).
On Thu, Jan 8, 2015 at 12:55 PM, William Stein wrote:
> On Thu, Jan 8, 2015 at 10:19 AM, Brian Granger
> wrote:
> > So far we have felt that it isn't worth the complexity cost for us to
> > support people that deliberately choose to break the internet. It is not
> > like WebSockets is some crazy, insecure, unsupported hack over a weird
> port.
> > It is just different bytes going over the same HTTP/HTTPS socket
> connection
> > and is essentially a formal standard (I know you know this - this is our
> > messaging to companies who complain).
>
> I know -- that's why I switched SMC to pure websockets for a while.
> Then I received complaints at a rate of about 2 very desperate users
> per week, and these were the people who cared enough to complain
> repeatedly.
>
> > Our situation is a bit different though than SMC because most of our
> current
> > users run the notebook on their own computers. This may be something
> that we
> > eventually want to rethink as more people run this in the cloud.
> However, I
> > would like to push back on the companies choosing to break the internet
> > really hard before giving in. I am guessing that in most cases,
> WebSockets
> > are broken in enterprise setting not because of some important deliberate
> > choice, but rather because people don't understand it and are using
> default
> > settings that disable them (I could be wrong though)....
>
> In my experience, for some people that's exactly the problem. For one
> person I helped it turned out their specific problem was the Windows
> install they had access to had websockets explicitly disabled --
> perhaps that was an IT policy. For other people the problem is
> further along the stack (e.g., possibly involving caching).
>
> Anyway, this change so that "there is a single websocket connection
> between the server and client. " makes implementing an alternative to
> WebSocket as a fallback dramatically easier, which I greatly
> appreciate.
>
> > Our situation is a bit different though than SMC because most of our
> current
> > users run the notebook on their own computers. This may be something
> that we
>
> Just curious -- how do you know that most people using IPython aren't
> already using it through SMC?
>
> William
>
> >
> > Cheers,
> >
> > Brian
> >
> >
> >
> > On Thu, Jan 8, 2015 at 10:10 AM, William Stein wrote:
> >>
> >> On Thu, Jan 8, 2015 at 10:04 AM, MinRK wrote:
> >> > Alternative notebook frontend authors:
> >> >
> >> > There is an upcoming change to websocket connections to the notebook
> >> > server.
> >> > Instead of three websockets per notebook, one for each zmq channel,
> >> > there is
> >> > a single websocket connection between the server and client. The
> channel
> >> > associated with each message is identified by a channel key in the
> >> > message
> >> > dict itself.
> >> >
> >> > Relevant changes:
> >> >
> >> > url is /channels instead of /shell, etc.
> >> > when sending a message, add a channel key with the channel name
> >> > ('shell',
> >> > 'stdin')
> >> > when receiving a message, check the channel key for routing
> >> >
> >> > -MinRK
> >>
> >> Thanks.
> >>
> >> Of related interest, what the situation involving providing a fallback
> >> to websockets?
> >>
> >> I tried to only support websockets connections with SageMathCloud for
> >> a few weeks, and immediately ran into many complaints from users who
> >> couldn't connect as a result. This is even with https and so on --
> >> it's just a sad fact that in some corporate or otherwise constrained
> >> environments that websockets don't work. By far the best approach I
> >> found was to use Primus + Engine.io, which uses websockets if
> >> possible, but will fallback to polling. So this is what SMC does
> >> now, and everything works, even for people that don't have websockets
> >> as an option... except for IPython-in-SMC of course, which doesn't
> >> work.
> >>
> >> Another unrelated issue is that I'm now hardcoding making this change
> >> around line 171 of IPython/html/notebookapp.py, since I want to serve
> >> the purely static html of IPython from a completely different web
> >> server:
> >>
> >> #static_url_prefix = url_path_join(base_url,'/static/'),
> >> static_url_prefix = '/static/ipython/',
> >>
> >> (Sorry for derailing the thread.)
> >>
> >> -- William
> >>
> >> >
> >> >
> >> > _______________________________________________
> >> > 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
> > @ellisonbg on Twitter and GitHub
> > 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
>
--
Kyle Kelley (@rgbkrk ; http://lambdaops.com)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ellisonbg at gmail.com Thu Jan 8 17:08:54 2015
From: ellisonbg at gmail.com (Brian Granger)
Date: Thu, 8 Jan 2015 14:08:54 -0800
Subject: [IPython-dev] Notebook websocket change
In-Reply-To:
References:
Message-ID:
>
>
> Just curious -- how do you know that most people using IPython aren't
> already using it through SMC?
>
Great question!
As with all such things, if you are asking for a precise data driven
answers, then we don't know.
But here is the constellation of evidence that would lead me to this
conclusion (that SMC represents a minority fraction of the overall number
of ipython users):
* We estimate that the total ipython user base is in the 0.5-1.5 million
range. However, this is likely a very conservative estimate. Fernando has
the best summary of where we get these estimates (I don't remember where
the most recent information is - probably in a private email to someone).
If SMC has this number of users, then my assertion is clearly to be
questioned.
* We spend a significant amount of time out meeting with ipython users an
conferences, universities, research labs, companies. Over this sample, I
know of very few people using SMC (less than 1%). I will be the first to
admit that this is both anecdotal and subject my the sampling bias of my
particular travel schedule...
* Users get and use ipython through a large number of avenues: anaconda,
pip, github, SMC, Canopy, apt-get, yum, etc. Our overall usage numbers come
from trying to estimate the install base of each of these things and adding
them up - we then double check with things like nbviewer usage, etc.
Anecdotally, it appears that anaconda is the most common way that people
get and use ipython, but the most reliable numbers we have come from
apt-get and yum.
* Commercial usage of the notebook (in private with private data) is
quickly overtaking the more open academic and educational uses of the
notebook. The difficulty here is that companies tend to keep their usage
private. However, each time we get a glimpse at commercial usage (which is
happening more and more) we are blown away by the scale of it. My
assumption is that industry usage with private code+data is not the main
audience for SMC.
I want to emphasize that I don't in any way mean to minimize the impact or
importance of SMC. We all think it is fantastic what you are doing and I
personally recommend it to people all the time.
ps - are you willing to share SMC usage stats with us? It would really help
us to reduce the error bars on our usage numbers, which is very helpful in
talking to funding agencies...
Cheers, Brian
--
Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger at calpoly.edu and ellisonbg at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From wstein at gmail.com Thu Jan 8 17:33:50 2015
From: wstein at gmail.com (William Stein)
Date: Thu, 8 Jan 2015 14:33:50 -0800
Subject: [IPython-dev] Notebook websocket change
In-Reply-To:
References:
Message-ID:
On Thu, Jan 8, 2015 at 2:08 PM, Brian Granger wrote:
>>
>> Just curious -- how do you know that most people using IPython aren't
>> already using it through SMC?
>
>
> Great question!
>
> As with all such things, if you are asking for a precise data driven
> answers, then we don't know.
>
> But here is the constellation of evidence that would lead me to this
> conclusion (that SMC represents a minority fraction of the overall number of
> ipython users):
>
> * We estimate that the total ipython user base is in the 0.5-1.5 million
> range. However, this is likely a very conservative estimate. Fernando has
> the best summary of where we get these estimates (I don't remember where the
> most recent information is - probably in a private email to someone). If SMC
> has this number of users, then my assertion is clearly to be questioned.
> * We spend a significant amount of time out meeting with ipython users an
> conferences, universities, research labs, companies. Over this sample, I
> know of very few people using SMC (less than 1%). I will be the first to
> admit that this is both anecdotal and subject my the sampling bias of my
> particular travel schedule...
> * Users get and use ipython through a large number of avenues: anaconda,
> pip, github, SMC, Canopy, apt-get, yum, etc. Our overall usage numbers come
> from trying to estimate the install base of each of these things and adding
> them up - we then double check with things like nbviewer usage, etc.
> Anecdotally, it appears that anaconda is the most common way that people get
> and use ipython, but the most reliable numbers we have come from apt-get and
> yum.
> * Commercial usage of the notebook (in private with private data) is quickly
> overtaking the more open academic and educational uses of the notebook. The
> difficulty here is that companies tend to keep their usage private. However,
> each time we get a glimpse at commercial usage (which is happening more and
> more) we are blown away by the scale of it. My assumption is that industry
> usage with private code+data is not the main audience for SMC.
>
> I want to emphasize that I don't in any way mean to minimize the impact or
> importance of SMC. We all think it is fantastic what you are doing and I
> personally recommend it to people all the time.
>
> ps - are you willing to share SMC usage stats with us? It would really help
> us to reduce the error bars on our usage numbers, which is very helpful in
> talking to funding agencies...
Thanks for explaining how you measure usage, which I knew nothing
about. Regarding my SMC usage stats, it's all here:
http://boxen.math.washington.edu/home/schilly/salvus/stats/stats.html
There is in theory more precise data, but it's not been mined yet.
Usage of SMC appears to be miniscule compared to any of the numbers
you list above.
William
>
> Cheers, Brian
>
>
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> @ellisonbg on Twitter and GitHub
> 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 ellisonbg at gmail.com Thu Jan 8 17:42:52 2015
From: ellisonbg at gmail.com (Brian Granger)
Date: Thu, 8 Jan 2015 14:42:52 -0800
Subject: [IPython-dev] Notebook websocket change
In-Reply-To:
References:
Message-ID:
Thanks for sharing this data! This will be really helpful for us!
Cheers, Brian
On Thu, Jan 8, 2015 at 2:33 PM, William Stein wrote:
> On Thu, Jan 8, 2015 at 2:08 PM, Brian Granger wrote:
> >>
> >> Just curious -- how do you know that most people using IPython aren't
> >> already using it through SMC?
> >
> >
> > Great question!
> >
> > As with all such things, if you are asking for a precise data driven
> > answers, then we don't know.
> >
> > But here is the constellation of evidence that would lead me to this
> > conclusion (that SMC represents a minority fraction of the overall
> number of
> > ipython users):
> >
> > * We estimate that the total ipython user base is in the 0.5-1.5 million
> > range. However, this is likely a very conservative estimate. Fernando has
> > the best summary of where we get these estimates (I don't remember where
> the
> > most recent information is - probably in a private email to someone). If
> SMC
> > has this number of users, then my assertion is clearly to be questioned.
> > * We spend a significant amount of time out meeting with ipython users an
> > conferences, universities, research labs, companies. Over this sample, I
> > know of very few people using SMC (less than 1%). I will be the first to
> > admit that this is both anecdotal and subject my the sampling bias of my
> > particular travel schedule...
> > * Users get and use ipython through a large number of avenues: anaconda,
> > pip, github, SMC, Canopy, apt-get, yum, etc. Our overall usage numbers
> come
> > from trying to estimate the install base of each of these things and
> adding
> > them up - we then double check with things like nbviewer usage, etc.
> > Anecdotally, it appears that anaconda is the most common way that people
> get
> > and use ipython, but the most reliable numbers we have come from apt-get
> and
> > yum.
> > * Commercial usage of the notebook (in private with private data) is
> quickly
> > overtaking the more open academic and educational uses of the notebook.
> The
> > difficulty here is that companies tend to keep their usage private.
> However,
> > each time we get a glimpse at commercial usage (which is happening more
> and
> > more) we are blown away by the scale of it. My assumption is that
> industry
> > usage with private code+data is not the main audience for SMC.
> >
> > I want to emphasize that I don't in any way mean to minimize the impact
> or
> > importance of SMC. We all think it is fantastic what you are doing and I
> > personally recommend it to people all the time.
> >
> > ps - are you willing to share SMC usage stats with us? It would really
> help
> > us to reduce the error bars on our usage numbers, which is very helpful
> in
> > talking to funding agencies...
>
> Thanks for explaining how you measure usage, which I knew nothing
> about. Regarding my SMC usage stats, it's all here:
>
> http://boxen.math.washington.edu/home/schilly/salvus/stats/stats.html
>
> There is in theory more precise data, but it's not been mined yet.
>
> Usage of SMC appears to be miniscule compared to any of the numbers
> you list above.
>
> William
>
> >
> > Cheers, Brian
> >
> >
> >
> >
> > --
> > Brian E. Granger
> > Cal Poly State University, San Luis Obispo
> > @ellisonbg on Twitter and GitHub
> > 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
@ellisonbg on Twitter and GitHub
bgranger at calpoly.edu and ellisonbg at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From fperez.net at gmail.com Thu Jan 8 18:20:03 2015
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 8 Jan 2015 15:20:03 -0800
Subject: [IPython-dev] [jupyter] Re: Notebook websocket change
In-Reply-To:
References:
Message-ID:
On Thu, Jan 8, 2015 at 2:08 PM, Brian Granger wrote:
> * We estimate that the total ipython user base is in the 0.5-1.5 million
> range. However, this is likely a very conservative estimate. Fernando has
> the best summary of where we get these estimates (I don't remember where
> the most recent information is - probably in a private email to someone).
This is how I most recently answered the question "what is the impact and
user base of IPython", indeed in the context of a private email as part of
the EU Sage-math grant proposal:
Getting metrics for usage is very tough, but we have some information. You
can read the report we wrote early this year for Sloan, that provides a
bunch of info (notebook and PDF format):
http://nbviewer.ipython.org/github/ipython/sloan-2013-reports/blob/master/IPython%202013%20Progress%20Report%20-%20Sloan%20Foundation.ipynb
http://archive.ipython.org/sloan-2013-reports/IPython%202013%20Progress%20Report%20-%20Sloan%20Foundation.pdf
As you can see, rather than a single blurb of download stats, we paint a
more complex (but I think richer) picture of broad usage and impact. A few
more things since:
- Recently highlighted in the cover of Nature:
http://www.nature.com/news/interactive-notebooks-sharing-the-code-1.16261
and that article links to a live, interactive demo here:
http://www.nature.com/news/ipython-interactive-demo-7.21492
This demo broke readership records for Nature, to the best of our
understanding (we blew past the estimates the editors gave us in terms of
highest numbers of simultaneous readers to expect).
- The NBviewer site has very significant usage, these are the Google
Analytics numbers for the period Nov 8, 2014-Dec 8, 2014:
Sessions
423,334
Users
215,546
Pageviews
844,523
That's almost 1 million page views for people sharing content as IPython
notebooks (that's the only purpose of that site).
- Our Gallery of notebooks is a good showcase of the breadth of usage and
impact of the notebook across domains:
https://github.com/ipython/ipython/wiki/A-gallery-of-interesting-IPython-Notebooks
- This list shows the adoption of our kernel architecture across languages:
23 independent implementations and counting, meaning this system is
becoming the lingua franca of interactive computing:
https://github.com/ipython/ipython/wiki/IPython-kernels-for-other-languages
- Here is a list of other projects (in academia and industry) using IPython:
https://github.com/ipython/ipython/wiki/Projects-using-IPython
- It's very hard to get accurate user counts, but we *estimate* at least ~2
Million users. This is a rough estimate, but I think realistic (and if
anything, a conservative undercount). The estimate goes as follows:
a) Estimates of linux users (not datacenter servers) range from 20M for
Ubuntu to ~70M across distros:
http://en.wikipedia.org/wiki/Ubuntu_(operating_system)#Installed_base
http://en.wikipedia.org/wiki/Linux_adoption#Measuring_desktop_adoption
b) The Debian 'popcon' statistics:
https://qa.debian.org/popcon.php?package=ipython
show IPython to be installed on ~ 5% of Debian installs.
If we use that as a baseline, and estimate total linux user counts at say
~50M (rough average of the above two numbers), we get about 2.5M installs
of IPython on linux. This doesn't count source installs, pip installs, nor
any of the Windows and Mac OSX users who get it via Anaconda, Enthought
Canopy, etc. Nor does it count the increasing number of server-side hosted
deployments we see more and more of.
But at least it gives a credible way to justify that IPython probably has
*at least* 2M users.
--
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:
From ellisonbg at gmail.com Thu Jan 8 18:23:32 2015
From: ellisonbg at gmail.com (Brian Granger)
Date: Thu, 8 Jan 2015 15:23:32 -0800
Subject: [IPython-dev] [jupyter] Re: Notebook websocket change
In-Reply-To:
References:
Message-ID:
Thanks Fernando, that was it exactly!
On Thu, Jan 8, 2015 at 3:20 PM, Fernando Perez wrote:
> On Thu, Jan 8, 2015 at 2:08 PM, Brian Granger wrote:
>
>> * We estimate that the total ipython user base is in the 0.5-1.5 million
>> range. However, this is likely a very conservative estimate. Fernando has
>> the best summary of where we get these estimates (I don't remember where
>> the most recent information is - probably in a private email to someone).
>
>
> This is how I most recently answered the question "what is the impact and
> user base of IPython", indeed in the context of a private email as part of
> the EU Sage-math grant proposal:
>
>
> Getting metrics for usage is very tough, but we have some information. You
> can read the report we wrote early this year for Sloan, that provides a
> bunch of info (notebook and PDF format):
>
>
> http://nbviewer.ipython.org/github/ipython/sloan-2013-reports/blob/master/IPython%202013%20Progress%20Report%20-%20Sloan%20Foundation.ipynb
>
>
> http://archive.ipython.org/sloan-2013-reports/IPython%202013%20Progress%20Report%20-%20Sloan%20Foundation.pdf
>
> As you can see, rather than a single blurb of download stats, we paint a
> more complex (but I think richer) picture of broad usage and impact. A few
> more things since:
>
> - Recently highlighted in the cover of Nature:
>
> http://www.nature.com/news/interactive-notebooks-sharing-the-code-1.16261
>
> and that article links to a live, interactive demo here:
>
> http://www.nature.com/news/ipython-interactive-demo-7.21492
>
> This demo broke readership records for Nature, to the best of our
> understanding (we blew past the estimates the editors gave us in terms of
> highest numbers of simultaneous readers to expect).
>
> - The NBviewer site has very significant usage, these are the Google
> Analytics numbers for the period Nov 8, 2014-Dec 8, 2014:
>
>
> Sessions
> 423,334
> Users
> 215,546
> Pageviews
> 844,523
> That's almost 1 million page views for people sharing content as IPython
> notebooks (that's the only purpose of that site).
>
> - Our Gallery of notebooks is a good showcase of the breadth of usage and
> impact of the notebook across domains:
>
>
> https://github.com/ipython/ipython/wiki/A-gallery-of-interesting-IPython-Notebooks
>
> - This list shows the adoption of our kernel architecture across
> languages: 23 independent implementations and counting, meaning this system
> is becoming the lingua franca of interactive computing:
>
> https://github.com/ipython/ipython/wiki/IPython-kernels-for-other-languages
>
> - Here is a list of other projects (in academia and industry) using
> IPython:
>
> https://github.com/ipython/ipython/wiki/Projects-using-IPython
>
> - It's very hard to get accurate user counts, but we *estimate* at least
> ~2 Million users. This is a rough estimate, but I think realistic (and if
> anything, a conservative undercount). The estimate goes as follows:
>
> a) Estimates of linux users (not datacenter servers) range from 20M for
> Ubuntu to ~70M across distros:
>
> http://en.wikipedia.org/wiki/Ubuntu_(operating_system)#Installed_base
> http://en.wikipedia.org/wiki/Linux_adoption#Measuring_desktop_adoption
>
> b) The Debian 'popcon' statistics:
>
> https://qa.debian.org/popcon.php?package=ipython
>
> show IPython to be installed on ~ 5% of Debian installs.
>
> If we use that as a baseline, and estimate total linux user counts at say
> ~50M (rough average of the above two numbers), we get about 2.5M installs
> of IPython on linux. This doesn't count source installs, pip installs, nor
> any of the Windows and Mac OSX users who get it via Anaconda, Enthought
> Canopy, etc. Nor does it count the increasing number of server-side hosted
> deployments we see more and more of.
>
> But at least it gives a credible way to justify that IPython probably has
> *at least* 2M users.
>
>
>
>
>
> --
> 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
>
> --
> You received this message because you are subscribed to the Google Groups
> "Project Jupyter" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jupyter+unsubscribe at googlegroups.com.
> To post to this group, send email to jupyter at googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jupyter/CAHAreOrQ%2BWvU2V2uxKYrho%3DXGYqSS6F1BrGmZth88kKU0s4Uaw%40mail.gmail.com
>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger at calpoly.edu and ellisonbg at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jackson_loper at brown.edu Thu Jan 8 22:28:03 2015
From: jackson_loper at brown.edu (Loper, Jackson)
Date: Thu, 8 Jan 2015 22:28:03 -0500
Subject: [IPython-dev] threadsafe widgets
Message-ID:
It is my understanding that the traitlets in most ipython notebook widgets
aren't threadsafe. If you're not sure what I mean, I attached a small
example at the bottom of this note.
What's the best way for me to make a threadsafe widget? I could inherit
from DOMWidget and override a whole bunch of methods with a wrapper that
puts things inside a threading.Lock, but it seems kinda like overkill. I
suppose theoretically you could lock all the traitlets & comms calls, but
that also seems like overkill. Or maybe not...I have no sense of
proportion for these things.
The application is straightforward, maybe there's an easier way to do it.
I'd like to be able to edit files from jupyterhub's host directly inside
the notebook; CodeMirror is much more responsive than vim over ssh. It was
easy to make a text-editing widget based on codemirror, but I'd like to pop
up a CodeMirror.dialog if somebody has changed the file being edited.
Can't figure out how to do that in a threadsafe way.
Happy Thursday!
Jackson Loper
Pattern Theory Group
Division of Applied Math
Brown University
====== threadsome danger =====
Running the latest github clone of jupyterhub, code like this is a very bad
idea:
import IPython.display
from IPython.html import widgets, nbextensions
import threading
from numpy.random import randint
isw=widgets.IntSlider()
IPython.display.display(isw)
def randoset(N):
for i in range(N):
isw.value=randint(0,50)
t1=threading.Thread(target=randoset,args=[100])
t2=threading.Thread(target=randoset,args=[100])
t1.start()
t2.start()
The jupyterhub logs errors such as
Malformed message: [b'comm-....', b'', b'comm-...', b'',
... more stuff.. ]
Presumably two attempts at sending data over comms got mixeduptogether
here, which is why we ended up with two in one message!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From fperez.net at gmail.com Thu Jan 8 23:25:51 2015
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 8 Jan 2015 20:25:51 -0800
Subject: [IPython-dev] threadsafe widgets
In-Reply-To:
References:
Message-ID:
On Thu, Jan 8, 2015 at 7:28 PM, Loper, Jackson
wrote:
> The application is straightforward, maybe there's an easier way to do it.
>
> I'd like to be able to edit files from jupyterhub's host directly inside
> the notebook;
>
Gotta run, so skipping thinking about threads right now :)
But indeed, there's an easier way to do the above: git pull.
In master of IPython, you can create/edit full files, just try it out at
tmpnb.org and let us know how it goes.
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:
From dsdale24 at gmail.com Fri Jan 9 11:38:29 2015
From: dsdale24 at gmail.com (Darren Dale)
Date: Fri, 09 Jan 2015 16:38:29 +0000
Subject: [IPython-dev] embedding ipython, namespace question
References:
Message-ID:
On Sat Jan 03 2015 at 10:45:42 AM Darren Dale wrote:
> Hi Ray,
>
> On Sat Dec 27 2014 at 8:48:20 PM Osborn, Raymond wrote:
>
>> I don?t really understand what you are trying to achieve, but the
>> ?user_ns? dictionary isn?t an isolated namespace - it?s the namespace that
>> is used by the console, and I would have thought you would have to do some
>> kind of injection to add other objects from within the application.
>>
>
> What I am trying to achieve is explicitly documented at
> http://ipython.org/ipython-doc/dev/interactive/reference.html#embedding-ipython
> :
>
> ---
> It is also possible to embed an IPython shell in a namespace in your
> Python code. This allows you to evaluate dynamically the state of your
> code, operate with your variables, analyze them, etc. Note however that any
> changes you make to values while in the shell do not propagate back to the
> running code, so it is safe to modify your values because you won?t break
> your code in bizarre ways by doing so.
>
> Note
> At present, embedding IPython cannot be done from inside IPython. Run the
> code samples below outside IPython.
> [DD: I am not attempting to embed ipython from inside ipython]
>
> This feature allows you to easily have a fully functional python
> environment for doing object introspection anywhere in your code with a
> simple function call. In some cases a simple print statement is enough, but
> if you need to do more detailed analysis of a code fragment this feature
> can be very valuable.
>
> It can also be useful in scientific computing situations where it is
> common to need to do some automatic, computationally intensive part and
> then stop to look at data, plots, etc. Opening an IPython instance will
> give you full access to your data and functions, and you can resume program
> execution once you are done with the interactive part (perhaps to stop
> again later, as many times as needed).
> The following code snippet is the bare minimum you need to include in your
> Python programs for this to work (detailed examples follow later):
>
> from IPython import embed
> embed() # this call anywhere in your program will start IPython
>
> You can also embed an IPython kernel, for use with qtconsole, etc. via
> IPython.embed_kernel(). This should function work the same way, but you can
> connect an external frontend (ipython qtconsole or ipython console), rather
> than interacting with it in the terminal.
> ---
>
> This is impressively simple for the embed function:
>
> ---
> C:\Users\darren> python
> Python 2.7.8 |Continuum Analytics, Inc.| (default, Jul 2 2014, 15:12:11)
> [MSC v.1500 64 bit (AMD64)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> Anaconda is brought to you by Continuum Analytics.
> Please check out: http://continuum.io/thanks and https://binstar.org
> >>> from IPython import embed
> >>> a=1
> >>> embed()
> Python 2.7.8 |Continuum Analytics, Inc.| (default, Jul 2 2014, 15:12:11)
> [MSC v.1500 64 bit (AMD64)]
> Type "copyright", "credits" or "license" for more information.
>
> IPython 2.3.1 -- An enhanced Interactive Python.
> Anaconda is brought to you by Continuum Analytics.
> Please check out: http://continuum.io/thanks and https://binstar.org
> ? -> 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
> Out[1]: 1
> ---
>
> But I have not been able to achieve the same behavior with the qt
> in-process console.
>
If this is not possible, perhaps the documentation should be changed?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jackson_loper at brown.edu Fri Jan 9 17:59:39 2015
From: jackson_loper at brown.edu (Loper, Jackson)
Date: Fri, 9 Jan 2015 17:59:39 -0500
Subject: [IPython-dev] threadsafe widgets
In-Reply-To:
References:
Message-ID:
Ah, the threading situation seems to be more diresome than I thought. I
believe the following code is unsafe to run.
=== Problem code ===
import IPython.display
from IPython.html import widgets
import threading
from numpy.random import randint
isw1=widgets.IntSlider()
IPython.display.display(isw1)
isw2=widgets.IntSlider()
IPython.display.display(isw2)
def randoset(wid,N):
for i in range(N):
wid.value=randint(0,50)
t1=threading.Thread(target=randoset,args=[isw1,100])
t2=threading.Thread(target=randoset,args=[isw2,100])
t1.start()
t2.start()
This code produces malformed message errors for me in the jupyterhub
terminal output.
I believe this is because all widgets seem to share the same iopub_socket
and write to it whenever the user changes a traitlet. And of course zmq
sockets aren't threadsafe.
=== A few potential solutions ===
1) "Quick" -- Wrap iopub_socket in a threadsafe wrapper. Surround every
important function call in a mutex.
2) "Hintjens-approved" -- Give every single widget its own inproc PUB
socket. We'd have to spin up an extra thread (or a greenlet in some
pre-extant thread? I don't really understand what the different IPython
threads do...but I could find out...) with a SUB socket to collect them all
together and forward them all out on iopub_socket.
3) "Dirty" -- Wrap IPython.kernel.zmq.session.Session.send inside a mutex.
Are there use-cases where anybody besides Session actually does anything
with iopub_socket?
=== Motivation ===
I think there could be valid use-cases for widgets which display results
from polling external resources, e.g. widgets which keep track of EC2
instances, widgets which monitor IPython.parallel workerbees, etc.
=== Conclusion ===
I'd be happy to attack this problem, if you guys think it would be useful.
If so, let me know what would be a good general direction, and I'll put
together a pull request.
Keep warm!
Jackson Loper
Pattern Theory Group
Division of Applied Math
Brown University
PS. I love the new text editor feature in the ipython master branch! My
days of vim-over-ssh aren't over yet (NERDTree and push-notification of
filechange detection are still too useful to me when logging on from
multiple machines) but I can see the end in sight!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ellisonbg at gmail.com Fri Jan 9 18:34:43 2015
From: ellisonbg at gmail.com (Brian Granger)
Date: Fri, 9 Jan 2015 15:34:43 -0800
Subject: [IPython-dev] threadsafe widgets
In-Reply-To:
References:
Message-ID:
Yuck :( but I am not surprised at this...
>
>
> I believe this is because all widgets seem to share the same iopub_socket
> and write to it whenever the user changes a traitlet. And of course zmq
> sockets aren't threadsafe.
>
>
Yep, they definitely share a single iopub socket.
> === A few potential solutions ===
>
> 1) "Quick" -- Wrap iopub_socket in a threadsafe wrapper. Surround every
> important function call in a mutex.
>
Probably my second choice.
> 2) "Hintjens-approved" -- Give every single widget its own inproc PUB
> socket. We'd have to spin up an extra thread (or a greenlet in some
> pre-extant thread? I don't really understand what the different IPython
> threads do...but I could find out...) with a SUB socket to collect them all
> together and forward them all out on iopub_socket.
>
Definitely not going to happen. One of the issues we are running into,
especially in multiuser deployments of the notebook is that file
descriptors get consumed. If anything we are wanting to *reduce* the number
of sockets used by ipython.
> 3) "Dirty" -- Wrap IPython.kernel.zmq.session.Session.send inside a
> mutex. Are there use-cases where anybody besides Session actually does
> anything with iopub_socket?
>
>
There shouldn't be any other way that send gets called, so this is probably
my top choice.
> === Motivation ===
>
> I think there could be valid use-cases for widgets which display results
> from polling external resources, e.g. widgets which keep track of EC2
> instances, widgets which monitor IPython.parallel workerbees, etc.
>
>
I have already started to use widgets with threads, but in my case I didn't
quite run into issue you are seeing - almost though. This is definitely
going to show up more.
> === Conclusion ===
>
> I'd be happy to attack this problem, if you guys think it would be
> useful. If so, let me know what would be a good general direction, and
> I'll put together a pull request.
>
@minrk is our expert on the zeromq stuff. Can you open an issue on the
ipython/ipython repo and mention @minrk and @ellisonbg and @jdfreder
Thanks!
Brian
>
> Keep warm!
>
> Jackson Loper
> Pattern Theory Group
> Division of Applied Math
> Brown University
>
> PS. I love the new text editor feature in the ipython master branch! My
> days of vim-over-ssh aren't over yet (NERDTree and push-notification of
> filechange detection are still too useful to me when logging on from
> multiple machines) but I can see the end in sight!
>
> _______________________________________________
> 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
@ellisonbg on Twitter and GitHub
bgranger at calpoly.edu and ellisonbg at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From fperez.net at gmail.com Fri Jan 9 18:57:17 2015
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 9 Jan 2015 15:57:17 -0800
Subject: [IPython-dev] threadsafe widgets
In-Reply-To:
References:
Message-ID:
On Fri, Jan 9, 2015 at 3:34 PM, Brian Granger wrote:
> @minrk is our expert on the zeromq stuff. Can you open an issue on the
> ipython/ipython repo and mention @minrk and @ellisonbg and @jdfreder
Add me @fperez as well please, I need to keep an eye on where this goes
too...
--
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:
From benjaminrk at gmail.com Fri Jan 9 19:25:15 2015
From: benjaminrk at gmail.com (MinRK)
Date: Fri, 9 Jan 2015 16:25:15 -0800
Subject: [IPython-dev] threadsafe widgets
In-Reply-To:
References:
Message-ID:
Since there?s already a single-threaded eventloop running (tornado), the
easiest way to ensure that actions in threads are properly serialized is to
hand them off via IOLoop.add_callback. This has the advantage over the
mutexes-everywhere approach that there isn?t anything to do in the vanilla
single-threaded case.
Where to put this serialization is a bit of an open question. The simplest
place to do it is on Session itself, since it would be always correct, but
Session isn?t always used in the context of an IOLoop, so to do it at that
level would require the most general, and thus most costly, approach (mutex
on every send/recv). We could add a send method on Kernel that does any
threading checks outside of Session, assuming that tornado is involved,
which is always True when there?s a Kernel, unlike for Session.
A mockup of threadsafe send in a tornado context:
def threadsafe_send(*args, **kwargs):
if not in_main_thread:
# can't touch zmq sockets except from main thread
# call me again ASAP from the main thread
io_loop.add_callback(threadsafe_send, *args, **kwargs)
return
actually_send()
The advantage of this over a mutex is that there?s no lock to grab in the
99% case where it is actually called from the main thread.
The issue of mixed-up messages is actually a slightly separate from libzmq
sockets themselves not being threadsafe. This is additional thread-unsafety
provided by pyzmq?s send/recv_multipart, which was allowed because the
underlying C socket is also not threadsafe. Making pyzmq itself threadsafe
was considered (implemented, even), but it?s easy enough to do this at the
application level that pyzmq doesn?t provided it for performance reasons.
-MinRK
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From dsdale24 at gmail.com Sat Jan 10 09:03:45 2015
From: dsdale24 at gmail.com (Darren Dale)
Date: Sat, 10 Jan 2015 14:03:45 +0000
Subject: [IPython-dev] embedding ipython, namespace question
References:
Message-ID:
I found the start of a solution by digging into the IPython library,
especially
https://github.com/ipython/ipython/blob/master/IPython/kernel/zmq/ipkernel.py#L33
. After creating the in-process kernel, it is possible to reinitialize the
console namespace with, for example, `kernel.user_ns = globals()`. Now its
just a matter of wiring up the gui so the user_ns gets updated whenever the
console widget receives focus.
On Fri Jan 09 2015 at 11:38:33 AM Darren Dale wrote:
> On Sat Jan 03 2015 at 10:45:42 AM Darren Dale wrote:
>
>> Hi Ray,
>>
>> On Sat Dec 27 2014 at 8:48:20 PM Osborn, Raymond wrote:
>>
>>> I don?t really understand what you are trying to achieve, but the
>>> ?user_ns? dictionary isn?t an isolated namespace - it?s the namespace that
>>> is used by the console, and I would have thought you would have to do some
>>> kind of injection to add other objects from within the application.
>>>
>>
>> What I am trying to achieve is explicitly documented at
>> http://ipython.org/ipython-doc/dev/interactive/reference.
>> html#embedding-ipython :
>>
>> ---
>> It is also possible to embed an IPython shell in a namespace in your
>> Python code. This allows you to evaluate dynamically the state of your
>> code, operate with your variables, analyze them, etc. Note however that any
>> changes you make to values while in the shell do not propagate back to the
>> running code, so it is safe to modify your values because you won?t break
>> your code in bizarre ways by doing so.
>>
>> Note
>> At present, embedding IPython cannot be done from inside IPython. Run the
>> code samples below outside IPython.
>> [DD: I am not attempting to embed ipython from inside ipython]
>>
>> This feature allows you to easily have a fully functional python
>> environment for doing object introspection anywhere in your code with a
>> simple function call. In some cases a simple print statement is enough, but
>> if you need to do more detailed analysis of a code fragment this feature
>> can be very valuable.
>>
>> It can also be useful in scientific computing situations where it is
>> common to need to do some automatic, computationally intensive part and
>> then stop to look at data, plots, etc. Opening an IPython instance will
>> give you full access to your data and functions, and you can resume program
>> execution once you are done with the interactive part (perhaps to stop
>> again later, as many times as needed).
>> The following code snippet is the bare minimum you need to include in
>> your Python programs for this to work (detailed examples follow later):
>>
>> from IPython import embed
>> embed() # this call anywhere in your program will start IPython
>>
>> You can also embed an IPython kernel, for use with qtconsole, etc. via
>> IPython.embed_kernel(). This should function work the same way, but you can
>> connect an external frontend (ipython qtconsole or ipython console), rather
>> than interacting with it in the terminal.
>> ---
>>
>> This is impressively simple for the embed function:
>>
>> ---
>> C:\Users\darren> python
>> Python 2.7.8 |Continuum Analytics, Inc.| (default, Jul 2 2014, 15:12:11)
>> [MSC v.1500 64 bit (AMD64)] on win32
>> Type "help", "copyright", "credits" or "license" for more information.
>> Anaconda is brought to you by Continuum Analytics.
>> Please check out: http://continuum.io/thanks and https://binstar.org
>> >>> from IPython import embed
>> >>> a=1
>> >>> embed()
>> Python 2.7.8 |Continuum Analytics, Inc.| (default, Jul 2 2014, 15:12:11)
>> [MSC v.1500 64 bit (AMD64)]
>> Type "copyright", "credits" or "license" for more information.
>>
>> IPython 2.3.1 -- An enhanced Interactive Python.
>> Anaconda is brought to you by Continuum Analytics.
>> Please check out: http://continuum.io/thanks and https://binstar.org
>> ? -> 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
>> Out[1]: 1
>> ---
>>
>> But I have not been able to achieve the same behavior with the qt
>> in-process console.
>>
>
> If this is not possible, perhaps the documentation should be changed?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From dsdale24 at gmail.com Sat Jan 10 10:30:30 2015
From: dsdale24 at gmail.com (Darren Dale)
Date: Sat, 10 Jan 2015 15:30:30 +0000
Subject: [IPython-dev] embedding ipython, namespace question
References:
Message-ID:
In case anyone else may find it useful, attached is a small modification of
the qt in-process example that implements the behavior I was looking for.
The namespace gets updated each time the mouse enters the widget, so every
time you use the console, the environment appears to be the same as that of
the GUI.
On Sat Jan 10 2015 at 9:03:48 AM Darren Dale wrote:
> I found the start of a solution by digging into the IPython library,
> especially https://github.com/ipython/ipython/blob/master/IPython/
> kernel/zmq/ipkernel.py#L33 . After creating the in-process kernel, it is
> possible to reinitialize the console namespace with, for example,
> `kernel.user_ns = globals()`. Now its just a matter of wiring up the gui so
> the user_ns gets updated whenever the console widget receives focus.
> On Fri Jan 09 2015 at 11:38:33 AM Darren Dale wrote:
>
>> On Sat Jan 03 2015 at 10:45:42 AM Darren Dale wrote:
>>
>>> Hi Ray,
>>>
>>> On Sat Dec 27 2014 at 8:48:20 PM Osborn, Raymond
>>> wrote:
>>>
>>>> I don?t really understand what you are trying to achieve, but the
>>>> ?user_ns? dictionary isn?t an isolated namespace - it?s the namespace that
>>>> is used by the console, and I would have thought you would have to do some
>>>> kind of injection to add other objects from within the application.
>>>>
>>>
>>> What I am trying to achieve is explicitly documented at
>>> http://ipython.org/ipython-doc/dev/interactive/reference.htm
>>> l#embedding-ipython :
>>>
>>> ---
>>> It is also possible to embed an IPython shell in a namespace in your
>>> Python code. This allows you to evaluate dynamically the state of your
>>> code, operate with your variables, analyze them, etc. Note however that any
>>> changes you make to values while in the shell do not propagate back to the
>>> running code, so it is safe to modify your values because you won?t break
>>> your code in bizarre ways by doing so.
>>>
>>> Note
>>> At present, embedding IPython cannot be done from inside IPython. Run
>>> the code samples below outside IPython.
>>> [DD: I am not attempting to embed ipython from inside ipython]
>>>
>>> This feature allows you to easily have a fully functional python
>>> environment for doing object introspection anywhere in your code with a
>>> simple function call. In some cases a simple print statement is enough, but
>>> if you need to do more detailed analysis of a code fragment this feature
>>> can be very valuable.
>>>
>>> It can also be useful in scientific computing situations where it is
>>> common to need to do some automatic, computationally intensive part and
>>> then stop to look at data, plots, etc. Opening an IPython instance will
>>> give you full access to your data and functions, and you can resume program
>>> execution once you are done with the interactive part (perhaps to stop
>>> again later, as many times as needed).
>>> The following code snippet is the bare minimum you need to include in
>>> your Python programs for this to work (detailed examples follow later):
>>>
>>> from IPython import embed
>>> embed() # this call anywhere in your program will start IPython
>>>
>>> You can also embed an IPython kernel, for use with qtconsole, etc. via
>>> IPython.embed_kernel(). This should function work the same way, but you can
>>> connect an external frontend (ipython qtconsole or ipython console), rather
>>> than interacting with it in the terminal.
>>> ---
>>>
>>> This is impressively simple for the embed function:
>>>
>>> ---
>>> C:\Users\darren> python
>>> Python 2.7.8 |Continuum Analytics, Inc.| (default, Jul 2 2014,
>>> 15:12:11) [MSC v.1500 64 bit (AMD64)] on win32
>>> Type "help", "copyright", "credits" or "license" for more information.
>>> Anaconda is brought to you by Continuum Analytics.
>>> Please check out: http://continuum.io/thanks and https://binstar.org
>>> >>> from IPython import embed
>>> >>> a=1
>>> >>> embed()
>>> Python 2.7.8 |Continuum Analytics, Inc.| (default, Jul 2 2014,
>>> 15:12:11) [MSC v.1500 64 bit (AMD64)]
>>> Type "copyright", "credits" or "license" for more information.
>>>
>>> IPython 2.3.1 -- An enhanced Interactive Python.
>>> Anaconda is brought to you by Continuum Analytics.
>>> Please check out: http://continuum.io/thanks and https://binstar.org
>>> ? -> 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
>>> Out[1]: 1
>>> ---
>>>
>>> But I have not been able to achieve the same behavior with the qt
>>> in-process console.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inprocess_qtconsole.py
Type: application/octet-stream
Size: 1457 bytes
Desc: not available
URL:
From dsdale24 at gmail.com Sun Jan 11 10:37:22 2015
From: dsdale24 at gmail.com (Darren Dale)
Date: Sun, 11 Jan 2015 15:37:22 +0000
Subject: [IPython-dev] Incompatible subclass instances of
InteractiveShellEmbed
Message-ID:
Hello,
I'm working on an application with an in-process qt console, following the
example at
https://github.com/ipython/ipython/blob/master/examples/Embedding/inprocess_qtconsole.py
. I would also like to be able to use the `embed` function occassionally
for troubleshooting other parts of the application that are unrelated to
the in-process qt console. However, calling embed yields an error:
"IPython.config.configurable.MultipleInstanceError: Multiple incompatible
subclass instances of InteractiveShellEmbed are being created." I can
reproduce this with the inprocess example by adding a call to `embed()`
just before the call to `guisupport.start_event_loop_qt4(app)`. Any ideas
how to make this work?
Thanks,
Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From rosborn at anl.gov Sun Jan 11 17:49:08 2015
From: rosborn at anl.gov (Osborn, Raymond)
Date: Sun, 11 Jan 2015 22:49:08 +0000
Subject: [IPython-dev] Incompatible subclass instances
of InteractiveShellEmbed
In-Reply-To:
References:
Message-ID: <7191368A-9B31-4D73-BB7B-D10ACE44F31D@anl.gov>
Until someone more knowledgeable replies, this is presumably because InteractiveShellEmbed ultimately inherits from SingletonConfigurable, which only allows one instance to be created. There is some code in embed.py, which saves an existing instance, clears it, and allows another to be created:
saved_shell_instance = InteractiveShell._instance
if saved_shell_instance is not None:
cls = type(saved_shell_instance)
cls.clear_instance()
shell = InteractiveShellEmbed.instance(**kwargs)
If something like that is not in your current code, perhaps you need to add it.
Ray
On Jan 11, 2015, at 9:37 AM, Darren Dale > wrote:
Hello,
I'm working on an application with an in-process qt console, following the example at https://github.com/ipython/ipython/blob/master/examples/Embedding/inprocess_qtconsole.py . I would also like to be able to use the `embed` function occassionally for troubleshooting other parts of the application that are unrelated to the in-process qt console. However, calling embed yields an error: "IPython.config.configurable.MultipleInstanceError: Multiple incompatible subclass instances of InteractiveShellEmbed are being created." I can reproduce this with the inprocess example by adding a call to `embed()` just before the call to `guisupport.start_event_loop_qt4(app)`. Any ideas how to make this work?
Thanks,
Darren
_______________________________________________
IPython-dev mailing list
IPython-dev at scipy.org
http://mail.scipy.org/mailman/listinfo/ipython-dev
--
Ray Osborn, Senior Scientist
Materials Science Division
Argonne National Laboratory
Argonne, IL 60439, USA
Phone: +1 (630) 252-9011
Email: ROsborn at anl.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From fperez.net at gmail.com Sun Jan 11 22:47:22 2015
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 11 Jan 2015 19:47:22 -0800
Subject: [IPython-dev] IPython 3.0, the homestretch. We need your help!
Message-ID:
Hi all,
we're behind schedule, but there is light at the end of the 3.0 tunnel.
Now is the time where we need the help from our community. This is the list
of currently open issues tagged for 3.0:
https://github.com/ipython/ipython/issues?q=is%3Aopen+is%3Aissue+milestone%3A3.0
If you see anything there for which you can contribute in any way a fix,
patch, or even constructive feedback, we'd be very grateful.
Eventually some of those will inevitably have to be retargetted for
3.1/4.0, since we won't be able to get to all of them. But there's a reason
we'd labeled them 3.0, so it would be great to actually close as many of
them as possible (or at least make partial progress on them, enough to
address the key problem and perhaps leave an easier but potentially longer
tail for 3.1/4).
So please jump in!
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:
From dsdale24 at gmail.com Mon Jan 12 12:28:34 2015
From: dsdale24 at gmail.com (Darren Dale)
Date: Mon, 12 Jan 2015 17:28:34 +0000
Subject: [IPython-dev] Incompatible subclass instances of
InteractiveShellEmbed
References:
<7191368A-9B31-4D73-BB7B-D10ACE44F31D@anl.gov>
Message-ID:
The following seems to work for me: in my main hexrd/__init__.py, I do
`from IPython import embed as debug`. Then, in my gui module, I monkeypatch
hexrd.debug so it uses the inprocess qtconsole:
class Debug(object):
def __init__(self, shell):
self.shell = shell
def __call__(self):
import inspect
frame = inspect.currentframe()
try:
# prepare the debug namespace
temp = frame.f_back.f_globals
temp.update(frame.f_back.f_locals)
finally:
del frame
# clear and repopulate the qtconsole namespace
self.shell.run_line_magic('reset', '-f -s')
self.shell.push(temp)
hexrd.debug = Debug(kernel_manager.kernel.shell)
Darren
On Sun Jan 11 2015 at 5:49:16 PM Osborn, Raymond wrote:
> Until someone more knowledgeable replies, this is presumably because
> InteractiveShellEmbed ultimately inherits from SingletonConfigurable, which
> only allows one instance to be created. There is some code in embed.py,
> which saves an existing instance, clears it, and allows another to be
> created:
>
> saved_shell_instance = InteractiveShell._instance
> if saved_shell_instance is not None:
> cls = type(saved_shell_instance)
> cls.clear_instance()
> shell = InteractiveShellEmbed.instance(**kwargs)
>
> If something like that is not in your current code, perhaps you need to
> add it.
>
> Ray
>
> On Jan 11, 2015, at 9:37 AM, Darren Dale wrote:
>
> Hello,
>
> I'm working on an application with an in-process qt console, following
> the example at
> https://github.com/ipython/ipython/blob/master/examples/Embedding/inprocess_qtconsole.py
> . I would also like to be able to use the `embed` function occassionally
> for troubleshooting other parts of the application that are unrelated to
> the in-process qt console. However, calling embed yields an error:
> "IPython.config.configurable.MultipleInstanceError: Multiple incompatible
> subclass instances of InteractiveShellEmbed are being created." I can
> reproduce this with the inprocess example by adding a call to `embed()`
> just before the call to `guisupport.start_event_loop_qt4(app)`. Any ideas
> how to make this work?
>
> Thanks,
> Darren
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
> --
> Ray Osborn, Senior Scientist
> Materials Science Division
> Argonne National Laboratory
> Argonne, IL 60439, USA
> Phone: +1 (630) 252-9011
> Email: ROsborn at anl.gov
>
>
> _______________________________________________
> 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:
From wstein at gmail.com Wed Jan 14 19:12:50 2015
From: wstein at gmail.com (William Stein)
Date: Wed, 14 Jan 2015 16:12:50 -0800
Subject: [IPython-dev] Notebook websocket change
In-Reply-To:
References:
Message-ID:
On Thu, Jan 8, 2015 at 11:18 AM, MinRK wrote:
> Some time ago, I made a PR to IPython switching to socket.io, which required
> the same basic changes since it only allowed a single connection per page,
> so I know it's not too hard. We may start to see more pressure as hosted
> instances, and reconsider the fallback in the future, but at this point, we
> don't feel that pressure. Wind proper websockets to be sufficiently
> preferable that we will wait as long as we can before appeasing old, broken,
> or misconfigured network environments that prevent websockets from working.
>
> The majority of notebook users seem to be running as a desktop app via
> localhost, where websockets are rarely a problem (The nightmare of Sophos
> AV/firewall on Windows excluded).
Do you have a pointer to the above pull request?
In my experience battling with websockets and the cloud over the last
few years, it's not just an issue of websockets versus fallbacks --
there's also issues with the robustness of the websocket connection,
how it's maintained, automatically reconnecting if the connection has
problems, heartbeats, etc. If you only use IPython locally then none
of this is a problem. However, if you use IPython over a complicated
network that drops packets sometimes, flakes out, etc., it can be. I
get fairly regular emails from people having trouble specifically with
the robustness of the iPython connection inside of SMC. Libraries
like socket.io and engine.io [1] seem to have pretty good debuged and
thought out code for dealing with these situations (and for fallbacks
in case websockets doesn't work).
Since this use case is only a tiny part of the total IPython notebook
usage, it makes sense for me to take this on myself. I will
definitely highly prioritize trying to hack on IPython in order to get
it to use engine.io+primus, since I have to deal with this websocket
robustness situation to improve my user's experience. For example,
I'm getting fairly regular complaints from Randy Leveque and his
colleagues at UW. So I'd greatly appreciate a link to that pull
request, and of course I'll share anything I do here.
[1] https://github.com/Automattic/engine.io
>
> -MinRK
>
> On Thu, Jan 8, 2015 at 10:55 AM, William Stein wrote:
>>
>> On Thu, Jan 8, 2015 at 10:19 AM, Brian Granger
>> wrote:
>> > So far we have felt that it isn't worth the complexity cost for us to
>> > support people that deliberately choose to break the internet. It is not
>> > like WebSockets is some crazy, insecure, unsupported hack over a weird
>> > port.
>> > It is just different bytes going over the same HTTP/HTTPS socket
>> > connection
>> > and is essentially a formal standard (I know you know this - this is our
>> > messaging to companies who complain).
>>
>> I know -- that's why I switched SMC to pure websockets for a while.
>> Then I received complaints at a rate of about 2 very desperate users
>> per week, and these were the people who cared enough to complain
>> repeatedly.
>>
>> > Our situation is a bit different though than SMC because most of our
>> > current
>> > users run the notebook on their own computers. This may be something
>> > that we
>> > eventually want to rethink as more people run this in the cloud.
>> > However, I
>> > would like to push back on the companies choosing to break the internet
>> > really hard before giving in. I am guessing that in most cases,
>> > WebSockets
>> > are broken in enterprise setting not because of some important
>> > deliberate
>> > choice, but rather because people don't understand it and are using
>> > default
>> > settings that disable them (I could be wrong though)....
>>
>> In my experience, for some people that's exactly the problem. For one
>> person I helped it turned out their specific problem was the Windows
>> install they had access to had websockets explicitly disabled --
>> perhaps that was an IT policy. For other people the problem is
>> further along the stack (e.g., possibly involving caching).
>>
>> Anyway, this change so that "there is a single websocket connection
>> between the server and client. " makes implementing an alternative to
>> WebSocket as a fallback dramatically easier, which I greatly
>> appreciate.
>>
>> > Our situation is a bit different though than SMC because most of our
>> > current
>> > users run the notebook on their own computers. This may be something
>> > that we
>>
>> Just curious -- how do you know that most people using IPython aren't
>> already using it through SMC?
>>
>> William
>>
>> >
>> > Cheers,
>> >
>> > Brian
>> >
>> >
>> >
>> > On Thu, Jan 8, 2015 at 10:10 AM, William Stein wrote:
>> >>
>> >> On Thu, Jan 8, 2015 at 10:04 AM, MinRK wrote:
>> >> > Alternative notebook frontend authors:
>> >> >
>> >> > There is an upcoming change to websocket connections to the notebook
>> >> > server.
>> >> > Instead of three websockets per notebook, one for each zmq channel,
>> >> > there is
>> >> > a single websocket connection between the server and client. The
>> >> > channel
>> >> > associated with each message is identified by a channel key in the
>> >> > message
>> >> > dict itself.
>> >> >
>> >> > Relevant changes:
>> >> >
>> >> > url is /channels instead of /shell, etc.
>> >> > when sending a message, add a channel key with the channel name
>> >> > ('shell',
>> >> > 'stdin')
>> >> > when receiving a message, check the channel key for routing
>> >> >
>> >> > -MinRK
>> >>
>> >> Thanks.
>> >>
>> >> Of related interest, what the situation involving providing a fallback
>> >> to websockets?
>> >>
>> >> I tried to only support websockets connections with SageMathCloud for
>> >> a few weeks, and immediately ran into many complaints from users who
>> >> couldn't connect as a result. This is even with https and so on --
>> >> it's just a sad fact that in some corporate or otherwise constrained
>> >> environments that websockets don't work. By far the best approach I
>> >> found was to use Primus + Engine.io, which uses websockets if
>> >> possible, but will fallback to polling. So this is what SMC does
>> >> now, and everything works, even for people that don't have websockets
>> >> as an option... except for IPython-in-SMC of course, which doesn't
>> >> work.
>> >>
>> >> Another unrelated issue is that I'm now hardcoding making this change
>> >> around line 171 of IPython/html/notebookapp.py, since I want to serve
>> >> the purely static html of IPython from a completely different web
>> >> server:
>> >>
>> >> #static_url_prefix = url_path_join(base_url,'/static/'),
>> >> static_url_prefix = '/static/ipython/',
>> >>
>> >> (Sorry for derailing the thread.)
>> >>
>> >> -- William
>> >>
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > 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
>> > @ellisonbg on Twitter and GitHub
>> > 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
>
>
>
> _______________________________________________
> 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 Wed Jan 14 19:50:46 2015
From: benjaminrk at gmail.com (MinRK)
Date: Wed, 14 Jan 2015 16:50:46 -0800
Subject: [IPython-dev] Notebook websocket change
In-Reply-To:
References:
Message-ID:
The PR is 2321 , switching
IPython to use SockJS instead of WebSockets. I?m not sure how informative
it is, since things have moved around *a lot* since then, and it is from a
time when we were shipping more things in external, rather than accepting
them as dependencies. I think a similar patch today would be a great deal
simpler, especially now that it doesn?t need to include merging sockets. I
also had to include a hack to workaround the fact that SockJS didn?t allow
empty messages, and we were sending empty messages as part of the initial
handshake (also not true anymore).
-MinRK
?
On Wed, Jan 14, 2015 at 4:12 PM, William Stein wrote:
> On Thu, Jan 8, 2015 at 11:18 AM, MinRK wrote:
> > Some time ago, I made a PR to IPython switching to socket.io, which
> required
> > the same basic changes since it only allowed a single connection per
> page,
> > so I know it's not too hard. We may start to see more pressure as hosted
> > instances, and reconsider the fallback in the future, but at this point,
> we
> > don't feel that pressure. Wind proper websockets to be sufficiently
> > preferable that we will wait as long as we can before appeasing old,
> broken,
> > or misconfigured network environments that prevent websockets from
> working.
> >
> > The majority of notebook users seem to be running as a desktop app via
> > localhost, where websockets are rarely a problem (The nightmare of Sophos
> > AV/firewall on Windows excluded).
>
> Do you have a pointer to the above pull request?
>
> In my experience battling with websockets and the cloud over the last
> few years, it's not just an issue of websockets versus fallbacks --
> there's also issues with the robustness of the websocket connection,
> how it's maintained, automatically reconnecting if the connection has
> problems, heartbeats, etc. If you only use IPython locally then none
> of this is a problem. However, if you use IPython over a complicated
> network that drops packets sometimes, flakes out, etc., it can be. I
> get fairly regular emails from people having trouble specifically with
> the robustness of the iPython connection inside of SMC. Libraries
> like socket.io and engine.io [1] seem to have pretty good debuged and
> thought out code for dealing with these situations (and for fallbacks
> in case websockets doesn't work).
>
> Since this use case is only a tiny part of the total IPython notebook
> usage, it makes sense for me to take this on myself. I will
> definitely highly prioritize trying to hack on IPython in order to get
> it to use engine.io+primus, since I have to deal with this websocket
> robustness situation to improve my user's experience. For example,
> I'm getting fairly regular complaints from Randy Leveque and his
> colleagues at UW. So I'd greatly appreciate a link to that pull
> request, and of course I'll share anything I do here.
>
> [1] https://github.com/Automattic/engine.io
>
> >
> > -MinRK
> >
> > On Thu, Jan 8, 2015 at 10:55 AM, William Stein wrote:
> >>
> >> On Thu, Jan 8, 2015 at 10:19 AM, Brian Granger
> >> wrote:
> >> > So far we have felt that it isn't worth the complexity cost for us to
> >> > support people that deliberately choose to break the internet. It is
> not
> >> > like WebSockets is some crazy, insecure, unsupported hack over a weird
> >> > port.
> >> > It is just different bytes going over the same HTTP/HTTPS socket
> >> > connection
> >> > and is essentially a formal standard (I know you know this - this is
> our
> >> > messaging to companies who complain).
> >>
> >> I know -- that's why I switched SMC to pure websockets for a while.
> >> Then I received complaints at a rate of about 2 very desperate users
> >> per week, and these were the people who cared enough to complain
> >> repeatedly.
> >>
> >> > Our situation is a bit different though than SMC because most of our
> >> > current
> >> > users run the notebook on their own computers. This may be something
> >> > that we
> >> > eventually want to rethink as more people run this in the cloud.
> >> > However, I
> >> > would like to push back on the companies choosing to break the
> internet
> >> > really hard before giving in. I am guessing that in most cases,
> >> > WebSockets
> >> > are broken in enterprise setting not because of some important
> >> > deliberate
> >> > choice, but rather because people don't understand it and are using
> >> > default
> >> > settings that disable them (I could be wrong though)....
> >>
> >> In my experience, for some people that's exactly the problem. For one
> >> person I helped it turned out their specific problem was the Windows
> >> install they had access to had websockets explicitly disabled --
> >> perhaps that was an IT policy. For other people the problem is
> >> further along the stack (e.g., possibly involving caching).
> >>
> >> Anyway, this change so that "there is a single websocket connection
> >> between the server and client. " makes implementing an alternative to
> >> WebSocket as a fallback dramatically easier, which I greatly
> >> appreciate.
> >>
> >> > Our situation is a bit different though than SMC because most of our
> >> > current
> >> > users run the notebook on their own computers. This may be something
> >> > that we
> >>
> >> Just curious -- how do you know that most people using IPython aren't
> >> already using it through SMC?
> >>
> >> William
> >>
> >> >
> >> > Cheers,
> >> >
> >> > Brian
> >> >
> >> >
> >> >
> >> > On Thu, Jan 8, 2015 at 10:10 AM, William Stein
> wrote:
> >> >>
> >> >> On Thu, Jan 8, 2015 at 10:04 AM, MinRK wrote:
> >> >> > Alternative notebook frontend authors:
> >> >> >
> >> >> > There is an upcoming change to websocket connections to the
> notebook
> >> >> > server.
> >> >> > Instead of three websockets per notebook, one for each zmq channel,
> >> >> > there is
> >> >> > a single websocket connection between the server and client. The
> >> >> > channel
> >> >> > associated with each message is identified by a channel key in the
> >> >> > message
> >> >> > dict itself.
> >> >> >
> >> >> > Relevant changes:
> >> >> >
> >> >> > url is /channels instead of /shell, etc.
> >> >> > when sending a message, add a channel key with the channel name
> >> >> > ('shell',
> >> >> > 'stdin')
> >> >> > when receiving a message, check the channel key for routing
> >> >> >
> >> >> > -MinRK
> >> >>
> >> >> Thanks.
> >> >>
> >> >> Of related interest, what the situation involving providing a
> fallback
> >> >> to websockets?
> >> >>
> >> >> I tried to only support websockets connections with SageMathCloud for
> >> >> a few weeks, and immediately ran into many complaints from users who
> >> >> couldn't connect as a result. This is even with https and so on --
> >> >> it's just a sad fact that in some corporate or otherwise constrained
> >> >> environments that websockets don't work. By far the best approach I
> >> >> found was to use Primus + Engine.io, which uses websockets if
> >> >> possible, but will fallback to polling. So this is what SMC does
> >> >> now, and everything works, even for people that don't have websockets
> >> >> as an option... except for IPython-in-SMC of course, which doesn't
> >> >> work.
> >> >>
> >> >> Another unrelated issue is that I'm now hardcoding making this change
> >> >> around line 171 of IPython/html/notebookapp.py, since I want to serve
> >> >> the purely static html of IPython from a completely different web
> >> >> server:
> >> >>
> >> >> #static_url_prefix = url_path_join(base_url,'/static/'),
> >> >> static_url_prefix = '/static/ipython/',
> >> >>
> >> >> (Sorry for derailing the thread.)
> >> >>
> >> >> -- William
> >> >>
> >> >> >
> >> >> >
> >> >> > _______________________________________________
> >> >> > 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
> >> > @ellisonbg on Twitter and GitHub
> >> > 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
> >
> >
> >
> > _______________________________________________
> > 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:
From wstein at gmail.com Wed Jan 14 19:55:21 2015
From: wstein at gmail.com (William Stein)
Date: Wed, 14 Jan 2015 16:55:21 -0800
Subject: [IPython-dev] Notebook websocket change
In-Reply-To:
References: